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

[Ray Tiley]

On Mon, Feb 5, 2018 at 7:32 PM Marton Balint <cus at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>