[FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract NTSC VANC

[Marton Balint]

On Mon, 5 Feb 2018, Devin Heitmueller wrote:

> Hi Marton,
>
>> 
>> Have you found which standard contains reference to interleaved VANC?
>
> So SMPTE falls back onto the earlier standards for digital video bitstreams as defined in ITU BT.656 (for SD) and BT.1120 (for HD).
>
>> 
>>> 
>>> That said, the list of modes should probably be expanded to include all the SD resolutions (although you’re unlikely to see CEA-708 over non-NTSC streams).  However I don’t think it would be a good idea to attempt to ‘autodetect” by applying both algorithms over all VANC lines regardless of mode.
>> 
>> I think the plan was to check if the mode is NTSC _and_ the first VANC header is present in an interleaved way. So the HD modes would remain as before.
>> 
>> I only found ITU-R BT.1364-3 which states that luma and chroma are separate VANC spaces, so that is why I thought autodetection for even NTSC would make it more compatible with newer equipment respecting this recommendation.
>
> I assume you’re referring to this specific excerpt from ITU BT.1364 Sec 4:
>
> "In interfaces conforming to Recommendation ITU-R BT.1120, the data words corresponding to the luminance and colour-difference channels are considered to form two independent ancillary data spaces, each of which begins with its own timing reference signal (and line number and CRCC)." 
>
> The key here is that this paragraph refers exclusively to interfaces conforming to BT.1120.  BT.1120 is bitstream format for HDTV interfaces, and doesn’t apply to standard definition.  Cases where we’re talking about standard definition (as specified in BT.656 and BT.799) don’t treat luma and chroma as two independent ancillary data spaces.
>
> Now Ray pointed out that SMPTE ST 334-1:2015 states the following in Sec 4:
>
> "When the ANC packets defined in this standard are carried in a high definition signal, they shall be carried in the Y stream.”
>
> This could certainly be considered ambiguous since it doesn’t state explicitly how ANC packets in standard definition should be carried.  I’m not willing to make that leap though given I’ve now looked at a couple of pieces of commercial gear, what Kieran’s OBE code has been doing for years without issue, as well as the contents of the ITU specs.
>
> All that said, if somebody wants to show me a VANC dump from a piece of commercially available hardware which does treat the channels separately in standard definition, I would certainly be willing to change my stance.  I would rather wait until that happens though rather than have code in ffmpeg which has never been exercised with any real input (and likely never will be).

Ok, then I guess only the width needs fixing, which is doubled if the 
source is interleaved.

Thanks,
Marton