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 
>>    /* 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 

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 

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.


ffmpeg-devel mailing list

Reply via email to