[FFmpeg-devel] [PATCH] Implement NewTek NDI support

Nicolas George george at nsup.org
Sun Jul 23 18:07:13 EEST 2017


Le quintidi 5 thermidor, an CCXXV, Marton Balint a écrit :
> That is copied from decklink_dec as far as I see. Maybe better to factorize
> first, and move it to AVThreadMessageQueue as a second step?

I had not noticed it was copied from decklink_dec. If so, then it must
absolutely be shared between this decklink_dec and NDI.

And indeed, it would probably be better to change decklink_dec to use
AVThreadMessageQueue, but it is harder for new code.

> Maybe it's just me, but I am not sure what kind of probing are you referring
> to. Could you explain in a bit more detail how the changed code should work?

The same way it works for formats without global header, for example
MPEG-PS: read_header() does not create any stream; read_packet() creates
the stream when it sees a packet for one that does not exist yet. And
libavformat takes care of the rest. I think it requires
AVFMTCTX_NOHEADER.

> I guess that is copied from decklink as well. As far as I see, the correct
> replacement is to set codecpar->field_order in read_header, and that is it,
> right?

I think so.

> I think it is better if it works with unkown channel layouts as well, as
> long as the number of channels are supported.

I do not agree, and especially not in the device itself. There are many
small issues where some component invents a default layout when only a
count is provided, and then we are unable to propagate a count without a
layout.

> >>+        av_log(avctx, AV_LOG_ERROR, "Only one video stream is supported!\n");
> >>+        return AVERROR(ENOTSUP);
> >I suspect this library exists also for Windows and Macos, so you cannot
> >use ENOTSUP. EINVAL.
> Or maybe ENOSYS?

ENOTSUP -> "Operation not supported" / "Not supported"
ENOSYS  -> "Function not implemented" / "Function not supported"
EINVAL  -> "Invalid argument"

In this case, the problem is that the avctx argument has several
streams: EINVAL is really the correct one.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170723/a8c2fb00/attachment.sig>


More information about the ffmpeg-devel mailing list