Hello Marton,
Thanks for taking the time to review. Most of the comments you’ve raised will
be fixed and I’ll resubmit an updated patch. Comments on other issues inline
below.
>>
>> /* Options */
>> int list_devices;
>> @@ -88,6 +93,7 @@ struct decklink_ctx {
>> DecklinkPtsSource audio_pts_source;
>> DecklinkPtsSource video_pts_source;
>> int draw_bars;
>> + int raw_format;
>
> Since this header includes decklink headers, this can be BMDPixelFormat
> instead of int, and you can use the decklink constants directly instead of
> MKBETAG.
I used MKBETAG because that was what was being used in decklink_dec.cpp (and I
wanted to be consistent). That said, I have no objection to changing it.
>
> For older decklink models (E.g. Decklink SDI, Decklink Duo 1), when you
> capture in 8 bit mode, you can only query 8bit VANC. For output, can you
> always use 10-bit VANC? Even if you use 8bit mode for video? Because if you
> can't, then it might make sense to return silently here, or only warn to user
> once, not for every frame (and maybe disable vanc_support?).
All decklink models require that VANC be in the same bit depth as video capture
(i.e. with both older and newer models you cannot do 8-bit video with 10-bit
VANC or vice-versa). The only exception is the RGB formats which do VANC in
10-bit YUV. The decklink_construct_vanc() function is only ever called if the
device is putting out 10-bit video, and thus your question about putting out
10-bit VANC when doing 8-bit video isn’t an issue since we never hit that code
path.
In summary, 8-bit VANC isn’t supported in the module, and I don’t have any
immediate plans to do such given how rare it is nowadays. If somebody really
cares about that use case, we can discuss further.
Devin
_______________________________________________
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
