Re: [FFmpeg-devel] [PATCH] libavformat/cdg: unset duration on packets
On 13/02/2019 16:28, Carl Eugen Hoyos wrote: Thanks for testing my patch. I wasn't aware of this specific test, sorry about that. What would be the proper way to address this? Should the fate reference be updated? Yes, unless the change is wrong. Ok thanks. So, who should I ask to review this patch and update the reference then? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, RFC] lavf/deinterlace_qsv: set TFF or BFF together with progressive
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Saturday, February 16, 2019 3:50 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH, RFC] lavf/deinterlace_qsv: set TFF or BFF
> together with progressive
>
> Currently, BFF or TFF will not be set if the frame is progressive.
> This will break the Input PicStruct check in MSDK because of absence of the
> specific PicStruct check for:
> MFX_PICSTRUCT_PROGRESSIVE | MFX_PICSTRUCT_FIELD_REPEATED
>
> Set PicStruct to MFX_PICSTRUCT_FIELD_TFF or MFX_PICSTRUCT_FIELD_BFF
> to match the CheckInputPicStruct in MSDK.
>
> Fix #7701.
After checking this ticket, I believe this is not a MSDK issue, and current fix
in this patch is not correct.
If I understand correctly, this issue only happens when H264 pic_struct = 5 or
6.
In this case, MFX_PICSTRUCT_FIELD_TFF or MFX_PICSTRUCT_FIELD_BFF should be set,
else we don't know which filed should be repeated.
> Signed-off-by: Linjie Fu
> ---
> Is it acceptable to add the TFF or BFF to PicStruct according to the attribute
> of the input frames, even if it's not interlaced?
> Or it should be fixed in MSDK level to support more PicStruct?
>
> libavfilter/vf_deinterlace_qsv.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_deinterlace_qsv.c
> b/libavfilter/vf_deinterlace_qsv.c
> index d6b02e98c5..f03d65f029 100644
> --- a/libavfilter/vf_deinterlace_qsv.c
> +++ b/libavfilter/vf_deinterlace_qsv.c
> @@ -417,8 +417,9 @@ static int submit_frame(AVFilterContext *ctx,
> AVFrame *frame,
> qf->surface.Info.CropH = qf->frame->height;
>
> qf->surface.Info.PicStruct = !qf->frame->interlaced_frame ?
> MFX_PICSTRUCT_PROGRESSIVE :
> - (qf->frame->top_field_first ?
> MFX_PICSTRUCT_FIELD_TFF :
> -
> MFX_PICSTRUCT_FIELD_BFF);
> +
> MFX_PICSTRUCT_UNKNOWN;
> +qf->surface.Info.PicStruct |= qf->frame->top_field_first ?
> MFX_PICSTRUCT_FIELD_TFF :
> +
> + MFX_PICSTRUCT_FIELD_BFF;
> if (qf->frame->repeat_pict == 1)
> qf->surface.Info.PicStruct |= MFX_PICSTRUCT_FIELD_REPEATED;
I believe the correct fix should be here (previous code change is not needed
and should be removed):
if (qf->frame->repeat_pict == 1) {
qf->surface.Info.PicStruct |= MFX_PICSTRUCT_FIELD_REPEATED;
qf->surface.Info.PicStruct |= qf->frame->top_field_first ?
MFX_PICSTRUCT_FIELD_TFF : MFX_PICSTRUCT_FIELD_BFF;
}
> else if (qf->frame->repeat_pict == 2)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a specific decode format
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Friday, November 16, 2018 16:37
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a
> specific decode format
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Mark Thompson
> > Sent: Thursday, November 15, 2018 05:48
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a
> > specific decode format
> >
> > On 14/11/18 01:35, Fu, Linjie wrote:
> > >> -Original Message-
> > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > >> Of Mark Thompson
> > >> Sent: Wednesday, November 14, 2018 09:11
> > >> To: ffmpeg-devel@ffmpeg.org
> > >> Subject: Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a
> > >> specific decode format
> > >>
> > >> On 14/11/18 00:50, Fu, Linjie wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > >> Behalf
> > Of Mark Thompson
> > Sent: Wednesday, November 14, 2018 07:44
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a
> > >> specific
> > decode format
> >
> > Fixes #7519.
> > ---
> > doc/ffmpeg.texi | 13
> > fftools/ffmpeg.c | 10 ++
> > fftools/ffmpeg.h | 4
> > fftools/ffmpeg_opt.c | 47
> >
> > 4 files changed, 74 insertions(+)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index 3717f22d42..d127bc0f0d 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -920,6 +920,19 @@ would be more efficient.
> > When doing stream copy, copy also non-key frames found at the
> > beginning.
> >
> > +@item -decode_format[:@var{stream_specifier}]
> > @var{pixfmt}[,@var{pixfmt}...] (@emph{input,per-stream})
> > +Set the possible output formats to be used by the decoder for this
> > >> stream.
> > +If the decoder does not natively support any format in the given list
> > for
> > +the input stream then decoding will fail rather than continuing with a
> > +different format.
> > +
> > +In general this should not be set - the decoder will select an output
> > +format based on the input stream parameters and available
> > components,
> > and
> > +that will be automatically converted to whatever the output
> requires.
> > It
> > +may be useful to force a hardware decoder supporting output in
> > >> multiple
> > +different memory types to pick a desired one, or to ensure that a
> > >> hardware
> > +decoder is used when software fallback is also available.
> > +
> > @item -init_hw_device
> > @var{type}[=@var{name}][:@var{device}[,@var{key=value}...]]
> > Initialise a new hardware device of type @var{type} called
> > @var{name},
> > using the
> > given device parameters.
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 38c21e944a..c651c8d3a8 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -598,6 +598,7 @@ static void ffmpeg_cleanup(int ret)
> > avsubtitle_free(>prev_sub.subtitle);
> > av_frame_free(>sub2video.frame);
> > av_freep(>filters);
> > +av_freep(>decode_formats);
> > av_freep(>hwaccel_device);
> > av_freep(>dts_buffer);
> >
> > @@ -2800,6 +2801,15 @@ static enum AVPixelFormat
> > get_format(AVCodecContext *s, const enum AVPixelFormat
> > const AVCodecHWConfig *config = NULL;
> > int i;
> >
> > +if (ist->decode_formats) {
> > +for (i = 0; ist->decode_formats[i] != AV_PIX_FMT_NONE;
> > i++)
> {
> > +if (ist->decode_formats[i] == *p)
> > +break;
> > +}
> > +if (ist->decode_formats[i] != *p)
> > +continue;
> > +}
> > +
> > if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))
> > break;
> >
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index eb1eaf6363..b06fd18b1c 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -125,6 +125,8 @@ typedef struct OptionsContext {
> > intnb_ts_scale;
> > SpecifierOpt *dump_attachment;
> > intnb_dump_attachment;
> > +SpecifierOpt *decode_formats;
> > +intnb_decode_formats;
> > SpecifierOpt *hwaccels;
> > intnb_hwaccels;
> > SpecifierOpt
Re: [FFmpeg-devel] [PATCH v5] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
Thanks. Seems I need to cover external samples either > -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Michael Niedermayer > Sent: Saturday, February 16, 2019 5:22 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v5] Improved the performance of 1 > decode + N filter graphs and adaptive bitrate. > > On Fri, Feb 15, 2019 at 04:54:23PM -0500, Shaofei Wang wrote: > > It enabled multiple filter graph concurrency, which bring above about > > 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration > > > > Below are some test cases and comparison as reference. > > (Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz) > > (Software: Intel iHD driver - 16.9.00100, CentOS 7) > > breaks fate > > make -j12 fate-filter-overlay-dvdsub-2397 V=2 > > > frame= 208 fps=0.0 q=-0.0 Lsize= 48kB time=00:00:08.04 bitrate= > 49.0kbits/s speed=10.6x > video:105300kB audio:1254kB subtitle:0kB other streams:0kB global > headers:0kB muxing overhead: unknown pthread_join failed with error: No > such process Aborted (core dumped) > make: *** [fate-filter-overlay-dvdsub-2397] Error 134 > > [...] > -- > Michael GnuPG fingerprint: > 9FF2128B147EF6730BADF133611EC787040B0FAB > > Asymptotically faster algorithms should always be preferred if you have > asymptotical amounts of data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, RFC] lavf/deinterlace_qsv: set TFF or BFF together with progressive
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Friday, February 15, 2019 20:46 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, RFC] lavf/deinterlace_qsv: set TFF or > BFF together with progressive > > 2019-02-15 20:50 GMT+01:00, Linjie Fu : > > Currently, BFF or TFF will not be set if the frame is progressive. > > This will break the Input PicStruct check in MSDK > > Was this always documented? > > If not - given that this is completely counterintuitive - this should > be fixed in the driver. > I agree that this should be fixed first in the driver or MSDK. However, in order to be more robust, I think it might be possible to make this modification in ffmpeg qsv too. This will help if the user is using an earlier version of the MSDK/driver. --- Linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] lavf/mpeg: fix indent
On 2/17/19 2:06 AM, Michael Niedermayer wrote:
> On Fri, Feb 15, 2019 at 01:48:04AM +, Morris Stock wrote:
>> mpeg.c | 56
>> 1 file changed, 28 insertions(+), 28 deletions(-)
>> 2c6d9fc35eaf3f348761d553ec3029275709acba 0001-lavf-mpeg-fix-indent.patch
>> From 2a2dc1dd417a78650675f327f6db832e58e229a8 Mon Sep 17 00:00:00 2001
>> From: wxf
>> Date: Fri, 15 Feb 2019 09:41:29 +0800
>> Subject: [PATCH] lavf/mpeg: fix indent
>>
>> Signed-off-by: wxf
>> ---
>> libavformat/mpeg.c | 56
>> +++---
>> 1 file changed, 28 insertions(+), 28 deletions(-)
>
> LGTM, if the 3 letter author name is Intended instead of a full name
>
Ah, yes, but seems no one else use short name, see new attachment, thanks.
> [...]
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From 80ec71bf54f3b29169d5eb0a9375a11ceef8e692 Mon Sep 17 00:00:00 2001
From: Xiaofeng Wang
Date: Mon, 18 Feb 2019 09:16:58 +0800
Subject: [PATCH] lavf/mpeg: fix indent
Signed-off-by: Xiaofeng Wang
---
libavformat/mpeg.c | 56 +++---
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index d4369b49c2..c147fa72ed 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -525,34 +525,34 @@ redo:
}
es_type = m->psm_es_type[startcode & 0xff];
-if (es_type == STREAM_TYPE_VIDEO_MPEG1) {
-codec_id = AV_CODEC_ID_MPEG2VIDEO;
-type = AVMEDIA_TYPE_VIDEO;
-} else if (es_type == STREAM_TYPE_VIDEO_MPEG2) {
-codec_id = AV_CODEC_ID_MPEG2VIDEO;
-type = AVMEDIA_TYPE_VIDEO;
-} else if (es_type == STREAM_TYPE_AUDIO_MPEG1 ||
- es_type == STREAM_TYPE_AUDIO_MPEG2) {
-codec_id = AV_CODEC_ID_MP3;
-type = AVMEDIA_TYPE_AUDIO;
-} else if (es_type == STREAM_TYPE_AUDIO_AAC) {
-codec_id = AV_CODEC_ID_AAC;
-type = AVMEDIA_TYPE_AUDIO;
-} else if (es_type == STREAM_TYPE_VIDEO_MPEG4) {
-codec_id = AV_CODEC_ID_MPEG4;
-type = AVMEDIA_TYPE_VIDEO;
-} else if (es_type == STREAM_TYPE_VIDEO_H264) {
-codec_id = AV_CODEC_ID_H264;
-type = AVMEDIA_TYPE_VIDEO;
-} else if (es_type == STREAM_TYPE_VIDEO_HEVC) {
-codec_id = AV_CODEC_ID_HEVC;
-type = AVMEDIA_TYPE_VIDEO;
-} else if (es_type == STREAM_TYPE_AUDIO_AC3) {
-codec_id = AV_CODEC_ID_AC3;
-type = AVMEDIA_TYPE_AUDIO;
-} else if (m->imkh_cctv && es_type == 0x91) {
-codec_id = AV_CODEC_ID_PCM_MULAW;
-type = AVMEDIA_TYPE_AUDIO;
+if (es_type == STREAM_TYPE_VIDEO_MPEG1) {
+codec_id = AV_CODEC_ID_MPEG2VIDEO;
+type = AVMEDIA_TYPE_VIDEO;
+} else if (es_type == STREAM_TYPE_VIDEO_MPEG2) {
+codec_id = AV_CODEC_ID_MPEG2VIDEO;
+type = AVMEDIA_TYPE_VIDEO;
+} else if (es_type == STREAM_TYPE_AUDIO_MPEG1 ||
+ es_type == STREAM_TYPE_AUDIO_MPEG2) {
+codec_id = AV_CODEC_ID_MP3;
+type = AVMEDIA_TYPE_AUDIO;
+} else if (es_type == STREAM_TYPE_AUDIO_AAC) {
+codec_id = AV_CODEC_ID_AAC;
+type = AVMEDIA_TYPE_AUDIO;
+} else if (es_type == STREAM_TYPE_VIDEO_MPEG4) {
+codec_id = AV_CODEC_ID_MPEG4;
+type = AVMEDIA_TYPE_VIDEO;
+} else if (es_type == STREAM_TYPE_VIDEO_H264) {
+codec_id = AV_CODEC_ID_H264;
+type = AVMEDIA_TYPE_VIDEO;
+} else if (es_type == STREAM_TYPE_VIDEO_HEVC) {
+codec_id = AV_CODEC_ID_HEVC;
+type = AVMEDIA_TYPE_VIDEO;
+} else if (es_type == STREAM_TYPE_AUDIO_AC3) {
+codec_id = AV_CODEC_ID_AC3;
+type = AVMEDIA_TYPE_AUDIO;
+} else if (m->imkh_cctv && es_type == 0x91) {
+codec_id = AV_CODEC_ID_PCM_MULAW;
+type = AVMEDIA_TYPE_AUDIO;
} else if (startcode >= 0x1e0 && startcode <= 0x1ef) {
static const unsigned char avs_seqh[4] = { 0, 0, 1, 0xb0 };
unsigned char buf[8];
--
2.16.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/mjpegdec: Fix stereo3d memleak
Fixes:
12937/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-5714945346371584
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 902b8eb7cb..e82c185433 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1903,6 +1903,7 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
type = get_bits(>gb, 8);
len -= 4;
+av_freep(>stereo3d);
s->stereo3d = av_stereo3d_alloc();
if (!s->stereo3d) {
goto out;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/arbc: Check nb_tiles against dimensions
Fixes: Timeout
Fixes:
12967/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARBC_fuzzer-5639021454163968
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/arbc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
index 4558304f12..841a9f10ac 100644
--- a/libavcodec/arbc.c
+++ b/libavcodec/arbc.c
@@ -45,6 +45,9 @@ static void fill_tile4(AVCodecContext *avctx, uint8_t *color,
AVFrame *frame)
int nb_tiles = bytestream2_get_le16(gb);
int h = avctx->height - 1;
+if ((avctx->width / 4 + 1) * (avctx->height / 4 + 1) < nb_tiles)
+return;
+
for (int i = 0; i < nb_tiles; i++) {
int y = bytestream2_get_byte(gb);
int x = bytestream2_get_byte(gb);
@@ -79,6 +82,9 @@ static void fill_tileX(AVCodecContext *avctx, int tile_width,
int tile_height,
int nb_tiles = bytestream2_get_le16(gb);
int h = avctx->height - 1;
+if ((avctx->width / tile_width + 1) * (avctx->height / tile_height + 1) <
nb_tiles)
+return;
+
for (int i = 0; i < nb_tiles; i++) {
int y = bytestream2_get_byte(gb);
int x = bytestream2_get_byte(gb);
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] palettegen: Fill with last color, not black
tor 2019-01-17 klockan 11:14 +0100 skrev Michael Niedermayer:
> On Thu, Jan 17, 2019 at 09:44:47AM +0100, Clément Bœsch wrote:
> > On Wed, Jan 16, 2019 at 01:40:20PM +0100, Tomas Härdin wrote:
> > > Hi
> > >
> > > I was helping the fine folks at peppercarrot.com with web video
> > > nonsense, and I notice palettegen outputs more colors than it
> > > should
> > > due to padding the generated palette with pure black.
> > >
> > > Compare this (ffmpeg version 3.2.12-1~deb9u1):
> > > http://www.härdin.se/files/peppercarrot_gif/output-blackspecks-64
> > > .gif
> > > with this (282a471 with this patch applied):
> > > http://www.härdin.se/files/peppercarrot_gif/output-fixed-64.gif
> > >
> > > The attached patch fixes this by padding with the last color
> > > instead of
> > > black.
> > >
> > > /Tomas
> > > From 3a01f62fdcc95cc7afaf5aa6e439b8742cce43bc Mon Sep 17 00:00:00
> > > 2001
> > > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
> > > Date: Wed, 16 Jan 2019 13:07:48 +0100
> > > Subject: [PATCH] palettegen: Fill with last color, not black
> > >
> > > If we fill with black then the generated palette will have one
> > > color more
> > > than what the user requested. This also resulted in unwanted
> > > black specks in
> > > the output of paletteuse, especially when generating small
> > > palettes.
> > > ---
> > > libavfilter/vf_palettegen.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavfilter/vf_palettegen.c
> > > b/libavfilter/vf_palettegen.c
> > > index 5ff73e6b2b..44323782d2 100644
> > > --- a/libavfilter/vf_palettegen.c
> > > +++ b/libavfilter/vf_palettegen.c
> > > @@ -245,7 +245,7 @@ static void write_palette(AVFilterContext
> > > *ctx, AVFrame *out)
> > > av_log(ctx, AV_LOG_WARNING, "Dupped color:
> > > %08"PRIX32"\n", pal[x]);
> > > last_color = pal[x];
> > > } else {
> > > -pal[x] = 0xff00; // pad with black
> > > +pal[x] = last_color; // pad with last color
> > > }
> > > }
> > > pal += pal_linesize;
> >
> > Code LGTM, thanks
> >
> > No FATE change?
>
> --- ./tests/ref/fate/filter-palettegen-2 2019-01-15
> 01:24:17.53094 +0100
> +++ tests/data/fate/filter-palettegen-2 2019-01-17
> 11:13:21.077198948 +0100
> @@ -3,4 +3,4 @@
> #codec_id 0: rawvideo
> #dimensions 0: 16x16
> #sar 0: 1/1
> -0, 0, 0,1, 1024, 0x906ff5aa
> +0, 0, 0,1, 1024, 0x23e072c8
> Test filter-palettegen-2 failed. Look at tests/data/fate/filter-
> palettegen-2.err for details.
> make: *** [fate-filter-palettegen-2] Error 1
Finally got around to fixing this. Updated patch attached, passes FATE
for me. I'll push in a day or two
/TomasFrom 20b5a4dfe58496eb8dc603b279e17b8fec07 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 16 Jan 2019 13:07:48 +0100
Subject: [PATCH] palettegen: Fill with last color, not black
If we fill with black then the generated palette will have one color more
than what the user requested. This also resulted in unwanted black specks in
the output of paletteuse, especially when generating small palettes.
---
libavfilter/vf_palettegen.c| 2 +-
tests/ref/fate/filter-palettegen-2 | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
index 5ff73e6b2b..44323782d2 100644
--- a/libavfilter/vf_palettegen.c
+++ b/libavfilter/vf_palettegen.c
@@ -245,7 +245,7 @@ static void write_palette(AVFilterContext *ctx, AVFrame *out)
av_log(ctx, AV_LOG_WARNING, "Dupped color: %08"PRIX32"\n", pal[x]);
last_color = pal[x];
} else {
-pal[x] = 0xff00; // pad with black
+pal[x] = last_color; // pad with last color
}
}
pal += pal_linesize;
diff --git a/tests/ref/fate/filter-palettegen-2 b/tests/ref/fate/filter-palettegen-2
index aa07b6cb93..9abec0fe8e 100644
--- a/tests/ref/fate/filter-palettegen-2
+++ b/tests/ref/fate/filter-palettegen-2
@@ -3,4 +3,4 @@
#codec_id 0: rawvideo
#dimensions 0: 16x16
#sar 0: 1/1
-0, 0, 0,1, 1024, 0x906ff5aa
+0, 0, 0,1, 1024, 0x23e072c8
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add mapping for AC-4 in MP4
On 2/17/19, James Almer wrote:
> On 2/17/2019 6:14 PM, Paul B Mahol wrote:
>> On 2/17/19, Carl Eugen Hoyos wrote:
>>> 2019-02-17 21:50 GMT+01:00, Paul B Mahol :
On 2/17/19, Carl Eugen Hoyos wrote:
> 2019-02-17 21:25 GMT+01:00, Paul B Mahol :
>> Signed-off-by: Paul B Mahol
>> ---
>> libavformat/isom.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>> index 0a4d901be5..0052db539e 100644
>> --- a/libavformat/isom.c
>> +++ b/libavformat/isom.c
>
>> +{ AV_CODEC_ID_AC4, MKTAG('a', 'c', '-', '4') },
>> /* ETSI TS 103 190 */
>
> Are there no codec-specific atoms needed when remuxing ac-4?
They are completely optional and not needed for decoding or remuxing.
>>>
>>> Thank you for the explanation!
>>> Do we already have samples?
>>>
>>
>> http://testassets.dashif.org/#feature/details/586fb3879ae9045678eab593
>
> There's a dac4 atom inside the Audio Sample Entry, much like AC-3 has a
> dac3 and EAC-3 a dec3 atom.
> Are you sure it's optional? Codec specific atoms inside the stream's
> Video/Audio Sample Entry tend to be obligatory.
From specification:
The ac4_dsi shall not be used to configure the AC-4 decoder. The AC-4
decoder shall obtain its configuration only
from ac4_toc , which is part of every sample.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add mapping for AC-4 in MP4
On 2/17/2019 6:14 PM, Paul B Mahol wrote:
> On 2/17/19, Carl Eugen Hoyos wrote:
>> 2019-02-17 21:50 GMT+01:00, Paul B Mahol :
>>> On 2/17/19, Carl Eugen Hoyos wrote:
2019-02-17 21:25 GMT+01:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol
> ---
> libavformat/isom.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index 0a4d901be5..0052db539e 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> +{ AV_CODEC_ID_AC4, MKTAG('a', 'c', '-', '4') },
> /* ETSI TS 103 190 */
Are there no codec-specific atoms needed when remuxing ac-4?
>>>
>>> They are completely optional and not needed for decoding or remuxing.
>>
>> Thank you for the explanation!
>> Do we already have samples?
>>
>
> http://testassets.dashif.org/#feature/details/586fb3879ae9045678eab593
There's a dac4 atom inside the Audio Sample Entry, much like AC-3 has a
dac3 and EAC-3 a dec3 atom.
Are you sure it's optional? Codec specific atoms inside the stream's
Video/Audio Sample Entry tend to be obligatory.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Lossy GIF encoding
fre 2019-02-15 klockan 16:45 + skrev Kornel: > > > Alternatively, would it be OK to create a separate codec just for > > > lossy compression? I would create a new GIF codec, define it under a > > > new name, and declare it always takes AV_PIX_FMT_RGB24 or > > > AV_PIX_FMT_RGBA. Is that a good approach? > > > > This sounds more like something that belongs in libswscale (RGBA -> > > PAL8 conversion) or could be done with a filter. An option like > > ImageMagick's -fuzz could be added to the PAL8 quantizer in sws > > Unfortunately, the lossy technique depends on a layering violation. > > The lossy compression alters each pixel in the image based on > current, precise state of the LZW dictionary. Without doing both LZW > and remapping at the same time I don't have information required to > make the image optimally compressible. > > At best I could simulate LZW compression in swscale just for the > purpose of remapping/dithering filter, and then expect the GIF codec > to LZW-compress the remapped image again. However, that approach > doesn't work in practice: the second LZW encoder pass ends up making > different decisions than the first one, falls out of sync with the > optimal lossy pattern, and ends up creating a large file. > > Given the constraint of true-color input and LZW integrated in one > algorithm, where's the best place to put that code? Aha. Yeah then a different encoder would be the appropriate solution. It's neat that you can do this with LZW /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add mapping for AC-4 in MP4
On 2/17/19, Carl Eugen Hoyos wrote:
> 2019-02-17 21:50 GMT+01:00, Paul B Mahol :
>> On 2/17/19, Carl Eugen Hoyos wrote:
>>> 2019-02-17 21:25 GMT+01:00, Paul B Mahol :
Signed-off-by: Paul B Mahol
---
libavformat/isom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 0a4d901be5..0052db539e 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
>>>
+{ AV_CODEC_ID_AC4, MKTAG('a', 'c', '-', '4') },
/* ETSI TS 103 190 */
>>>
>>> Are there no codec-specific atoms needed when remuxing ac-4?
>>
>> They are completely optional and not needed for decoding or remuxing.
>
> Thank you for the explanation!
> Do we already have samples?
>
http://testassets.dashif.org/#feature/details/586fb3879ae9045678eab593
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add mapping for AC-4 in MP4
2019-02-17 21:50 GMT+01:00, Paul B Mahol :
> On 2/17/19, Carl Eugen Hoyos wrote:
>> 2019-02-17 21:25 GMT+01:00, Paul B Mahol :
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> libavformat/isom.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>>> index 0a4d901be5..0052db539e 100644
>>> --- a/libavformat/isom.c
>>> +++ b/libavformat/isom.c
>>
>>> +{ AV_CODEC_ID_AC4, MKTAG('a', 'c', '-', '4') },
>>> /* ETSI TS 103 190 */
>>
>> Are there no codec-specific atoms needed when remuxing ac-4?
>
> They are completely optional and not needed for decoding or remuxing.
Thank you for the explanation!
Do we already have samples?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add mapping for AC-4 in MP4
On 2/17/19, Carl Eugen Hoyos wrote:
> 2019-02-17 21:25 GMT+01:00, Paul B Mahol :
>> Signed-off-by: Paul B Mahol
>> ---
>> libavformat/isom.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>> index 0a4d901be5..0052db539e 100644
>> --- a/libavformat/isom.c
>> +++ b/libavformat/isom.c
>
>> +{ AV_CODEC_ID_AC4, MKTAG('a', 'c', '-', '4') },
>> /* ETSI TS 103 190 */
>
> Are there no codec-specific atoms needed when remuxing ac-4?
They are completely optional and not needed for decoding or remuxing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add mapping for AC-4 in MP4
2019-02-17 21:25 GMT+01:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol
> ---
> libavformat/isom.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index 0a4d901be5..0052db539e 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> +{ AV_CODEC_ID_AC4, MKTAG('a', 'c', '-', '4') },
> /* ETSI TS 103 190 */
Are there no codec-specific atoms needed when remuxing ac-4?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat: add mapping for AC-4 in MP4
Signed-off-by: Paul B Mahol
---
libavformat/isom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 0a4d901be5..0052db539e 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -368,6 +368,7 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
{ AV_CODEC_ID_SMV, MKTAG('s', 's', 'm', 'v') }, /* 3GPP2 */
{ AV_CODEC_ID_FLAC,MKTAG('f', 'L', 'a', 'C') }, /* nonstandard
*/
{ AV_CODEC_ID_OPUS,MKTAG('O', 'p', 'u', 's') }, /* mp4ra.org */
+{ AV_CODEC_ID_AC4, MKTAG('a', 'c', '-', '4') }, /* ETSI TS 103
190 */
{ AV_CODEC_ID_NONE, 0 },
};
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec: add AC-4 codec id and description
Signed-off-by: Paul B Mahol
---
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 0ce22ec4fa..13eb241c77 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -648,6 +648,7 @@ enum AVCodecID {
AV_CODEC_ID_SBC,
AV_CODEC_ID_ATRAC9,
AV_CODEC_ID_HCOM,
+AV_CODEC_ID_AC4,
/* subtitle codecs */
AV_CODEC_ID_FIRST_SUBTITLE = 0x17000, ///< A dummy ID pointing at
the start of subtitle codecs.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index a3de8e1c2b..5fcad0e044 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2957,6 +2957,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("HCOM Audio"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_AC4,
+.type = AVMEDIA_TYPE_AUDIO,
+.name = "ac4",
+.long_name = NULL_IF_CONFIG_SMALL("AC-4"),
+.props = AV_CODEC_PROP_LOSSY,
+},
/* subtitle codecs */
{
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avformat/utils: be more strict about stream specifiers
2019-02-17 20:55 GMT+01:00, Marton Balint : > This reworks the code to be more strict about accepting > stream specifiers. From now on we strictly enforce the > syntax in the documentation up until the decisive part of > the stream specifier. Therefore matching stream specifiers > always need to be correct, non matching specifiers only > need to be correct until the decisive part. Could you give an example for something that changes behaviour with this patch? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avformat/utils: be even more strict about stream specifiers
After this change we always parse the full specifier even if we know the result
in the middle of the parsing. Sligtly slower, but this is needed to
consistently reject incorrect specifiers in both matching and non-matching
cases.
Signed-off-by: Marton Balint
---
libavformat/utils.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 39290a647d..81f72bbf83 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5109,11 +5109,12 @@ AVRational av_guess_frame_rate(AVFormatContext *format,
AVStream *st, AVFrame *f
static int match_stream_specifier(AVFormatContext *s, AVStream *st,
const char *spec, const char **indexptr)
{
+int match = 1; /* Stores if the specifier matches so
far. */
while (*spec) {
if (*spec <= '9' && *spec >= '0') { /* opt:index */
if (indexptr)
*indexptr = spec;
-return 1;
+return match;
} else if (*spec == 'v' || *spec == 'a' || *spec == 's' || *spec == 'd' ||
*spec == 't' || *spec == 'V') { /* opt:[vasdtV] */
enum AVMediaType type;
@@ -5135,14 +5136,14 @@ static int match_stream_specifier(AVFormatContext *s,
AVStream *st,
FF_DISABLE_DEPRECATION_WARNINGS
if (type != st->codecpar->codec_type
&& (st->codecpar->codec_type != AVMEDIA_TYPE_UNKNOWN ||
st->codec->codec_type != type))
-return 0;
+match = 0;
FF_ENABLE_DEPRECATION_WARNINGS
#else
if (type != st->codecpar->codec_type)
-return 0;
+match = 0;
#endif
if (nopic && (st->disposition & AV_DISPOSITION_ATTACHED_PIC))
-return 0;
+match = 0;
} else if (*spec == 'p' && *(spec + 1) == ':') {
int prog_id, i, j;
int found = 0;
@@ -5153,6 +5154,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (spec == endptr || (*endptr && *endptr++ != ':'))
return AVERROR(EINVAL);
spec = endptr;
+if (match) {
for (i = 0; i < s->nb_programs; i++) {
if (s->programs[i]->id != prog_id)
continue;
@@ -5165,8 +5167,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
}
+}
if (!found)
-return 0;
+match = 0;
} else if (*spec == '#' ||
(*spec == 'i' && *(spec + 1) == ':')) {
int stream_id;
@@ -5175,12 +5178,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
stream_id = strtol(spec, , 0);
if (spec == endptr || *endptr)/* Disallow empty id and
make sure we are at the end. */
return AVERROR(EINVAL);
-return stream_id == st->id;
+return match && (stream_id == st->id);
} else if (*spec == 'm' && *(spec + 1) == ':') {
AVDictionaryEntry *tag;
char *key, *val;
int ret;
+if (match) {
spec += 2;
val = strchr(spec, ':');
@@ -5198,7 +5202,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
ret = 0;
av_freep();
-return ret;
+}
+return match && ret;
} else if (*spec == 'u' && *(spec + 1) == '\0') {
AVCodecParameters *par = st->codecpar;
#if FF_API_LAVF_AVCTX
@@ -5240,17 +5245,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
break;
}
#if FF_API_LAVF_AVCTX
-return (par->codec_id != AV_CODEC_ID_NONE || codec->codec_id !=
AV_CODEC_ID_NONE) && val != 0;
+return match && ((par->codec_id != AV_CODEC_ID_NONE || codec->codec_id
!= AV_CODEC_ID_NONE) && val != 0);
#else
-return par->codec_id != AV_CODEC_ID_NONE && val != 0;
+return match && (par->codec_id != AV_CODEC_ID_NONE && val != 0);
#endif
} else {
return AVERROR(EINVAL);
}
}
-/* empty specifier, matches everything */
-return 1;
+return match;
}
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avformat/utils: be more strict about stream specifiers
This reworks the code to be more strict about accepting stream specifiers. From
now on we strictly enforce the syntax in the documentation up until the
decisive part of the stream specifier. Therefore matching stream specifiers
always need to be correct, non matching specifiers only need to be correct
until the decisive part.
Also recursion is changed to a simple loop.
Signed-off-by: Marton Balint
---
libavformat/utils.c | 81 +
1 file changed, 50 insertions(+), 31 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index d113a16c80..39290a647d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5100,18 +5100,19 @@ AVRational av_guess_frame_rate(AVFormatContext *format,
AVStream *st, AVFrame *f
/**
* Matches a stream specifier (but ignores requested index).
*
- * @param index set if a specific index is requested from the matching streams
+ * @param indexptr set to point to the requested stream index if there is one
*
* @return <0 on error
* 0 if st is NOT a matching stream
* >0 if st is a matching stream
*/
static int match_stream_specifier(AVFormatContext *s, AVStream *st,
- const char *spec, int *index)
+ const char *spec, const char **indexptr)
{
+while (*spec) {
if (*spec <= '9' && *spec >= '0') { /* opt:index */
-if (index)
-*index = strtol(spec, NULL, 0);
+if (indexptr)
+*indexptr = spec;
return 1;
} else if (*spec == 'v' || *spec == 'a' || *spec == 's' || *spec == 'd' ||
*spec == 't' || *spec == 'V') { /* opt:[vasdtV] */
@@ -5127,6 +5128,9 @@ static int match_stream_specifier(AVFormatContext *s,
AVStream *st,
case 'V': type = AVMEDIA_TYPE_VIDEO; nopic = 1; break;
default: av_assert0(0);
}
+if (*spec && *spec++ != ':') /* If we are not at the end, then
another specifier must follow. */
+return AVERROR(EINVAL);
+
#if FF_API_LAVF_AVCTX
FF_DISABLE_DEPRECATION_WARNINGS
if (type != st->codecpar->codec_type
@@ -5139,37 +5143,39 @@ FF_ENABLE_DEPRECATION_WARNINGS
#endif
if (nopic && (st->disposition & AV_DISPOSITION_ATTACHED_PIC))
return 0;
-if (*spec++ == ':') /* possibly followed by another specifier */
-return match_stream_specifier(s, st, spec, index);
-return 1;
} else if (*spec == 'p' && *(spec + 1) == ':') {
int prog_id, i, j;
+int found = 0;
char *endptr;
spec += 2;
prog_id = strtol(spec, , 0);
+/* Disallow empty id and make sure that if we are not at the end, then
another specifier must follow. */
+if (spec == endptr || (*endptr && *endptr++ != ':'))
+return AVERROR(EINVAL);
+spec = endptr;
for (i = 0; i < s->nb_programs; i++) {
if (s->programs[i]->id != prog_id)
continue;
for (j = 0; j < s->programs[i]->nb_stream_indexes; j++) {
if (st->index == s->programs[i]->stream_index[j]) {
-if (*endptr++ == ':') { // p::
-return match_stream_specifier(s, st, endptr, index);
-} else {
-return 1;
-}
+found = 1;
+i = s->nb_programs;
+break;
}
}
}
-return 0;
+if (!found)
+return 0;
} else if (*spec == '#' ||
(*spec == 'i' && *(spec + 1) == ':')) {
int stream_id;
char *endptr;
spec += 1 + (*spec == 'i');
stream_id = strtol(spec, , 0);
-if (!*endptr)
-return stream_id == st->id;
+if (spec == endptr || *endptr)/* Disallow empty id and
make sure we are at the end. */
+return AVERROR(EINVAL);
+return stream_id == st->id;
} else if (*spec == 'm' && *(spec + 1) == ':') {
AVDictionaryEntry *tag;
char *key, *val;
@@ -5193,7 +5199,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
av_freep();
return ret;
-} else if (*spec == 'u') {
+} else if (*spec == 'u' && *(spec + 1) == '\0') {
AVCodecParameters *par = st->codecpar;
#if FF_API_LAVF_AVCTX
FF_DISABLE_DEPRECATION_WARNINGS
@@ -5238,40 +5244,53 @@ FF_ENABLE_DEPRECATION_WARNINGS
#else
return par->codec_id != AV_CODEC_ID_NONE && val != 0;
#endif
-} else if (!*spec) /* empty specifier, matches everything */
-return 1;
+} else {
+return AVERROR(EINVAL);
+}
+}
-return AVERROR(EINVAL);
+/* empty specifier, matches everything */
+return 1;
}
int avformat_match_stream_specifier(AVFormatContext *s, AVStream *st,
const char *spec)
{
-int ret;
-
[FFmpeg-devel] [PATCH 4/4] avformat/utils: fix indentation
Signed-off-by: Marton Balint
---
libavformat/utils.c | 236 ++--
1 file changed, 118 insertions(+), 118 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 81f72bbf83..db2dfac3b4 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5111,147 +5111,147 @@ static int match_stream_specifier(AVFormatContext *s,
AVStream *st,
{
int match = 1; /* Stores if the specifier matches so
far. */
while (*spec) {
-if (*spec <= '9' && *spec >= '0') { /* opt:index */
-if (indexptr)
-*indexptr = spec;
-return match;
-} else if (*spec == 'v' || *spec == 'a' || *spec == 's' || *spec == 'd' ||
- *spec == 't' || *spec == 'V') { /* opt:[vasdtV] */
-enum AVMediaType type;
-int nopic = 0;
-
-switch (*spec++) {
-case 'v': type = AVMEDIA_TYPE_VIDEO; break;
-case 'a': type = AVMEDIA_TYPE_AUDIO; break;
-case 's': type = AVMEDIA_TYPE_SUBTITLE; break;
-case 'd': type = AVMEDIA_TYPE_DATA; break;
-case 't': type = AVMEDIA_TYPE_ATTACHMENT; break;
-case 'V': type = AVMEDIA_TYPE_VIDEO; nopic = 1; break;
-default: av_assert0(0);
-}
-if (*spec && *spec++ != ':') /* If we are not at the end, then
another specifier must follow. */
-return AVERROR(EINVAL);
+if (*spec <= '9' && *spec >= '0') { /* opt:index */
+if (indexptr)
+*indexptr = spec;
+return match;
+} else if (*spec == 'v' || *spec == 'a' || *spec == 's' || *spec ==
'd' ||
+ *spec == 't' || *spec == 'V') { /* opt:[vasdtV] */
+enum AVMediaType type;
+int nopic = 0;
+
+switch (*spec++) {
+case 'v': type = AVMEDIA_TYPE_VIDEO; break;
+case 'a': type = AVMEDIA_TYPE_AUDIO; break;
+case 's': type = AVMEDIA_TYPE_SUBTITLE; break;
+case 'd': type = AVMEDIA_TYPE_DATA; break;
+case 't': type = AVMEDIA_TYPE_ATTACHMENT; break;
+case 'V': type = AVMEDIA_TYPE_VIDEO; nopic = 1; break;
+default: av_assert0(0);
+}
+if (*spec && *spec++ != ':') /* If we are not at the end,
then another specifier must follow. */
+return AVERROR(EINVAL);
#if FF_API_LAVF_AVCTX
FF_DISABLE_DEPRECATION_WARNINGS
-if (type != st->codecpar->codec_type
- && (st->codecpar->codec_type != AVMEDIA_TYPE_UNKNOWN ||
st->codec->codec_type != type))
-match = 0;
-FF_ENABLE_DEPRECATION_WARNINGS
+if (type != st->codecpar->codec_type
+ && (st->codecpar->codec_type != AVMEDIA_TYPE_UNKNOWN ||
st->codec->codec_type != type))
+match = 0;
+FF_ENABLE_DEPRECATION_WARNINGS
#else
-if (type != st->codecpar->codec_type)
-match = 0;
+if (type != st->codecpar->codec_type)
+match = 0;
#endif
-if (nopic && (st->disposition & AV_DISPOSITION_ATTACHED_PIC))
-match = 0;
-} else if (*spec == 'p' && *(spec + 1) == ':') {
-int prog_id, i, j;
-int found = 0;
-char *endptr;
-spec += 2;
-prog_id = strtol(spec, , 0);
-/* Disallow empty id and make sure that if we are not at the end, then
another specifier must follow. */
-if (spec == endptr || (*endptr && *endptr++ != ':'))
-return AVERROR(EINVAL);
-spec = endptr;
-if (match) {
-for (i = 0; i < s->nb_programs; i++) {
-if (s->programs[i]->id != prog_id)
-continue;
+if (nopic && (st->disposition & AV_DISPOSITION_ATTACHED_PIC))
+match = 0;
+} else if (*spec == 'p' && *(spec + 1) == ':') {
+int prog_id, i, j;
+int found = 0;
+char *endptr;
+spec += 2;
+prog_id = strtol(spec, , 0);
+/* Disallow empty id and make sure that if we are not at the end,
then another specifier must follow. */
+if (spec == endptr || (*endptr && *endptr++ != ':'))
+return AVERROR(EINVAL);
+spec = endptr;
+if (match) {
+for (i = 0; i < s->nb_programs; i++) {
+if (s->programs[i]->id != prog_id)
+continue;
-for (j = 0; j < s->programs[i]->nb_stream_indexes; j++) {
-if (st->index == s->programs[i]->stream_index[j]) {
-found = 1;
-i = s->nb_programs;
-break;
+for (j = 0; j < s->programs[i]->nb_stream_indexes; j++) {
+if (st->index == s->programs[i]->stream_index[j]) {
+found = 1;
+i = s->nb_programs;
+
[FFmpeg-devel] [PATCH 1/4] doc/formats: add reference to ffmpeg(1) stream specifiers as that docs is more complete
Signed-off-by: Marton Balint
---
doc/formats.texi | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/doc/formats.texi b/doc/formats.texi
index 52a5ff8371..a992506ac1 100644
--- a/doc/formats.texi
+++ b/doc/formats.texi
@@ -234,30 +234,10 @@ At present, applicable for MPEG-PS and MPEG-TS.
Format stream specifiers allow selection of one or more streams that
match specific properties.
-Possible forms of stream specifiers are:
-@table @option
-@item @var{stream_index}
-Matches the stream with this index.
-
-@item @var{stream_type}[:@var{stream_index}]
-@var{stream_type} is one of following: 'v' for video, 'a' for audio,
-'s' for subtitle, 'd' for data, and 't' for attachments. If
-@var{stream_index} is given, then it matches the stream number
-@var{stream_index} of this type. Otherwise, it matches all streams of
-this type.
-
-@item p:@var{program_id}[:@var{stream_index}]
-If @var{stream_index} is given, then it matches the stream with number
-@var{stream_index} in the program with the id
-@var{program_id}. Otherwise, it matches all streams in the program.
-
-@item #@var{stream_id}
-Matches the stream by a format-specific ID.
-@end table
-
The exact semantics of stream specifiers is defined by the
@code{avformat_match_stream_specifier()} function declared in the
-@file{libavformat/avformat.h} header.
+@file{libavformat/avformat.h} header and documented in the
+@ref{Stream specifiers,,Stream specifiers section in the ffmpeg(1)
manual,ffmpeg}.
@ifclear config-writeonly
@include demuxers.texi
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/get_bits: add assertion to limit ouptut value of get_bits
Should fix the following Coverity false positives: Coverity CID #1415651. Coverity CID #1420392. Coverity CID #1420473. Coverity CID #1433770. Coverity CID #1435320. Coverity CID #1439573. Coverity CID #1439580. Coverity CID #1439588. Signed-off-by: Marton Balint --- libavcodec/get_bits.h | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h index 2e2adc29c2..c2f267186e 100644 --- a/libavcodec/get_bits.h +++ b/libavcodec/get_bits.h @@ -403,6 +403,7 @@ static inline unsigned int get_bits(GetBitContext *s, int n) LAST_SKIP_BITS(re, s, n); CLOSE_READER(re, s); #endif +av_assert2(tmp < UINT64_C(1) << n); return tmp; } -- 2.16.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/get_bits: use unsigned integers in show_bits and get_bits
The return value is also unsigned.
---
libavcodec/get_bits.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 26a5b3e54f..2e2adc29c2 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -380,7 +380,7 @@ static inline int get_sbits(GetBitContext *s, int n)
*/
static inline unsigned int get_bits(GetBitContext *s, int n)
{
-register int tmp;
+register unsigned int tmp;
#if CACHED_BITSTREAM_READER
av_assert2(n>0 && n<=32);
@@ -442,7 +442,7 @@ static inline unsigned int get_bits_le(GetBitContext *s,
int n)
*/
static inline unsigned int show_bits(GetBitContext *s, int n)
{
-register int tmp;
+register unsigned int tmp;
#if CACHED_BITSTREAM_READER
if (n > s->bits_left)
refill_32(s);
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/avpacket: add some assertions to ensure pkt->data is not null if pkt->size > 0
This should fix the following Coverity false positives: Coverity CID #1405450. Coverity CID #1430930. Signed-off-by: Marton Balint --- libavcodec/avpacket.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c index 11ac4e80cd..8f0603df78 100644 --- a/libavcodec/avpacket.c +++ b/libavcodec/avpacket.c @@ -616,6 +616,7 @@ int av_packet_ref(AVPacket *dst, const AVPacket *src) ret = packet_alloc(>buf, src->size); if (ret < 0) goto fail; +av_assert1(!src->size || src->data); if (src->size) memcpy(dst->buf->data, src->data, src->size); @@ -668,6 +669,7 @@ int av_packet_make_refcounted(AVPacket *pkt) ret = packet_alloc(>buf, pkt->size); if (ret < 0) return ret; +av_assert1(!pkt->size || pkt->data); if (pkt->size) memcpy(pkt->buf->data, pkt->data, pkt->size); @@ -687,6 +689,7 @@ int av_packet_make_writable(AVPacket *pkt) ret = packet_alloc(, pkt->size); if (ret < 0) return ret; +av_assert1(!pkt->size || pkt->data); if (pkt->size) memcpy(buf->data, pkt->data, pkt->size); -- 2.16.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mxfdec: Export EIA608 Closed Captions by default
On Sun, 17 Feb 2019, Marton Balint wrote: On Sun, 17 Feb 2019, Carl Eugen Hoyos wrote: 2019-02-17 1:40 GMT+01:00, Marton Balint : On Sat, 16 Feb 2019, Carl Eugen Hoyos wrote: I am not sure why there is an option to disable Closed Captions export, but disabling the export by default seems like a bad idea to me. SMPTE 436M can be any kind of ancillary data, not only closed captions. That is why the default behaviour (pass all the data to userspace so a userspace app can parse it properly) makes sense. Some applications might depend on this. Wouldn't it still make more sense to change the default? Sorry, no. We should not change existing behaviour for this. The application that knows it needs the ancillary data, well, knows it while the average user who reads the mxf file has no idea that there is a subtitle stream and has no idea that FFmpeg can read the subtitle stream. I would bump micro in any case and the option also works fine with older FFmpeg versions so I don't really see the issue. Issue is that you are removing a data stream which was previously provided. Also CC extraction in MXF decoder is a hack. It should be deprecated after the API will be capable of bitstream filtering between different codecs. And the VANC data can be parsed to multiple subtitle/data streams. Why eia608 has the perference? Why not teletext, or SCTE messages? All in all, it is better to keep hacks under the option until we come up with better API. One more thing is that the fact that a file has VANC data does not mean that it actually has Closed Captions data. It might, or it might not, so unconditionally advertising a CC stream just because there _might_ be CC data would also be bad. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mxfdec: Export EIA608 Closed Captions by default
On Sun, 17 Feb 2019, Carl Eugen Hoyos wrote: 2019-02-17 1:40 GMT+01:00, Marton Balint : On Sat, 16 Feb 2019, Carl Eugen Hoyos wrote: I am not sure why there is an option to disable Closed Captions export, but disabling the export by default seems like a bad idea to me. SMPTE 436M can be any kind of ancillary data, not only closed captions. That is why the default behaviour (pass all the data to userspace so a userspace app can parse it properly) makes sense. Some applications might depend on this. Wouldn't it still make more sense to change the default? Sorry, no. We should not change existing behaviour for this. The application that knows it needs the ancillary data, well, knows it while the average user who reads the mxf file has no idea that there is a subtitle stream and has no idea that FFmpeg can read the subtitle stream. I would bump micro in any case and the option also works fine with older FFmpeg versions so I don't really see the issue. Issue is that you are removing a data stream which was previously provided. Also CC extraction in MXF decoder is a hack. It should be deprecated after the API will be capable of bitstream filtering between different codecs. And the VANC data can be parsed to multiple subtitle/data streams. Why eia608 has the perference? Why not teletext, or SCTE messages? All in all, it is better to keep hacks under the option until we come up with better API. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v7] mpeg12enc: Use Closed Captions if available
> It would be better to test against a decoder from a unrelated codebase > Otherwise its a bit like testing your new language skills by talking with > yourself. I have just tested with gstreamer's mpegvideoparse element, it detects the closed captions as expected: 0:00:00.602266814 27833 0x810400 DEBUG mpegvideoparse gstmpegvideoparse.c:507:parse_user_data_packet: CEA-708 closed captions, 60 bytes ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Makefile: delete unneeded escape
Michael Niedermayer wrote: >if someone adds a line after this he would have to change the >previous line (adding the \ back) >that would make such a patch less tidy (2 lines changed instead >of 1) >i suspect that was the reason why all lines have a \ Possibly. The two other similar instances are handled differently. Anyway, sorry for the noise! And best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Makefile: delete unneeded escape
On Sun, Feb 17, 2019 at 09:44:52AM +0100, Reto Kromer wrote: > Best regards, Reto > Makefile |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > ed5a95e331e302563d0859bd3b514d88376696e6 > 0001-Makefile-delete-unneeded-escape.patch > From 764d9459caecc259952984258ae19ed0906c1176 Mon Sep 17 00:00:00 2001 > From: Reto Kromer > Date: Sun, 17 Feb 2019 09:40:01 +0100 > Subject: [PATCH] Makefile: delete unneeded escape > > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 59b26c65c9..08b3cfa9b1 100644 > --- a/Makefile > +++ b/Makefile > @@ -59,7 +59,7 @@ CONFIGURABLE_COMPONENTS = > \ > $(wildcard $(FFLIBS:%=$(SRC_PATH)/lib%/all*.c)) \ > $(SRC_PATH)/libavcodec/bitstream_filters.c \ > $(SRC_PATH)/libavcodec/parsers.c\ > -$(SRC_PATH)/libavformat/protocols.c \ > +$(SRC_PATH)/libavformat/protocols.c > if someone adds a line after this he would have to change the previous line (adding the \ back) that would make such a patch less tidy (2 lines changed instead of 1) i suspect that was the reason why all lines have a \ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Makefile: delete unneeded escape
Best regards, Reto 0001-Makefile-delete-unneeded-escape.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Check parents remaining length
On Wed, Feb 13, 2019 at 01:41:31PM +0100, Michael Niedermayer wrote: > Reported-by: Steve Lhomme > This was found through the Hacker One program on VLC but is not a security > issue in libavformat > Signed-off-by: Michael Niedermayer > --- > libavformat/matroskadec.c | 21 + > 1 file changed, 21 insertions(+) will apply an equivalent variant from steve [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/ftp: Fix Out-of-Bounds Access and Information Leak in ftp.c:393
On Wed, Feb 13, 2019 at 10:31:32AM +0100, Michael Niedermayer wrote: > From: Wenxiang Qian > > Signed-off-by: Michael Niedermayer > --- > libavformat/ftp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Do not leak queued packets on sync errors
On Fri, Feb 08, 2019 at 10:53:52PM +0100, Michael Niedermayer wrote: > Fixes: memleak > Fixes: clusterfuzz-testcase-minimized-audio_decoder_fuzzer-5649187601121280 > > Reported-by: Chris Cunningham > Tested-by: Chris Cunningham > Signed-off-by: Michael Niedermayer > --- > libavformat/matroskadec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for tag scaning
On Wed, Feb 13, 2019 at 01:22:37AM +0100, Michael Niedermayer wrote: > From: Kevin Backhouse via RT > > Fixes: [Semmle Security Reports #19438] > Fixes: dos_sscanf1.mkv > > Signed-off-by: Michael Niedermayer > --- > libavcodec/htmlsubtitles.c | 30 +- > 1 file changed, 29 insertions(+), 1 deletion(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpegvideo_enc: Use av_assert1() instead of assert()
On Fri, Feb 01, 2019 at 11:33:35PM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/mpegvideo_enc.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
