On Mon, Jan 22, 2018 at 11:12 PM Devin Heitmueller < dheitmuel...@ltnglobal.com> wrote:
> Hi Ray, > > > On Jan 22, 2018, at 10:47 PM, Ray Tiley <rayti...@gmail.com> wrote: > >> Could you confirm whether you are capturing via SDI or analog (i.e. > >> composite/component)? Also what is the capturing device and SDK version > >> you are using? I’ve found various bugs in the numbering of VANC lines > in > >> some cards, particularly with interlaced formats, and it would be good > to > >> understand if perhaps this is a card-specific issue. > >> > >> I'm capturing SDI, the only decklink card I have access to is the > Decklink > > mini recorder, and I was using the latest sdk ( I can check exact version > > tomorrow during work.) It's definitely possible I expanded the search > lines > > a bit too far, I was just hacking until I found the data. > > Ok, so it’s possible that in the three cases you’ve changed, the start > line was actually fine to begin with and the problem was just the end line > was wrong. I could totally believe that. > > I can say that all three start lines are correct according to RP 168, but > I would have to do the math to check the end lines (there was a time I > could tell you from memory where the active video starts/ends for each > video standard, but those days are long gone). > > > > The source equipment was again a Matrox LE4. The source file was 1080i > > while I was testing the NTSC output, so it was perhaps a scaling issue. > > However the spec says that VANC data will be on the luma channel for high > > definition sources, so that is why I tried extracting it from the > > interleaved and was able to successfully parse the VANC packets. > > Right. At least in libklvanc I don’t even bother looking at the chroma > channel, since I’ve never seen a piece of equipment that puts any VANC > there. For CEA-608 payloads and CEA-708 CDP packets, SMPTE ST 334-1:2015 > Sec 4 clearly states that it must be in the luma channel for HD sources. > I'm reading 334-1:2017 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." I couldn't find anywhere in the document where it calls out standard definition Conversation is here: https://video-dev.slack.com/archives/C0XKDDH5Y/p1516141555000074 with kier...@obe.tv who I believe is in the ffmpeg-devel IRC. > > > > > I chatted with someone in the video developers slack community and they > > suggested that for NTSC the data is indeed interleaved. > > Hmmm, this is a pretty ambiguous explanation. Got a link to the > conversation? > > I also wouldn’t rule out a decklink bug, but it’s too early to make such > an assertion. > > If you can get a dump of the raw VANC line data that I can review, that > would be helpful. > > > > > I have access to some SD captioned files that I can play out my test > > hardware to eliminate scaling. > > Great. I think you’ve definitely found some issues - it’s just a question > of whether we really have to deviate from the spec in order to work > properly for your use case. > > Devin > _______________________________________________ > 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