[FFmpeg-devel] PATCH: examples/transcode_aac.c drain/flush to output
Example transocde_aac.c does not drain queue and write to output when
requested, resulting in "frames left in queue on closing" warning messages and
samples/frames lost.
$ ./transcode_aac foo.wav foo.aac
[aac @ 0x1e299c0] Qavg: 55159.750
[aac @ 0x1e299c0] 1 frames left in the queue on closing
An attempt to drain the Q exists (a loop calling encode_audio_frame() with a
NULL frame), but inside the function it mishandles the avcodec_send_frame()
return code, forcing it to cleanup upon EOF (due to the NULL frame) instead of
continuing to avcodec_recieve_frame() and av_write_frame().
Tested with transcode_aac and ffmpeg on the same input following patch to
confirm identifcal
$ ffmpeg -i foo.wav -ab 96k -ac 2 bar.aac
$ diff foo.aac bar.aac
From 321a4459c406b9fcb332a64bfac43f718f262309 Mon Sep 17 00:00:00 2001
From: whatdoineed2do/Ray
Date: Fri, 7 May 2021 17:23:56 +0100
Subject: [PATCH] Fixes mishandling of return code from avcodec_send_frame()
(EOF) when attempting to drain and flush all frames to output file.
Signed-off-by: whatdoineed2do/Ray
---
doc/examples/transcode_aac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/doc/examples/transcode_aac.c b/doc/examples/transcode_aac.c
index 711076b5a5..c9badaa561 100644
--- a/doc/examples/transcode_aac.c
+++ b/doc/examples/transcode_aac.c
@@ -685,7 +685,6 @@ static int encode_audio_frame(AVFrame *frame,
/* The encoder signals that it has nothing more to encode. */
if (error == AVERROR_EOF) {
error = 0;
- goto cleanup;
} else if (error < 0) {
fprintf(stderr, "Could not send packet for encoding (error '%s')\n",
av_err2str(error));
--
2.26.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH]: examples/transcode_aac.c - Do not use global pts for frame pts counting
The example transcode_aac.c uses a global pts for counting. For libavcodec
novices this can cause them to overlook this and result with incorrect "start"
times of output files if called multiple times (see user error resulting in bug
report https://trac.ffmpeg.org/ticket/9228)
From 52cbed063ee54e667905ca243e8ee4a811a108dc Mon Sep 17 00:00:00 2001
From: whatdoineed2do/Ray
Date: Tue, 11 May 2021 13:16:48 +0100
Subject: [PATCH] Do not use global pts for frame pts counting
Signed-off-by: whatdoineed2do/Ray
---
doc/examples/transcode_aac.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/doc/examples/transcode_aac.c b/doc/examples/transcode_aac.c
index c9badaa561..7f6148fa15 100644
--- a/doc/examples/transcode_aac.c
+++ b/doc/examples/transcode_aac.c
@@ -648,8 +648,6 @@ static int init_output_frame(AVFrame **frame,
return 0;
}
-/* Global timestamp for the audio frames. */
-static int64_t pts = 0;
/**
* Encode one frame worth of audio to the output file.
@@ -663,6 +661,7 @@ static int64_t pts = 0;
static int encode_audio_frame(AVFrame *frame,
AVFormatContext *output_format_context,
AVCodecContext *output_codec_context,
+ int64_t* pts,
int *data_present)
{
/* Packet used for temporary storage. */
@@ -675,8 +674,8 @@ static int encode_audio_frame(AVFrame *frame,
/* Set a timestamp based on the sample rate for the container. */
if (frame) {
- frame->pts = pts;
- pts += frame->nb_samples;
+ frame->pts = *pts;
+ *pts += frame->nb_samples;
}
/* Send the audio frame stored in the temporary packet to the encoder.
@@ -734,7 +733,8 @@ cleanup:
*/
static int load_encode_and_write(AVAudioFifo *fifo,
AVFormatContext *output_format_context,
- AVCodecContext *output_codec_context)
+ AVCodecContext *output_codec_context,
+ int64_t* pts)
{
/* Temporary storage of the output samples of the frame written to the
file. */
AVFrame *output_frame;
@@ -759,7 +759,7 @@ static int load_encode_and_write(AVAudioFifo *fifo,
/* Encode one frame worth of audio samples. */
if (encode_audio_frame(output_frame, output_format_context,
- output_codec_context, &data_written)) {
+ output_codec_context, pts, &data_written)) {
av_frame_free(&output_frame);
return AVERROR_EXIT;
}
@@ -790,6 +790,8 @@ int main(int argc, char **argv)
SwrContext *resample_context = NULL;
AVAudioFifo *fifo = NULL;
int ret = AVERROR_EXIT;
+ /* timestamp for the audio frames. */
+ int64_t pts = 0;
if (argc != 3) {
fprintf(stderr, "Usage: %s \n", argv[0]);
@@ -850,7 +852,7 @@ int main(int argc, char **argv)
/* Take one frame worth of audio samples from the FIFO buffer,
* encode it and write it to the output file. */
if (load_encode_and_write(fifo, output_format_context,
- output_codec_context))
+ output_codec_context, &pts))
goto cleanup;
/* If we are at the end of the input file and have encoded
@@ -861,7 +863,7 @@ int main(int argc, char **argv)
do {
data_written = 0;
if (encode_audio_frame(NULL, output_format_context,
- output_codec_context, &data_written))
+ output_codec_context, &pts,
&data_written))
goto cleanup;
} while (data_written);
break;
--
2.26.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] add color table for 8-bit gray scale raw image data
From: unknown <2010263...@qq.com>
---
libavformat/riffenc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index c04d55c423..e33bcdb339 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -242,6 +242,15 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecParameters
*par,
avio_wl32(pb, pal_avi ? 1 << par->bits_per_coded_sample : 0);
avio_wl32(pb, 0);
+ if (par->bits_per_coded_sample == 8) {
+ for(int i=0; i<256; i++) {
+ avio_w8(pb,i);
+ avio_w8(pb,i);
+ avio_w8(pb,i);
+ avio_w8(pb,0);
+ }
+ }
+
if (!ignore_extradata) {
if (par->extradata_size) {
avio_write(pb, par->extradata, extradata_size);
--
2.30.1 (Apple Git-130)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Handle AV_PIX_FMT_PAL8
---
libavformat/riffenc.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 971c4a7eb8..69761431da 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -250,15 +250,6 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecParameters
*par,
avio_wl32(pb, pal_avi ? 1 << par->bits_per_coded_sample : 0);
avio_wl32(pb, 0);
- if (par->bits_per_coded_sample == 8) {
- for(int i=0; i<256; i++) {
- avio_w8(pb,i);
- avio_w8(pb,i);
- avio_w8(pb,i);
- avio_w8(pb,0);
- }
- }
-
if (!ignore_extradata) {
if (par->extradata_size) {
avio_write(pb, par->extradata, extradata_size);
@@ -272,6 +263,13 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecParameters
*par,
avio_wl32(pb, 0xff);
else if (i == 1 && pix_fmt == AV_PIX_FMT_MONOBLACK)
avio_wl32(pb, 0xff);
+else if (pix_fmt == AV_PIX_FMT_PAL8) {
+/* Initialize 8 bpp palette */
+avio_w8(pb,i);
+ avio_w8(pb,i);
+ avio_w8(pb,i);
+ avio_w8(pb,0);
+}
else
avio_wl32(pb, 0);
}
--
2.30.1 (Apple Git-130)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Handle AV_PIX_FMT_PAL8
---
libavformat/riffenc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index c04d55c423..3171c152f0 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -255,6 +255,13 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecParameters
*par,
avio_wl32(pb, 0xff);
else if (i == 1 && pix_fmt == AV_PIX_FMT_MONOBLACK)
avio_wl32(pb, 0xff);
+else if (pix_fmt == AV_PIX_FMT_PAL8) {
+/* Initialize 8 bpp palette */
+avio_w8(pb,i);
+ avio_w8(pb,i);
+ avio_w8(pb,i);
+ avio_w8(pb,0);
+}
else
avio_wl32(pb, 0);
}
--
2.30.1 (Apple Git-130)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Handle AV_PIX_FMT_PAL8
---
libavformat/riffenc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 971c4a7eb8..6926fbf060 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -271,7 +271,14 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecParameters
*par,
if (i == 0 && pix_fmt == AV_PIX_FMT_MONOWHITE)
avio_wl32(pb, 0xff);
else if (i == 1 && pix_fmt == AV_PIX_FMT_MONOBLACK)
-avio_wl32(pb, 0xff);
+avio_wl32(pb, 0xff);
+else if (pix_fmt == AV_PIX_FMT_PAL8) {
+/* Initialize 8 bpp palette */
+avio_w8(pb,i);
+avio_w8(pb,i);
+avio_w8(pb,i);
+avio_w8(pb,0);
+}
else
avio_wl32(pb, 0);
}
--
2.30.1 (Apple Git-130)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/riffenc: support raw avi for raw PAL8 or Gray8 pixel data
This is a my latest committed patch. Please ignore those similar mails I sent
before.
> 2021年8月16日 下午5:01，rui.jiang <229135...@qq.com> 写道：
>
> add palette data in avi header when the input data is raw PAL8 or Gray8 pixel
> data and the output data is 8bit raw avi video;
>
> Signed-off-by: rui.jiang <229135...@qq.com>
> ---
> libavformat/riffenc.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
> index 43c8bf957a..bc654b3cd3 100644
> --- a/libavformat/riffenc.c
> +++ b/libavformat/riffenc.c
> @@ -228,7 +228,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecParameters
> *par,
> pal_avi = !for_asf &&
> (pix_fmt == AV_PIX_FMT_PAL8 ||
>pix_fmt == AV_PIX_FMT_MONOWHITE ||
> - pix_fmt == AV_PIX_FMT_MONOBLACK);
> + pix_fmt == AV_PIX_FMT_MONOBLACK ||
> + pix_fmt == AV_PIX_FMT_GRAY8);
>
> /* Size (not including the size of the color table or color masks) */
> avio_wl32(pb, 40 + (ignore_extradata || pal_avi ? 0 : extradata_size));
> @@ -263,6 +264,13 @@ void ff_put_bmp_header(AVIOContext *pb,
> AVCodecParameters *par,
> avio_wl32(pb, 0xff);
> else if (i == 1 && pix_fmt == AV_PIX_FMT_MONOBLACK)
> avio_wl32(pb, 0xff);
> +else if (pix_fmt == AV_PIX_FMT_PAL8 || pix_fmt ==
> AV_PIX_FMT_GRAY8) {
> +/* Initialize palette */
> +avio_w8(pb,i);
> +avio_w8(pb,i);
> +avio_w8(pb,i);
> +avio_w8(pb,0);
> +}
> else
> avio_wl32(pb, 0);
> }
> --
> 2.30.1 (Apple Git-130)
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/riffenc: support raw avi for raw PAL8 or Gray8 pixel data
is that I should only deal with gray8 format in particular？and it has passed
the fate test
> 2021年8月17日 上午3:00，Michael Niedermayer 写道：
>
> On Mon, Aug 16, 2021 at 05:01:14PM +0800, rui.jiang wrote:
>> add palette data in avi header when the input data is raw PAL8 or Gray8
>> pixel data and the output data is 8bit raw avi video;
>>
>> Signed-off-by: rui.jiang <229135...@qq.com>
>> ---
>> libavformat/riffenc.c | 10 +-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
>> index 43c8bf957a..bc654b3cd3 100644
>> --- a/libavformat/riffenc.c
>> +++ b/libavformat/riffenc.c
>> @@ -228,7 +228,8 @@ void ff_put_bmp_header(AVIOContext *pb,
>> AVCodecParameters *par,
>> pal_avi = !for_asf &&
>> (pix_fmt == AV_PIX_FMT_PAL8 ||
>>pix_fmt == AV_PIX_FMT_MONOWHITE ||
>> - pix_fmt == AV_PIX_FMT_MONOBLACK);
>> + pix_fmt == AV_PIX_FMT_MONOBLACK ||
>> + pix_fmt == AV_PIX_FMT_GRAY8);
>>
>> /* Size (not including the size of the color table or color masks) */
>> avio_wl32(pb, 40 + (ignore_extradata || pal_avi ? 0 : extradata_size));
>> @@ -263,6 +264,13 @@ void ff_put_bmp_header(AVIOContext *pb,
>> AVCodecParameters *par,
>> avio_wl32(pb, 0xff);
>> else if (i == 1 && pix_fmt == AV_PIX_FMT_MONOBLACK)
>> avio_wl32(pb, 0xff);
>> +else if (pix_fmt == AV_PIX_FMT_PAL8 || pix_fmt ==
>> AV_PIX_FMT_GRAY8) {
>> +/* Initialize palette */
>> +avio_w8(pb,i);
>> +avio_w8(pb,i);
>> +avio_w8(pb,i);
>> +avio_w8(pb,0);
>
> I dont think this will always match the palette
> also this is going to break fate i would assume
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Trying to ftp upload sample video
There doesn't appear to be enough detail for uploading a sample file by ftp. [image: Inline image 1] What are the values for *port* and *password* ? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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
Re: [FFmpeg-devel] Proposed vf_decimate enhancement
Quite honestly I decided it isn't worth the frustration of trying to submit a
patch. It works for me and I'm happy with it.
-- Ray
On 12/14/2015 03:19 PM, Michael Niedermayer wrote:
On Tue, Sep 29, 2015 at 11:02:33AM -0500, Ray Cole wrote:
Here is an updated patch. I cleaned the code up to hopefully be closer to
standards. It works well for me, but your mileage may vary...
--- vf_decimate.c 2015-09-29 10:56:46.171698492 -0500
+++ vf_decimatex.c 2015-09-29 10:59:50.679695685 -0500
a git patch with a commit message would be better
see:
git commit -a
git format-patch -1
[...]
@@ -51,6 +52,10 @@
int bdiffsize;
int64_t *bdiffs;
+/* Ray */
git keeps track of who changed what
+int lastdrop;
+int64_t drop_count[25]; // drop counts
The purpose of comments is to provide additional information not
already in the field name
+
/* options */
int cycle;
double dupthresh_flt;
@@ -60,6 +65,9 @@
int blockx, blocky;
int ppsrc;
int chroma;
+int force_drop;
+int lock_on;
+
} DecimateContext;
#define OFFSET(x) offsetof(DecimateContext, x)
@@ -71,9 +79,13 @@
{ "scthresh", "set scene change threshold", OFFSET(scthresh_flt),
AV_OPT_TYPE_DOUBLE, {.dbl = 15.0}, 0, 100, FLAGS },
{ "blockx","set the size of the x-axis blocks used during metric
calculations", OFFSET(blockx), AV_OPT_TYPE_INT, {.i64 = 32}, 4, 1<<9, FLAGS },
{ "blocky","set the size of the y-axis blocks used during metric
calculations", OFFSET(blocky), AV_OPT_TYPE_INT, {.i64 = 32}, 4, 1<<9, FLAGS },
-{ "ppsrc", "mark main input as a pre-processed input and activate clean
source input stream", OFFSET(ppsrc), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS },
+{ "ppsrc", "mark main input as a pre-processed input and activate clean
source input stream", OFFSET(ppsrc), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, FLAGS },
-{ "chroma","set whether or not chroma is considered in the metric
calculations", OFFSET(chroma), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
+{ "chroma","set whether or not chroma is considered in the metric
calculations", OFFSET(chroma), AV_OPT_TYPE_INT, {.i64=1}, 0, 1, FLAGS },
this looks like a unintended mistake
+{ "force_drop","set to forcefully drop frame X in cycle",
OFFSET(force_drop), AV_OPT_TYPE_INT, {.i64=-1}, -1, 4, FLAGS },
+{ "lock_on","set to lock on to a cycle", OFFSET(lock_on),
AV_OPT_TYPE_INT, {.i64=0}, 0, 1, FLAGS },
+
{ NULL }
+
};
AVFILTER_DEFINE_CLASS(decimate);
@@ -140,13 +152,15 @@
q->totdiff = 0;
for (i = 0; i < dm->bdiffsize; i++)
q->totdiff += bdiffs[i];
+
q->maxbdiff = maxdiff;
+
}
stray changes
please read your patch before submitting
static int filter_frame(AVFilterLink *inlink, AVFrame *in)
{
-int scpos = -1, duppos = -1;
-int drop = INT_MIN, i, lowest = 0, ret;
+int scpos = -1, duppos = -1, common = 0, start = 0;
+int drop = INT_MIN, i, lowest = 0, lowest_tot = 0, ret =0;
AVFilterContext *ctx = inlink->dst;
AVFilterLink *outlink = ctx->outputs[0];
DecimateContext *dm = ctx->priv;
@@ -176,17 +190,128 @@
dm->last = av_frame_clone(in);
dm->fid = 0;
+
+// The major change starts here
git keeps track of changes, theres no need to put such notes in
the source
[...]
@@ -372,6 +499,7 @@
fps = av_mul_q(fps, (AVRational){dm->cycle - 1, dm->cycle});
av_log(ctx, AV_LOG_VERBOSE, "FPS: %d/%d -> %d/%d\n",
inlink->frame_rate.num, inlink->frame_rate.den, fps.num, fps.den);
+outlink->flags |= FF_LINK_FLAG_REQUEST_LOOP;
this flag no longer exists
and please provide a commit message for the change which describes
what is changed, how and why
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Proposed vf_decimate enhancement
I hope this is the appropriate place to propose an enhancement. This is the
first time I've offered up code to any open source project...so be gentle :-)
First, I love ffmpeg. Wonderful software and thank you for your efforts.
I have been pulling down a number of movies back to 24 FPS (24000/1001) using
fieldmatch and decimate. However decimate seemed to drop incorrect frames from
time-to-time particularly on scenes with little motion. The pullup filter
likewise made poor decisions under similar circumstances.
So...I modified vf_decimate and it is working very well for me. I make no
claims that the enhancements would work for anyone else. My source is 1080i
29.97 fps movies recording from component video. I'm pulling down to 24 fps
(24000/1001 actually).
The changes are:
1) The total and max diffs are used to find the lowest frame to drop rather
than just the max diff. If these two methods disagree with one another then it
goes through a 'conflict resolution'. The conflict resolution checks to see if
either method matches the most commonly-dropped frame (a simple short-term
history of drops is retained for this purpose). If so, the most
commonly-dropped frame is assumed to be correct. If they do not match then it
uses the last dropped frame. This keeps the filter from varying the frame drop
so often and made a big difference in detection, at least with the stuff I'm
working with.
2) The existing vf_decimate allows frame 4 to be dropped immediately followed by frame 0
whereas frame 3 dropped could never be followed by frame 4 dropped - similar with frames
0 through 2. Having 2 frames in a row eligible to be dropped seems wrong and the biggest
issue I had was when the drop cycle was hitting frame 4. So I put in some code that says
if the last frame dropped was frame 4 then frame 0 and frame 1 is not eligible for drop.
If frame 3 was last dropped then frame 0 is not dropped. This enforces 2 undropped frames
between drops. I'm not "married" to this...but it did help quite a bit.
3) I had one movie where frame 4 was ALWAYS the correct frame to drop...so I
added an option to 'lock on' to a pattern in 1 of 2 ways. The first way is for
someone to pass force_drop=x where x is the frame number to drop each time. The
other is passing lock_on=1 to tell it to figure out what frame it should lock
onto. I mainly used this to assist in finding places where the code was
dropping incorrect frames. I'm not sure I really consider this 'useful' for
anything other than such testing where you know what should be dropped. It
still goes through all the computations as before but insists on dropping the
specified frame and noting if the computations resulted in a different frame
than requested.
I realize the attached code needs cleanup to conform to standards but I just
wanted to put it up for discussion. The first change above is really the major
change and it could (obviously) be enabled/disabled by an option to decimate if
desired.
-- Ray Cole
/*
* Copyright (c) 2012 Fredrik Mellbin
* Copyright (c) 2013 Clément BÅsch
*
* This file is part of FFmpeg.
*
* FFmpeg is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* FFmpeg is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with FFmpeg; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
#include "libavutil/timestamp.h"
#include "avfilter.h"
#include "internal.h"
#define INPUT_MAIN 0
#define INPUT_CLEANSRC 1
struct qitem {
AVFrame *frame;
int64_t maxbdiff;
int64_t totdiff;
};
typedef struct {
const AVClass *class;
struct qitem *queue;///< window of cycle frames and the associated data diff
int fid;///< current frame id in the queue
int filled; ///< 1 if the queue is filled, 0 otherwise
AVFrame *last; ///< last frame from the previous queue
AVFrame **clean_src;///< frame queue for the clean source
int got_frame[2]; ///< frame request flag for each input stream
double ts_unit; ///< timestamp units for the output frames
int64_t start_pts; ///< base for output timestamps
uint32_t eof; ///< bitmask for end of stream
int hsub, vsub; ///< chroma subsampling values
i
Re: [FFmpeg-devel] Proposed vf_decimate enhancement
Thank you. I know I have a number of coding style things to clean up before this could be accepted (as well as removing some output I'm logging as info) but perhaps those familiar with the decimate filter can see if the changes being proposed make sense. -- Ray On 09/29/2015 07:32 AM, compn wrote: On Mon, 28 Sep 2015 21:31:59 -0500 Ray Cole wrote: This is the first time I've offered up code to any open source project...so be gentle :-) ehe, patches are what the devs want, either git diff or diff -u... i've downloaded and diff'ed your filter to ffmpeg git master and attached it in this mail. -compn ___ 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] Proposed vf_decimate enhancement
Here is an updated patch. I cleaned the code up to hopefully be closer to
standards. It works well for me, but your mileage may vary...
--- vf_decimate.c 2015-09-29 10:56:46.171698492 -0500
+++ vf_decimatex.c 2015-09-29 10:59:50.679695685 -0500
@@ -27,6 +27,7 @@
#define INPUT_MAIN 0
#define INPUT_CLEANSRC 1
+#define DROP_HISTORY 8
struct qitem {
AVFrame *frame;
@@ -51,6 +52,10 @@
int bdiffsize;
int64_t *bdiffs;
+/* Ray */
+int lastdrop;
+int64_t drop_count[25]; // drop counts
+
/* options */
int cycle;
double dupthresh_flt;
@@ -60,6 +65,9 @@
int blockx, blocky;
int ppsrc;
int chroma;
+int force_drop;
+int lock_on;
+
} DecimateContext;
#define OFFSET(x) offsetof(DecimateContext, x)
@@ -71,9 +79,13 @@
{ "scthresh", "set scene change threshold", OFFSET(scthresh_flt),
AV_OPT_TYPE_DOUBLE, {.dbl = 15.0}, 0, 100, FLAGS },
{ "blockx","set the size of the x-axis blocks used during metric
calculations", OFFSET(blockx), AV_OPT_TYPE_INT, {.i64 = 32}, 4, 1<<9, FLAGS },
{ "blocky","set the size of the y-axis blocks used during metric
calculations", OFFSET(blocky), AV_OPT_TYPE_INT, {.i64 = 32}, 4, 1<<9, FLAGS },
-{ "ppsrc", "mark main input as a pre-processed input and activate
clean source input stream", OFFSET(ppsrc), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1,
FLAGS },
-{ "chroma","set whether or not chroma is considered in the metric
calculations", OFFSET(chroma), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
+{ "ppsrc", "mark main input as a pre-processed input and activate
clean source input stream", OFFSET(ppsrc), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
FLAGS },
+{ "chroma","set whether or not chroma is considered in the metric
calculations", OFFSET(chroma), AV_OPT_TYPE_INT, {.i64=1}, 0, 1, FLAGS },
+{ "force_drop","set to forcefully drop frame X in cycle",
OFFSET(force_drop), AV_OPT_TYPE_INT, {.i64=-1}, -1, 4, FLAGS },
+{ "lock_on","set to lock on to a cycle", OFFSET(lock_on),
AV_OPT_TYPE_INT, {.i64=0}, 0, 1, FLAGS },
+
{ NULL }
+
};
AVFILTER_DEFINE_CLASS(decimate);
@@ -140,13 +152,15 @@
q->totdiff = 0;
for (i = 0; i < dm->bdiffsize; i++)
q->totdiff += bdiffs[i];
+
q->maxbdiff = maxdiff;
+
}
static int filter_frame(AVFilterLink *inlink, AVFrame *in)
{
-int scpos = -1, duppos = -1;
-int drop = INT_MIN, i, lowest = 0, ret;
+int scpos = -1, duppos = -1, common = 0, start = 0;
+int drop = INT_MIN, i, lowest = 0, lowest_tot = 0, ret =0;
AVFilterContext *ctx = inlink->dst;
AVFilterLink *outlink = ctx->outputs[0];
DecimateContext *dm = ctx->priv;
@@ -176,17 +190,128 @@
dm->last = av_frame_clone(in);
dm->fid = 0;
+
+// The major change starts here
+
+// First we will NOT consider the 'next' frame in the drop detection because
that would be wrong.
+// The old code would allow frame 0 to be dropped immediately after frame 4.
I've not seen a case where that makes sense and
+// frame 0 could never be followed by a drop of 1, nor could frame 1 be
followed by 2, etc. because of the way detection is
+// performed 5 frames at a time. So first we start at what _should_ be a
reasonable point to be closer inline with what can
+// happen when frames 0, 1 and 2 are the drops.
+
+start = 0;
+
+if (dm->lastdrop == (dm->cycle - 1))
+ start = 2;
+else
+if (dm->lastdrop == (dm->cycle - 2))
+ start = 1;
+
/* we have a complete cycle, select the frame to drop */
-lowest = 0;
+lowest = start;
+lowest_tot = start;
+
+// We will now locate the lowest frame by diff and by total.
+
for (i = 0; i < dm->cycle; i++) {
if (dm->queue[i].totdiff > dm->scthresh)
scpos = i;
-if (dm->queue[i].maxbdiff < dm->queue[lowest].maxbdiff)
-lowest = i;
+
+if (i >= start || scpos >= 0) {// if in range of eligible for
pattern drop
+if (dm->queue[lowest].maxbdiff == 0 ||
+dm->queue[i].maxbdiff < dm->queue[lowest].maxbdiff)
+
+lowest = i;
+
+if (dm->queue[lowest_tot].totdiff == 0 ||
+dm->queue[i].totdiff < dm->queue[lowest_tot].totdiff)
+
+lowest_tot = i;
+}
+
}
+
if (dm->queue[lowest].maxbdiff < dm->dupthresh)
duppos = lowest;
-drop = scpos >= 0 && duppos < 0 ? scpos : lowest;
+
+// If the lowest from by max
