On Mon, Feb 5, 2018 at 7:32 PM Marton Balint <c...@passwd.hu> wrote: > > > 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 > Just sent the updated patch (hopefully correctly). Sorry about the outdated one before. Thanks -ray > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
