[FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC
This changes the vertical blanking lines extracted for NTSC and 1080i
resolutions that in personal testing were required to extract closed
caption data from the decklink video frames.
Additionally NTSC resolutions have the vanc data interleved between the uyvy
and not just the luma as in high definition resolutions.
In my testing this allows a decklink card encoding valid NTSC and 1080i
closed captions to pass the caption data to the x264 encoder.
Signed-off-by: Ray Tiley
---
libavdevice/decklink_dec.cpp | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 94dae26..bceced5 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -67,8 +67,7 @@ typedef struct VANCLineNumber {
* another source during switching*/
static VANCLineNumber vanc_line_numbers[] = {
/* SD Modes */
-
-{bmdModeNTSC, 11, 19, 274, 282},
+{bmdModeNTSC, 4, 21, 24, 284},
{bmdModeNTSC2398, 11, 19, 274, 282},
{bmdModePAL, 7, 22, 320, 335},
{bmdModeNTSCp, 11, -1, -1, 39},
@@ -82,7 +81,7 @@ static VANCLineNumber vanc_line_numbers[] = {
{bmdModeHD1080p2997, 8, -1, -1, 42},
{bmdModeHD1080p30, 8, -1, -1, 42},
{bmdModeHD1080i50, 8, 20, 570, 585},
-{bmdModeHD1080i5994, 8, 20, 570, 585},
+{bmdModeHD1080i5994, 6, 30, 568, 595},
{bmdModeHD1080i6000, 8, 20, 570, 585},
{bmdModeHD1080p50, 8, -1, -1, 42},
{bmdModeHD1080p5994, 8, -1, -1, 42},
@@ -92,7 +91,7 @@ static VANCLineNumber vanc_line_numbers[] = {
{bmdModeHD720p50, 8, -1, -1, 26},
{bmdModeHD720p5994, 8, -1, -1, 26},
-{bmdModeHD720p60, 8, -1, -1, 26},
+{bmdModeHD720p60, 7, -1, -1, 26},
/* For all other modes, for which we don't support VANC */
{bmdModeUnknown, 0, -1, -1, -1}
@@ -149,6 +148,30 @@ static void extract_luma_from_v210(uint16_t *dst, const
uint8_t *src, int width)
}
}
+static void unpack_v210(uint16_t *dst, const uint8_t *src, int width)
+{
+int i;
+for (i = 0; i < width / 6; i++) {
+*dst++ = src[0] + ((src[1] & 3) << 8);
+*dst++ = (src[1] >> 2) + ((src[2] & 15) << 6);
+*dst++ = (src[2] >> 4) + ((src[3] & 63) << 4);
+
+*dst++ = src[4] + ((src[5] & 3) << 8);
+*dst++ = (src[5] >> 2) + ((src[6] & 15) << 6);
+*dst++ = (src[6] >> 4) + ((src[7] & 63) << 4);
+
+*dst++ = src[8] + ((src[9] & 3) << 8);
+*dst++ = (src[9] >> 2) + ((src[10] & 15) << 6);
+*dst++ = (src[10] >> 4) + ((src[11] & 63) << 4);
+
+*dst++ = src[12] + ((src[13] & 3) << 8);
+*dst++ = (src[13] >> 2) + ((src[14] & 15) << 6);
+*dst++ = (src[14] >> 4) + ((src[15] & 63) << 4);
+
+src += 16;
+}
+}
+
static uint8_t calc_parity_and_line_offset(int line)
{
uint8_t ret = (line < 313) << 5;
@@ -741,7 +764,11 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
uint8_t *buf;
if (vanc->GetBufferForVerticalBlankingLine(i,
(void**)&buf) == S_OK) {
uint16_t luma_vanc[MAX_WIDTH_VANC];
-extract_luma_from_v210(luma_vanc, buf,
videoFrame->GetWidth());
+if (ctx->bmd_mode == bmdModeNTSC) {
+ unpack_v210(luma_vanc, buf,
videoFrame->GetWidth());
+} else {
+ extract_luma_from_v210(luma_vanc, buf,
videoFrame->GetWidth());
+}
txt_buf = get_metadata(avctx, luma_vanc,
videoFrame->GetWidth(),
txt_buf, sizeof(txt_buf0) -
(txt_buf - txt_buf0), &pkt);
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC
On Mon, Jan 22, 2018 at 10:20 PM Devin Heitmueller <
dheitmuel...@ltnglobal.com> wrote:
> Hi Ray,
>
> Thanks for your patch. A few questions:
>
> 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.
>
> > On Jan 20, 2018, at 12:33 PM, Ray Tiley wrote:
> >
> > This changes the vertical blanking lines extracted for NTSC and 1080i
> > resolutions that in personal testing were required to extract closed
> > caption data from the decklink video frames.
> >
> > Additionally NTSC resolutions have the vanc data interleved between the
> uyvy
> > and not just the luma as in high definition resolutions.
> >
> > In my testing this allows a decklink card encoding valid NTSC and 1080i
> > closed captions to pass the caption data to the x264 encoder.
> >
> > Signed-off-by: Ray Tiley
> > ---
> > libavdevice/decklink_dec.cpp | 37 -
> > 1 file changed, 32 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > index 94dae26..bceced5 100644
> > --- a/libavdevice/decklink_dec.cpp
> > +++ b/libavdevice/decklink_dec.cpp
> > @@ -67,8 +67,7 @@ typedef struct VANCLineNumber {
> > * another source during switching*/
> > static VANCLineNumber vanc_line_numbers[] = {
> > /* SD Modes */
> > -
> > -{bmdModeNTSC, 11, 19, 274, 282},
> > +{bmdModeNTSC, 4, 21, 24, 284},
>
> I hadn’t previously reviewed this table, but now that I look at it, I’m
> not confident your proposed patch is correct. VANC data generally cannot
> appear until after the switching line (through the first line of active
> video), which is on line 10 for NTSC 480i video. Could you elaborate on
> what equipment you have which is putting VBI data out on lines 4-10?
> Agreed though that the upper limit for field one is incorrect - it should
> be 21 as your patch proposed.
>
> Also, it’s highly unlikely that you really want to search line 24-284 for
> field 2 VBI data. Perhaps you meant 274-284?
>
> FYI: SMPTE RP 168-2009 is the normative reference for the location of
> switching lines across various video resolutions/framerates.
>
> For NTSC my source hardware was outputting on line 12, so I'll resubmit
the patch with it adjusted after I dig up SMPTE RP 168-2009 and check the
values.. The one I definitely had to modify in order for the search to find
the data was bmdModeHD1080i5994, when I get to the office I'll hook up the
signal to my scope and check the exact line and also run a test in 720p
>
> > {bmdModeNTSC2398, 11, 19, 274, 282},
> > {bmdModePAL, 7, 22, 320, 335},
> > {bmdModeNTSCp, 11, -1, -1, 39},
> > @@ -82,7 +81,7 @@ static VANCLineNumber vanc_line_numbers[] = {
> > {bmdModeHD1080p2997, 8, -1, -1, 42},
> > {bmdModeHD1080p30, 8, -1, -1, 42},
> > {bmdModeHD1080i50, 8, 20, 570, 585},
> > -{bmdModeHD1080i5994, 8, 20, 570, 585},
> > +{bmdModeHD1080i5994, 6, 30, 568, 595},
>
> For 1080i the switching line is line 7, hence VBI should appear on line
> 8+. It’s possible for data to appear on line 7 if the transmitting
> equipment is misconfigured, and only some cards can actually capture that
> data (for example, the Decklink Duo cannot but the Decklink Duo2 can).
>
> Again, what is the signal source?
>
This makes sense, VBI was on line 12 for 1080i. The source was a Matrox DSX
LE4.
>
> > {bmdModeHD1080i6000, 8, 20, 570, 585},
> > {bmdModeHD1080p50, 8, -1, -1, 42},
> > {bmdModeHD1080p5994, 8, -1, -1, 42},
> > @@ -92,7 +91,7 @@ static VANCLineNumber vanc_line_numbers[] = {
> >
> > {bmdModeHD720p50, 8, -1, -1, 26},
> > {bmdModeHD720p5994, 8, -1, -1, 26},
> > -{bmdModeHD720p60, 8, -1, -1, 26},
> > +{bmdModeHD720p60, 7, -1, -1, 26},
>
> Same questions as with the 1080i change above. Also, switching line
> location is the same for 720p/5994 and 720p/60, so presumably we would want
> to adjust both if it is actually needed.
>
> >
> > /* For all other modes, for which we do
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC
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 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/p151614155574 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
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC
On Tue, Jan 23, 2018 at 9:07 AM Devin Heitmueller < dheitmuel...@ltnglobal.com> wrote: > Hi Ray, > > > On Jan 22, 2018, at 11:20 PM, Ray Tiley wrote: > > > > 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 > > Right, so my understanding was that allowing the ability to use both luma > and chroma was a result of having less space in the VANC to hold data, > compared to HD resolutions where that is much less likely to be an issue. > That said, I’ve never seen an implementation that actually puts it in the > chroma. > > > > > Conversation is here: > > https://video-dev.slack.com/archives/C0XKDDH5Y/p151614155574 < > https://video-dev.slack.com/archives/C0XKDDH5Y/p151614155574> with > > kier...@obe.tv <mailto:kier...@obe.tv> who I believe is in the > ffmpeg-devel IRC. > > > > Ah, ok. That’s Kieran. He’s really knowledgable in this area, although I > cannot see the conversation you’ve linked to as it seems that room is only > accessible by people with email accounts from certain domains. > > Devin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Please find updated patch attatched. I reverted the vanc lines changes and found that all my tests worked as expected, so not sure what was wrong w/ my original test. The need to extract vanc from the entire line vs just the luma in NTSC is still required. -ray 0001-avdevice-decklink_dec-Extract-NTSC-VANC.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC
Apologies for attaching the patch, still trying to figure out patches, didn't know how to send the patch and include info in the email unrelated to commit message / change. The unpack_v210 is only called for SD resolutions ,specifically NTSC which is 720 wide. unpack_v210 should never be called for HD resolutions as that would violate the spec in which all the vanc should be in the lama. So MAX_WIDTH_VANC being 1920 is wide enough to hold a single line of unpacked SD resolution. But probably better to be safe then risk an overflow. I see a few options. Increase luma_vanc to be MAX_WIDTH_VANC * 3, but a guard in the unpack_v210 (should it just return early, log a warning), or do both. Any preferences. C is not my day to day language so let me know what' best practice and I'll get the patch fixed up. -ray On Thu, Jan 25, 2018 at 9:47 AM Devin Heitmueller < dheitmuel...@ltnglobal.com> wrote: > Hi Ray, > > > > > Please find updated patch attatched. I reverted the vanc lines changes > and > > found that all my tests worked as expected, so not sure what was wrong w/ > > my original test. The need to extract vanc from the entire line vs just > the > > luma in NTSC is still required. > > It’s helpful if in the future you could not do patches as attachments. It > makes it harder for people to comment on them. > > Glad to hear you didn’t need to adjust any of the VANC line definitions in > order to work properly. I think they do still need some more review, but > at least we don’t need to commit to any values at this time which would > violate the spec. > > Regarding the luma/chroma extraction, I haven’t looked at your code too > closely, but isn’t the destination array too small? If MAX_WIDTH_VANC is > 1920, presumably intended to be the number of pixels, then you would need > three times as many uint16_t values in your destination array if you wanted > Y, U, and V, or else you would overflow the buffer. Right? In either > case, you probably want some bounds protection to ensure GetWidth() never > returns a size greater than your destination array. > > Also, could you send me a copy of the array of V210 bytes you are testing > with (i.e. just jam a printf loop into the code and dump the whole thing > out)? Would be useful to have it here so I can ensure that libklvanc works > properly as well (and add it to the list of test vectors I bundle with the > library). If you can’t that’s fine - I’ll eventually get around to doing > some SD testing here. > > 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
[FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract NTSC VANC
This changes how NTSC VANC is extracted from the buffer. In NTSC the vanc
data interleved between the uyvy and not just the luma as in
high definition resolutions.
In my testing this allows a decklink card encoding valid NTSC closed
captions to pass the caption data to the x264 encoder.
Updated with rewviews from Devon Heitmueller and Marton Balint.
Signed-off-by: Ray Tiley
---
libavdevice/decklink_dec.cpp | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 94dae26..c7811eb 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -149,6 +149,30 @@ static void extract_luma_from_v210(uint16_t *dst, const
uint8_t *src, int width)
}
}
+static void unpack_v210(uint16_t *dst, const uint8_t *src, int width)
+{
+int i;
+for (i = 0; i < width / 6; i++) {
+*dst++ = src[0] + ((src[1] & 3) << 8);
+*dst++ = (src[1] >> 2) + ((src[2] & 15) << 6);
+*dst++ = (src[2] >> 4) + ((src[3] & 63) << 4);
+
+*dst++ = src[4] + ((src[5] & 3) << 8);
+*dst++ = (src[5] >> 2) + ((src[6] & 15) << 6);
+*dst++ = (src[6] >> 4) + ((src[7] & 63) << 4);
+
+*dst++ = src[8] + ((src[9] & 3) << 8);
+*dst++ = (src[9] >> 2) + ((src[10] & 15) << 6);
+*dst++ = (src[10] >> 4) + ((src[11] & 63) << 4);
+
+*dst++ = src[12] + ((src[13] & 3) << 8);
+*dst++ = (src[13] >> 2) + ((src[14] & 15) << 6);
+*dst++ = (src[14] >> 4) + ((src[15] & 63) << 4);
+
+src += 16;
+}
+}
+
static uint8_t calc_parity_and_line_offset(int line)
{
uint8_t ret = (line < 313) << 5;
@@ -741,7 +765,11 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
uint8_t *buf;
if (vanc->GetBufferForVerticalBlankingLine(i,
(void**)&buf) == S_OK) {
uint16_t luma_vanc[MAX_WIDTH_VANC];
-extract_luma_from_v210(luma_vanc, buf,
videoFrame->GetWidth());
+if (ctx->bmd_mode == bmdModeNTSC) {
+ unpack_v210(luma_vanc, buf,
videoFrame->GetWidth());
+} else {
+ extract_luma_from_v210(luma_vanc, buf,
videoFrame->GetWidth());
+}
txt_buf = get_metadata(avctx, luma_vanc,
videoFrame->GetWidth(),
txt_buf, sizeof(txt_buf0) -
(txt_buf - txt_buf0), &pkt);
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC
On Sun, Jan 28, 2018 at 4:54 PM Marton Balint wrote: > > On Thu, 25 Jan 2018, Ray Tiley wrote: > > > On Tue, Jan 23, 2018 at 9:07 AM Devin Heitmueller < > > dheitmuel...@ltnglobal.com> wrote: > > > >> Hi Ray, > >> > >>> On Jan 22, 2018, at 11:20 PM, Ray Tiley wrote: > >>> > >>> 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 > >> > >> Right, so my understanding was that allowing the ability to use both > luma > >> and chroma was a result of having less space in the VANC to hold data, > >> compared to HD resolutions where that is much less likely to be an > issue. > >> That said, I’ve never seen an implementation that actually puts it in > the > >> chroma. > >> > >>> > >>> Conversation is here: > >>> https://video-dev.slack.com/archives/C0XKDDH5Y/p151614155574 < > >> https://video-dev.slack.com/archives/C0XKDDH5Y/p151614155574> with > >>> kier...@obe.tv <mailto:kier...@obe.tv> who I believe is in the > >> ffmpeg-devel IRC. > >>> > >> > >> Ah, ok. That’s Kieran. He’s really knowledgable in this area, > although I > >> cannot see the conversation you’ve linked to as it seems that room is > only > >> accessible by people with email accounts from certain domains. > >> > >> Devin > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > Please find updated patch attatched. I reverted the vanc lines changes > and > > found that all my tests worked as expected, so not sure what was wrong w/ > > my original test. The need to extract vanc from the entire line vs just > the > > luma in NTSC is still required. > > Is interleaved VANC data is always the case for SD NTSC, or it depends on > the equipment? Maybe we should add some auto detection, and check for the > first VANC header. E.g. > > if (ctx->bmd_mode == bmdModeNTSC && > (*(uint32_t*)buf & 0x3 == 0x3fc00)) > unpack_v210 > else > unpack_luma_v210 > Sounds good to me. Will send patch shortly. > > Also, later on in the code, you only parse half of the decoded VANC. > If you decode from both the luma and chroma, get_metadata should be called > with frame width*2, no? > Good catch. I was testing with very small caption packets so I did not see it cut off. Will send patch shortly. > > Regards, > Marton > ___ > 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
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract NTSC VANC
On Sun, Jan 28, 2018 at 9:40 PM Ray Tiley wrote:
> This changes how NTSC VANC is extracted from the buffer. In NTSC the vanc
> data interleved between the uyvy and not just the luma as in
> high definition resolutions.
>
> In my testing this allows a decklink card encoding valid NTSC closed
> captions to pass the caption data to the x264 encoder.
>
> Updated with rewviews from Devon Heitmueller and Marton Balint.
>
> Signed-off-by: Ray Tiley
> ---
> libavdevice/decklink_dec.cpp | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index 94dae26..c7811eb 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -149,6 +149,30 @@ static void extract_luma_from_v210(uint16_t *dst,
> const uint8_t *src, int width)
> }
> }
>
> +static void unpack_v210(uint16_t *dst, const uint8_t *src, int width)
> +{
> +int i;
> +for (i = 0; i < width / 6; i++) {
> +*dst++ = src[0] + ((src[1] & 3) << 8);
> +*dst++ = (src[1] >> 2) + ((src[2] & 15) << 6);
> +*dst++ = (src[2] >> 4) + ((src[3] & 63) << 4);
> +
> +*dst++ = src[4] + ((src[5] & 3) << 8);
> +*dst++ = (src[5] >> 2) + ((src[6] & 15) << 6);
> +*dst++ = (src[6] >> 4) + ((src[7] & 63) << 4);
> +
> +*dst++ = src[8] + ((src[9] & 3) << 8);
> +*dst++ = (src[9] >> 2) + ((src[10] & 15) << 6);
> +*dst++ = (src[10] >> 4) + ((src[11] & 63) << 4);
> +
> +*dst++ = src[12] + ((src[13] & 3) << 8);
> +*dst++ = (src[13] >> 2) + ((src[14] & 15) << 6);
> +*dst++ = (src[14] >> 4) + ((src[15] & 63) << 4);
> +
> +src += 16;
> +}
> +}
> +
> static uint8_t calc_parity_and_line_offset(int line)
> {
> uint8_t ret = (line < 313) << 5;
> @@ -741,7 +765,11 @@ HRESULT
> decklink_input_callback::VideoInputFrameArrived(
> uint8_t *buf;
> if (vanc->GetBufferForVerticalBlankingLine(i,
> (void**)&buf) == S_OK) {
> uint16_t luma_vanc[MAX_WIDTH_VANC];
> -extract_luma_from_v210(luma_vanc, buf,
> videoFrame->GetWidth());
> +if (ctx->bmd_mode == bmdModeNTSC) {
> + unpack_v210(luma_vanc, buf,
> videoFrame->GetWidth());
> +} else {
> + extract_luma_from_v210(luma_vanc, buf,
> videoFrame->GetWidth());
> +}
> txt_buf = get_metadata(avctx, luma_vanc,
> videoFrame->GetWidth(),
> txt_buf,
> sizeof(txt_buf0) - (txt_buf - txt_buf0), &pkt);
> }
> --
> 2.7.4
>
>
Anything else I need to do for this patch?
Thanks
-ray
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract NTSC VANC
This changes how NTSC VANC is extracted from the buffer. In NTSC the vanc
data interleved between the uyvy and not just the luma as in
high definition resolutions.
In my testing this allows a decklink card encoding valid NTSC closed
captions to pass the caption data to the x264 encoder.
Updated with rewviews from Devon Heitmueller and Marton Balint.
Signed-off-by: Ray Tiley
---
libavdevice/decklink_dec.cpp | 37 ++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 94dae26..c3683bb 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -149,6 +149,30 @@ static void extract_luma_from_v210(uint16_t *dst, const
uint8_t *src, int width)
}
}
+static void unpack_v210(uint16_t *dst, const uint8_t *src, int width)
+{
+int i;
+for (i = 0; i < width / 6; i++) {
+*dst++ = src[0] + ((src[1] & 3) << 8);
+*dst++ = (src[1] >> 2) + ((src[2] & 15) << 6);
+*dst++ = (src[2] >> 4) + ((src[3] & 63) << 4);
+
+*dst++ = src[4] + ((src[5] & 3) << 8);
+*dst++ = (src[5] >> 2) + ((src[6] & 15) << 6);
+*dst++ = (src[6] >> 4) + ((src[7] & 63) << 4);
+
+*dst++ = src[8] + ((src[9] & 3) << 8);
+*dst++ = (src[9] >> 2) + ((src[10] & 15) << 6);
+*dst++ = (src[10] >> 4) + ((src[11] & 63) << 4);
+
+*dst++ = src[12] + ((src[13] & 3) << 8);
+*dst++ = (src[13] >> 2) + ((src[14] & 15) << 6);
+*dst++ = (src[14] >> 4) + ((src[15] & 63) << 4);
+
+src += 16;
+}
+}
+
static uint8_t calc_parity_and_line_offset(int line)
{
uint8_t ret = (line < 313) << 5;
@@ -740,9 +764,16 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
for (i = vanc_line_numbers[idx].vanc_start; i <=
vanc_line_numbers[idx].vanc_end; i++) {
uint8_t *buf;
if (vanc->GetBufferForVerticalBlankingLine(i,
(void**)&buf) == S_OK) {
-uint16_t luma_vanc[MAX_WIDTH_VANC];
-extract_luma_from_v210(luma_vanc, buf,
videoFrame->GetWidth());
-txt_buf = get_metadata(avctx, luma_vanc,
videoFrame->GetWidth(),
+uint16_t vanc[MAX_WIDTH_VANC];
+size_t vanc_size = videoFrame->GetWidth();
+if (ctx->bmd_mode == bmdModeNTSC &&
+videoFrame->GetWidth() * 2 <= MAX_WIDTH_VANC) {
+ vanc_size = vanc_size * 2;
+ unpack_v210(vanc, buf, videoFrame->GetWidth());
+} else {
+ extract_luma_from_v210(vanc, buf,
videoFrame->GetWidth());
+}
+txt_buf = get_metadata(avctx, vanc, vanc_size,
txt_buf, sizeof(txt_buf0) -
(txt_buf - txt_buf0), &pkt);
}
if (i == vanc_line_numbers[idx].field0_vanc_end)
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract NTSC VANC
On Mon, Feb 5, 2018 at 7:32 PM Marton Balint 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
[FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract NTSC VANC
This changes how NTSC VANC is extracted from the buffer. In NTSC the vanc
data interleved between the uyvy and not just the luma as in
high definition resolutions.
In my testing this allows a decklink card encoding valid NTSC closed
captions to pass the caption data to the x264 encoder.
Updated with rewviews from Devon Heitmueller and Marton Balint.
Signed-off-by: Ray Tiley
---
libavdevice/decklink_dec.cpp | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 5c116f2..c3bb46e 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -149,6 +149,17 @@ static void extract_luma_from_v210(uint16_t *dst, const
uint8_t *src, int width)
}
}
+static void unpack_v210(uint16_t *dst, const uint8_t *src, int width)
+{
+int i;
+for (i = 0; i < width * 2 / 3; i++) {
+*dst++ = src[0] + ((src[1] & 3) << 8);
+*dst++ = (src[1] >> 2) + ((src[2] & 15) << 6);
+*dst++ = (src[2] >> 4) + ((src[3] & 63) << 4);
+src += 4;
+}
+}
+
static uint8_t calc_parity_and_line_offset(int line)
{
uint8_t ret = (line < 313) << 5;
@@ -752,9 +763,15 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
for (i = vanc_line_numbers[idx].vanc_start; i <=
vanc_line_numbers[idx].vanc_end; i++) {
uint8_t *buf;
if (vanc->GetBufferForVerticalBlankingLine(i,
(void**)&buf) == S_OK) {
-uint16_t luma_vanc[MAX_WIDTH_VANC];
-extract_luma_from_v210(luma_vanc, buf,
videoFrame->GetWidth());
-txt_buf = get_metadata(avctx, luma_vanc,
videoFrame->GetWidth(),
+uint16_t vanc[MAX_WIDTH_VANC];
+size_t vanc_size = videoFrame->GetWidth();
+if (ctx->bmd_mode == bmdModeNTSC &&
videoFrame->GetWidth() * 2 <= MAX_WIDTH_VANC) {
+vanc_size = vanc_size * 2;
+unpack_v210(vanc, buf, videoFrame->GetWidth());
+} else {
+extract_luma_from_v210(vanc, buf,
videoFrame->GetWidth());
+}
+txt_buf = get_metadata(avctx, vanc, vanc_size,
txt_buf, sizeof(txt_buf0) -
(txt_buf - txt_buf0), &pkt);
}
if (i == vanc_line_numbers[idx].field0_vanc_end)
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
