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 ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel