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).


ffmpeg-devel mailing list

Reply via email to