Re: [FFmpeg-devel] [PATCH 2/4] avcodec/hevc_ps: Fix integer overflow with num_tile_rows
On Mon, Jun 17, 2019 at 07:55:45PM -0300, James Almer wrote:
> On 6/17/2019 6:54 PM, Michael Niedermayer wrote:
> > On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
> >> On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
> >>> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
> >>> type 'int'
> >>> Fixes:
> >>> 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
> >>>
> >>> Found-by: continuous fuzzing process
> >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer
> >>> ---
> >>> libavcodec/hevc_ps.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> >>> index 80df417e4f..0ed6682bb4 100644
> >>> --- a/libavcodec/hevc_ps.c
> >>> +++ b/libavcodec/hevc_ps.c
> >>> @@ -1596,7 +1596,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> >>> AVCodecContext *avctx,
> >>> if (pps->num_tile_rows <= 0 ||
> >>> pps->num_tile_rows >= sps->height) {
> >>> av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of
> >>> range: %d\n",
> >>> - pps->num_tile_rows - 1);
> >>> + pps->num_tile_rows - 1U);
> >>
> >> The proper fix for this is making pps->num_tile_rows/cols unsigned.
[...]
> >
> > is this here ok if num_tile_rows is 0 ?
> > for (i = 0; i < pps->num_tile_rows - 1; i++) { (example line from ffmpeg
> > git)
> >
> > i would guess nearly everyone wold say yes without having seen the
> > discussion about the type. but of course if this is unsigned its not
> > going to be safe with it being 0.
>
> pps->num_tile_rows is set to a value returned by "get_ue_golomb_long() +
> 1", which will always be in the 1..UINT32_MAX range. It can't be 0, as
> it would be a bug. Int is definitely not the right type for it.
i dont think num_tile_rows of more than 2^31 (that is the negative when signed
range)
makes much sense but sure i can change it to unsigned if preferred.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
signature.asc
Description: PGP signature
___
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 v2] avfilter/vaapi: add overlay_vaapi filter
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> myp...@gmail.com
> Sent: Wednesday, June 19, 2019 10:13 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter/vaapi: add overlay_vaapi
> filter
>
> ?
> On Tue, Jun 11, 2019 at 10:52 AM Zachary Zhou
> wrote:
> >
> > ---
> > configure | 1 +
> > libavfilter/Makefile | 1 +
> > libavfilter/allfilters.c | 1 +
> > libavfilter/vaapi_vpp.c| 95 +
> > libavfilter/vaapi_vpp.h| 5 +
> > libavfilter/vf_overlay_vaapi.c | 357
> > +
> > 6 files changed, 460 insertions(+)
> > create mode 100644 libavfilter/vf_overlay_vaapi.c
> >
> > diff --git a/configure b/configure
> > index 32fc26356c..f469e6a3b1 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3478,6 +3478,7 @@ openclsrc_filter_deps="opencl"
> > overlay_opencl_filter_deps="opencl"
> > overlay_qsv_filter_deps="libmfx"
> > overlay_qsv_filter_select="qsvvpp"
> > +overlay_vaapi_filter_deps="vaapi"
> > owdenoise_filter_deps="gpl"
> > pan_filter_deps="swresample"
> > perspective_filter_deps="gpl"
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile index
> > 07ea8d7edc..5cbf1a7e41 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -311,6 +311,7 @@ OBJS-$(CONFIG_OVERLAY_FILTER)+=
> vf_overlay.o framesync.o
> > OBJS-$(CONFIG_OVERLAY_OPENCL_FILTER) += vf_overlay_opencl.o
> opencl.o \
> > opencl/overlay.o
> > framesync.o
> > OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o
> framesync.o
> > +OBJS-$(CONFIG_OVERLAY_VAAPI_FILTER) += vf_overlay_vaapi.o
> framesync.o
> > OBJS-$(CONFIG_OWDENOISE_FILTER) += vf_owdenoise.o
> > OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
> > OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
> > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index
> > 9c846b1ddd..27ee1df78b 100644
> > --- a/libavfilter/allfilters.c
> > +++ b/libavfilter/allfilters.c
> > @@ -295,6 +295,7 @@ extern AVFilter ff_vf_oscilloscope; extern
> > AVFilter ff_vf_overlay; extern AVFilter ff_vf_overlay_opencl; extern
> > AVFilter ff_vf_overlay_qsv;
> > +extern AVFilter ff_vf_overlay_vaapi;
> > extern AVFilter ff_vf_owdenoise;
> > extern AVFilter ff_vf_pad;
> > extern AVFilter ff_vf_palettegen;
> > diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c index
> > b5b245c8af..a8caa5b532 100644
> > --- a/libavfilter/vaapi_vpp.c
> > +++ b/libavfilter/vaapi_vpp.c
> > @@ -663,6 +663,101 @@ fail:
> > return err;
> > }
> >
> > +int ff_vaapi_vpp_render_overlay(AVFilterContext *avctx,
> > +VAProcPipelineParameterBuffer *params,
> > +VAProcPipelineParameterBuffer
> > *subpic_params,
> > +VASurfaceID output_surface) {
> > +VABufferID params_id;
> > +VABufferID subpic_params_id;
> > +VAStatus vas;
> > +int err = 0;
> > +VAAPIVPPContext *ctx = avctx->priv;
> > +
> > +vas = vaBeginPicture(ctx->hwctx->display,
> > + ctx->va_context, output_surface);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to attach new picture: "
> > + "%d (%s).\n", vas, vaErrorStr(vas));
> > +err = AVERROR(EIO);
> > +goto fail;
> > +}
> > +
> > +vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
> > + VAProcPipelineParameterBufferType,
> > + sizeof(*params), 1, params, ¶ms_id);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to create parameter buffer: "
> > + "%d (%s).\n", vas, vaErrorStr(vas));
> > +err = AVERROR(EIO);
> > +goto fail_after_begin;
> > +}
> > +av_log(avctx, AV_LOG_DEBUG, "Pipeline parameter buffer is %#x.\n",
> > + params_id);
> > +
> > +
> > +vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
> > + VAProcPipelineParameterBufferType,
> > + sizeof(*subpic_params), 1, subpic_params,
> &subpic_params_id);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to create parameter buffer: "
> > + "%d (%s).\n", vas, vaErrorStr(vas));
> > +err = AVERROR(EIO);
> > +goto fail_after_begin;
> > +}
> > +av_log(avctx, AV_LOG_DEBUG, "Pipeline subpic parameter buffer
> is %#x.\n",
> > + subpic_params_id);
> > +
> > +vas = vaRenderPicture(ctx->hwctx->display, ctx->va_context,
> > + ¶ms_id, 1);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to render parameter buf
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/iff: Check bpp for validity
On Wed, Jun 19, 2019 at 01:53:02AM +0200, Michael Niedermayer wrote:
> Fixes: shift exponent -100663046 is negative
> Fixes: out of array access
> Fixes:
> 15270/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5727829913763840
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/iff.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/iff.c b/libavcodec/iff.c
> index 33cf2e3a94..48a0340604 100644
> --- a/libavcodec/iff.c
> +++ b/libavcodec/iff.c
> @@ -382,7 +382,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
> IffContext *s = avctx->priv_data;
> int err;
>
> -if (avctx->bits_per_coded_sample <= 8) {
> +if (avctx->bits_per_coded_sample <= 8U) {
> int palette_size;
>
> if (avctx->extradata_size >= 2)
> @@ -391,7 +391,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
> palette_size = 0;
> avctx->pix_fmt = (avctx->bits_per_coded_sample < 8) ||
> (avctx->extradata_size >= 2 && palette_size) ?
> AV_PIX_FMT_PAL8 : AV_PIX_FMT_GRAY8;
> -} else if (avctx->bits_per_coded_sample <= 32) {
> +} else if (avctx->bits_per_coded_sample <= 32U) {
> if (avctx->codec_tag == MKTAG('R', 'G', 'B', '8')) {
> avctx->pix_fmt = AV_PIX_FMT_RGB32;
> } else if (avctx->codec_tag == MKTAG('R', 'G', 'B', 'N')) {
> --
> 2.21.0
hey michael, can you post the test case file?
AVCodecParameters.bits_per_coded_sample is signed, but looking at
*libavformat*/iff.c,
i can't fathom how its getting below zero.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
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] avformat/hlsenc: enhanced %v handling with variant names
On Tue, Jun 18, 2019 at 11:09:12PM +0200, Bodecs Bela wrote: > Dear All, > > When multiple variant streams are specified by var_stream_map option, %v > placeholder in various names ensures that each variant has its unique > names. Currently %v is substituted by its variant index value (0, 1, 2 > etc.). In some use cases it would be handy to specify names for variants > instead of numerical indexes. This patch makes it possible to use names > instead of default indexes. In var_stream_map option each or some of the > variant streams may use an optional name attributum (e.g. > -var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is > specified for a variant, then this name value will be used as > substitution value of %v instead of the default index value. > > > example: > ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \ > -map 0:v:0 -map 0:a:0 -map 0:v:1 -map 0:a:1 -f hls -var_stream_map > "v:0,a:0,name:my_hd v:1,a:1,name:mysd" \ > http://example.com/live/out_%v.m3u8 > > This example creates two hls variant streams, the two output media playlist > with file names out_my_hd.m3u8 and out_mysd.m3u8 will be created. > > Please review this patch. > > best regards, maybe i made a mistake but this seems not to apply Applying: avformat/hlsenc: enhanced %v handling with variant names error: sha1 information is lacking or useless (libavformat/hlsenc.c). error: could not build fake ancestor Patch failed at 0001 avformat/hlsenc: enhanced %v handling with variant names hint: Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: PGP signature ___ 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] set AVFrame decode_error_flags to FF_DECODE_ERROR_CONCEALMENT_ACTIVE in case of concealed errors
On Tue, Jun 18, 2019 at 03:14:47PM +0300, Amir Z wrote: > Thanks Michael, > > The reason I set the flag before the log line in ff_er_frame_end is because > the code might never get there even though the return value is set to zero. > > Should we use two different values ? if there are 2 semantically different cases, maybe yes thx [...] -- 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 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] dash: change default MP4 extension to .m4s
On 19/06/2019 07:21, Jeyapal, Karthick wrote:
On 6/18/19 1:48 PM, Alfred E. Heggestad wrote:
On 18/06/2019 04:02, Steven Liu wrote:
Alfred E. Heggestad 于2019年6月17日周一 下午4:02写道：
From 923da82598bddd1ed05750427dbc71e607d296a2 Mon Sep 17 00:00:00 2001
From: "Alfred E. Heggestad"
Date: Mon, 17 Jun 2019 09:59:04 +0200
Subject: [PATCH] dash: change default MP4 extension to .m4s
this was changed in commit 281a21ed50849e3c8c0d03005230e9fd07c24370
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 3fd7e78166..a51a1da0ca 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -166,7 +166,7 @@ static struct format_string {
const char *str;
} formats[] = {
{ SEGMENT_TYPE_AUTO, "auto" },
-{ SEGMENT_TYPE_MP4, "mp4" },
+{ SEGMENT_TYPE_MP4, "m4s" },
{ SEGMENT_TYPE_WEBM, "webm" },
{ 0, NULL }
};
--
2.20.1 (Apple Git-117)
___
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".
LGTM
the background for this is the extension for DASH media files
used to be *.m4s and it is now *.mp4
the patch is a suggestion and should be checked by the DASH experts
what is correct according to the standard ?
the media-file is not really an .mp4 file, it cannot be
played with e.g. ffplay:
$ ffplay chunk-stream1-1.m4s
Thanks for submitting the patch. I agree that m4s should be extension for media
segments.
mp4 should be used only for complete files.
With respect to the patch, dashenc generates either multiple segments or a single
file(with byte range as segments) based on "single_file" option.
The default of mp4 is correct when "single_file" is enabled. But it is wrong when
"single_file" is disabled. The proposed patch just reverses this situation.
I would suggest the patch should handle both cases correctly.
Hi,
many thanks for your review comments.
I have updated the patch based on your comments, please see below.
this code works in my application (both single and multi files)
but the code should be reviewed by someone who has better
knowledge with the code.
...
From 2059bfad56eadbccee968cc34dd594089a1e8984 Mon Sep 17 00:00:00 2001
From: "Alfred E. Heggestad"
Date: Wed, 19 Jun 2019 11:33:13 +0200
Subject: [PATCH] dash: change default MP4 extension to .m4s
---
libavformat/dashenc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 3fd7e78166..a60547ef0d 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -250,6 +250,10 @@ static int init_segment_types(AVFormatContext *s)
c->segment_type_option, s->streams[i]->codecpar->codec_id);
os->segment_type = segment_type;
os->format_name = get_format_str(segment_type);
+
+if (segment_type == SEGMENT_TYPE_MP4 && !c->single_file)
+os->format_name = "m4s";
+
if (!os->format_name) {
av_log(s, AV_LOG_ERROR, "Could not select DASH segment
type for stream %d\n", i);
return AVERROR_MUXER_NOT_FOUND;
@@ -1210,7 +1214,7 @@ static int dash_init(AVFormatContext *s)
}
}
-ctx->oformat = av_guess_format(os->format_name, NULL, NULL);
+ctx->oformat =
av_guess_format(get_format_str(os->segment_type), NULL, NULL);
if (!ctx->oformat)
return AVERROR_MUXER_NOT_FOUND;
os->ctx = ctx;
--
2.20.1 (Apple Git-117)
___
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 2/3] avcodec/iff: Check bpp for validity
On Wed, Jun 19, 2019 at 07:34:19PM +1000, Peter Ross wrote:
> On Wed, Jun 19, 2019 at 01:53:02AM +0200, Michael Niedermayer wrote:
> > Fixes: shift exponent -100663046 is negative
> > Fixes: out of array access
> > Fixes:
> > 15270/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5727829913763840
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/iff.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/iff.c b/libavcodec/iff.c
> > index 33cf2e3a94..48a0340604 100644
> > --- a/libavcodec/iff.c
> > +++ b/libavcodec/iff.c
> > @@ -382,7 +382,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
> > IffContext *s = avctx->priv_data;
> > int err;
> >
> > -if (avctx->bits_per_coded_sample <= 8) {
> > +if (avctx->bits_per_coded_sample <= 8U) {
> > int palette_size;
> >
> > if (avctx->extradata_size >= 2)
> > @@ -391,7 +391,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
> > palette_size = 0;
> > avctx->pix_fmt = (avctx->bits_per_coded_sample < 8) ||
> > (avctx->extradata_size >= 2 && palette_size) ?
> > AV_PIX_FMT_PAL8 : AV_PIX_FMT_GRAY8;
> > -} else if (avctx->bits_per_coded_sample <= 32) {
> > +} else if (avctx->bits_per_coded_sample <= 32U) {
> > if (avctx->codec_tag == MKTAG('R', 'G', 'B', '8')) {
> > avctx->pix_fmt = AV_PIX_FMT_RGB32;
> > } else if (avctx->codec_tag == MKTAG('R', 'G', 'B', 'N')) {
> > --
> > 2.21.0
>
> hey michael, can you post the test case file?
>
> AVCodecParameters.bits_per_coded_sample is signed, but looking at
> *libavformat*/iff.c,
> i can't fathom how its getting below zero.
even better i can explain it
in target_dec_fuzzer.c there is:
ctx->bits_per_coded_sample = bytestream2_get_le32(&gbc);
quite possibly this is not possble with libavformat and this codec currently.
A API user from his own demuxer or a future demuxer in libavformat could set
it though.
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
signature.asc
Description: PGP signature
___
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 2/4] avcodec/hevc_ps: Fix integer overflow with num_tile_rows
On Mon, Jun 17, 2019 at 07:55:45PM -0300, James Almer wrote:
> On 6/17/2019 6:54 PM, Michael Niedermayer wrote:
> > On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
> >> On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
> >>> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
> >>> type 'int'
> >>> Fixes:
> >>> 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
> >>>
> >>> Found-by: continuous fuzzing process
> >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer
> >>> ---
> >>> libavcodec/hevc_ps.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> >>> index 80df417e4f..0ed6682bb4 100644
> >>> --- a/libavcodec/hevc_ps.c
> >>> +++ b/libavcodec/hevc_ps.c
> >>> @@ -1596,7 +1596,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> >>> AVCodecContext *avctx,
> >>> if (pps->num_tile_rows <= 0 ||
> >>> pps->num_tile_rows >= sps->height) {
> >>> av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of
> >>> range: %d\n",
> >>> - pps->num_tile_rows - 1);
> >>> + pps->num_tile_rows - 1U);
> >>
> >> The proper fix for this is making pps->num_tile_rows/cols unsigned.
> >
> > I dont think "unsigned int" is wise to use as type here, the semantics
> > of unsigned ints are unexpected to many
> > especially making random subsets of "normal" fields unsigned will make
> > the codebase slowly "interresting".
>
> If you make the actual unsigned values as per the spec be unsigned, it
> will not be a random subset of values...
no, but it would require very precisse knowledge of the types used in the
spec though. Iam not sure everyone working on the code has this knowledge
> And i see plenty of unsigned
> and uint*_t fields in hevc_ps.h. These for some reason were given the
> wrong type.
uint8/16 is not unsigned in this sense in C. So these are not a problem
at all. Ill cover uint32 below, but first consider uint8/16 and unsigned
int main(){
uint8_t u8 = 0;
unsigned u = 0;
printf("is u-1 negative: %d, is u8-1 negative: %d\n", u-1 < 0, u8-1 < 0);
}
This produces:
is u-1 negative: 0, is u8-1 negative: 1
the uint8_t type is a signed int in C expressions, unsigned is a unsigned int
in C
Now about uint32_t, that you probably dont want to hear about but it should
behave platform dependant. On a system that has 32bit ints its unsigned, on a
platform
where int is 64bit it should be signed.
We did not run into this yet because platforms with 64bit int are uncommon.
the world choose to keep int 32bit even on 64bit architectures in general.
But because of that use of uint32_t except for array types is probably simply
a bad idea.
Iam not sure today if i like C, normally i like it ...
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
signature.asc
Description: PGP signature
___
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] avformat/hlsenc: enhanced %v handling with variant names
2019.06.19. 11:37 keltezéssel, Michael Niedermayer írta: On Tue, Jun 18, 2019 at 11:09:12PM +0200, Bodecs Bela wrote: Dear All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Currently %v is substituted by its variant index value (0, 1, 2 etc.). In some use cases it would be handy to specify names for variants instead of numerical indexes. This patch makes it possible to use names instead of default indexes. In var_stream_map option each or some of the variant streams may use an optional name attributum (e.g. -var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is specified for a variant, then this name value will be used as substitution value of %v instead of the default index value. example: ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \ -map 0:v:0 -map 0:a:0 -map 0:v:1 -map 0:a:1 -f hls -var_stream_map "v:0,a:0,name:my_hd v:1,a:1,name:mysd" \ http://example.com/live/out_%v.m3u8 This example creates two hls variant streams, the two output media playlist with file names out_my_hd.m3u8 and out_mysd.m3u8 will be created. Please review this patch. best regards, maybe i made a mistake but this seems not to apply Applying: avformat/hlsenc: enhanced %v handling with variant names error: sha1 information is lacking or useless (libavformat/hlsenc.c). error: could not build fake ancestor Patch failed at 0001 avformat/hlsenc: enhanced %v handling with variant names hint: Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [...] I think it relates to the fact - as I mentioned my other post - that I created two related patches and I send them into the list as unrelated patches. I will wait for my earlier patch to be applied and then I reissue this patch again. best, bb ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/binkdsp: Fix integer overflows in idct
On Tue, Jun 18, 2019 at 02:55:02PM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 3784 * 682038 cannot be represented in type
> 'int'
> Fixes:
> 15265/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-5088311799971840
> Fixes:
> 15268/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-5666502344179712
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/binkdsp.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/binkdsp.c b/libavcodec/binkdsp.c
> index 9d70e2326f..a357d31672 100644
> --- a/libavcodec/binkdsp.c
> +++ b/libavcodec/binkdsp.c
> @@ -33,20 +33,22 @@
> #define A3 3784
> #define A4 -5352
>
> +#define MUL(X,Y) ((int)((unsigned)(X) * (Y)) >> 11)
> +
> #define
> IDCT_TRANSFORM(dest,s0,s1,s2,s3,s4,s5,s6,s7,d0,d1,d2,d3,d4,d5,d6,d7,munge,src)
> {\
> const int a0 = (src)[s0] + (src)[s4]; \
> const int a1 = (src)[s0] - (src)[s4]; \
> const int a2 = (src)[s2] + (src)[s6]; \
> -const int a3 = (A1*((src)[s2] - (src)[s6])) >> 11; \
> +const int a3 = MUL(A1, (src)[s2] - (src)[s6]); \
> const int a4 = (src)[s5] + (src)[s3]; \
> const int a5 = (src)[s5] - (src)[s3]; \
> const int a6 = (src)[s1] + (src)[s7]; \
> const int a7 = (src)[s1] - (src)[s7]; \
> const int b0 = a4 + a6; \
> -const int b1 = (A3*(a5 + a7)) >> 11; \
> -const int b2 = ((A4*a5) >> 11) - b0 + b1; \
> -const int b3 = (A1*(a6 - a4) >> 11) - b2; \
> -const int b4 = ((A2*a7) >> 11) + b3 - b1; \
> +const int b1 = MUL(A3, a5 + a7); \
> +const int b2 = MUL(A4, a5) - b0 + b1; \
> +const int b3 = MUL(A1, a6 - a4) - b2; \
> +const int b4 = MUL(A2, a7) + b3 - b1; \
> (dest)[d0] = munge(a0+a2 +b0); \
> (dest)[d1] = munge(a1+a3-a2+b2); \
> (dest)[d2] = munge(a1-a3+a2+b3); \
> --
> 2.21.0
approve both parts 1 & 2.
have also tested these changes against my pile of reference binkb files.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
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] avformat/hlsenc: enhanced %v handling with variant names
> 在 2019年6月19日，下午6:00，Bodecs Bela 写道： > > > 2019.06.19. 11:37 keltezéssel, Michael Niedermayer írta: >> On Tue, Jun 18, 2019 at 11:09:12PM +0200, Bodecs Bela wrote: >>> Dear All, >>> >>> When multiple variant streams are specified by var_stream_map option, %v >>> placeholder in various names ensures that each variant has its unique >>> names. Currently %v is substituted by its variant index value (0, 1, 2 >>> etc.). In some use cases it would be handy to specify names for variants >>> instead of numerical indexes. This patch makes it possible to use names >>> instead of default indexes. In var_stream_map option each or some of the >>> variant streams may use an optional name attributum (e.g. >>> -var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is >>> specified for a variant, then this name value will be used as >>> substitution value of %v instead of the default index value. >>> >>> >>> example: >>> ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \ >>> -map 0:v:0 -map 0:a:0 -map 0:v:1 -map 0:a:1 -f hls -var_stream_map >>> "v:0,a:0,name:my_hd v:1,a:1,name:mysd" \ >>> http://example.com/live/out_%v.m3u8 >>> >>> This example creates two hls variant streams, the two output media playlist >>> with file names out_my_hd.m3u8 and out_mysd.m3u8 will be created. >>> >>> Please review this patch. >>> >>> best regards, >> maybe i made a mistake but this seems not to apply >> >> Applying: avformat/hlsenc: enhanced %v handling with variant names >> error: sha1 information is lacking or useless (libavformat/hlsenc.c). >> error: could not build fake ancestor >> Patch failed at 0001 avformat/hlsenc: enhanced %v handling with variant names >> hint: Use 'git am --show-current-patch' to see the failed patch >> When you have resolved this problem, run "git am --continue". >> If you prefer to skip this patch, run "git am --skip" instead. >> To restore the original branch and stop patching, run "git am --abort". >> >> [...] >> >> > I think it relates to the fact - as I mentioned my other post - that I > created two related patches and I send them into the list as unrelated > patches. > > I will wait for my earlier patch to be applied and then I reissue this patch > again. Let me push it :D > > best, > > bb > >> ___ >> 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 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 2/3] avcodec/iff: Check bpp for validity
On Wed, Jun 19, 2019 at 11:44:36AM +0200, Michael Niedermayer wrote:
> On Wed, Jun 19, 2019 at 07:34:19PM +1000, Peter Ross wrote:
> > On Wed, Jun 19, 2019 at 01:53:02AM +0200, Michael Niedermayer wrote:
> > > Fixes: shift exponent -100663046 is negative
> > > Fixes: out of array access
> > > Fixes:
> > > 15270/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5727829913763840
> > >
> > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavcodec/iff.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/iff.c b/libavcodec/iff.c
> > > index 33cf2e3a94..48a0340604 100644
> > > --- a/libavcodec/iff.c
> > > +++ b/libavcodec/iff.c
> > > @@ -382,7 +382,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
> > > IffContext *s = avctx->priv_data;
> > > int err;
> > >
> > > -if (avctx->bits_per_coded_sample <= 8) {
> > > +if (avctx->bits_per_coded_sample <= 8U) {
> > > int palette_size;
> > >
> > > if (avctx->extradata_size >= 2)
> > > @@ -391,7 +391,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
> > > palette_size = 0;
> > > avctx->pix_fmt = (avctx->bits_per_coded_sample < 8) ||
> > > (avctx->extradata_size >= 2 && palette_size) ?
> > > AV_PIX_FMT_PAL8 : AV_PIX_FMT_GRAY8;
> > > -} else if (avctx->bits_per_coded_sample <= 32) {
> > > +} else if (avctx->bits_per_coded_sample <= 32U) {
> > > if (avctx->codec_tag == MKTAG('R', 'G', 'B', '8')) {
> > > avctx->pix_fmt = AV_PIX_FMT_RGB32;
> > > } else if (avctx->codec_tag == MKTAG('R', 'G', 'B', 'N')) {
> > > --
> > > 2.21.0
> >
> > hey michael, can you post the test case file?
> >
> > AVCodecParameters.bits_per_coded_sample is signed, but looking at
> > *libavformat*/iff.c,
> > i can't fathom how its getting below zero.
>
> even better i can explain it
> in target_dec_fuzzer.c there is:
> ctx->bits_per_coded_sample = bytestream2_get_le32(&gbc);
>
> quite possibly this is not possble with libavformat and this codec currently.
> A API user from his own demuxer or a future demuxer in libavformat could set
> it though.
understood, this patch is ok.
i fear there are many of other places where signed test is done on
bits_per_coded sample
leading to shift explosion. given enough time, fuzz will eventually catch them
all.
how radical of a change would just making
AVCodecParameters.bits_per_coded_sample unsigned be?
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
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] avformat/hlsenc: enhanced %v handling with variant names
> 在 2019年6月19日，下午6:00，Bodecs Bela 写道： > > > 2019.06.19. 11:37 keltezéssel, Michael Niedermayer írta: >> On Tue, Jun 18, 2019 at 11:09:12PM +0200, Bodecs Bela wrote: >>> Dear All, >>> >>> When multiple variant streams are specified by var_stream_map option, %v >>> placeholder in various names ensures that each variant has its unique >>> names. Currently %v is substituted by its variant index value (0, 1, 2 >>> etc.). In some use cases it would be handy to specify names for variants >>> instead of numerical indexes. This patch makes it possible to use names >>> instead of default indexes. In var_stream_map option each or some of the >>> variant streams may use an optional name attributum (e.g. >>> -var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is >>> specified for a variant, then this name value will be used as >>> substitution value of %v instead of the default index value. >>> >>> >>> example: >>> ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \ >>> -map 0:v:0 -map 0:a:0 -map 0:v:1 -map 0:a:1 -f hls -var_stream_map >>> "v:0,a:0,name:my_hd v:1,a:1,name:mysd" \ >>> http://example.com/live/out_%v.m3u8 >>> >>> This example creates two hls variant streams, the two output media playlist >>> with file names out_my_hd.m3u8 and out_mysd.m3u8 will be created. >>> >>> Please review this patch. >>> >>> best regards, >> maybe i made a mistake but this seems not to apply >> >> Applying: avformat/hlsenc: enhanced %v handling with variant names >> error: sha1 information is lacking or useless (libavformat/hlsenc.c). >> error: could not build fake ancestor >> Patch failed at 0001 avformat/hlsenc: enhanced %v handling with variant names >> hint: Use 'git am --show-current-patch' to see the failed patch >> When you have resolved this problem, run "git am --continue". >> If you prefer to skip this patch, run "git am --skip" instead. >> To restore the original branch and stop patching, run "git am --abort". >> >> [...] >> >> > I think it relates to the fact - as I mentioned my other post - that I > created two related patches and I send them into the list as unrelated > patches. > > I will wait for my earlier patch to be applied and then I reissue this patch > again. I have pushed the first patch, and this patch cannot be merged: muhanmoeMacBook:ffmpeg StevenLiu$ git am ~/Downloads/0001-avformat-hlsenc-enhanced-v-handling-with-variant-nam.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given. muhanmoeMacBook:ffmpeg StevenLiu$ patch -p1 < ~/Downloads/0001-avformat-hlsenc-enhanced-v-handling-with-variant-nam.patch (Stripping trailing CRs from patch.) patching file doc/muxers.texi (Stripping trailing CRs from patch.) patching file libavformat/hlsenc.c Hunk #8 FAILED at 2693. Hunk #9 FAILED at 2754. Hunk #10 FAILED at 2811. Hunk #11 FAILED at 2876. Hunk #12 succeeded at 2938 (offset 11 lines). 4 out of 12 hunks FAILED -- saving rejects to file libavformat/hlsenc.c.rej muhanmoeMacBook:ffmpeg StevenLiu$ > > best, > > bb > >> ___ >> 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 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] [FFmpeg-cvslog] avcodec/bitstream: Check for integer code truncation in build_table()
Am Fr., 14. Juni 2019 um 21:40 Uhr schrieb Michael Niedermayer
:
>
> ffmpeg | branch: master | Michael Niedermayer | Wed
> Jun 5 12:18:54 2019 +0200| [e78b0f83748f92ea9e93b21c36082e0dd04d7cb1] |
> committer: Michael Niedermayer
>
> avcodec/bitstream: Check for integer code truncation in build_table()
>
> Fixes: out of array read
> Fixes:
> 14563/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5646451545210880
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e78b0f83748f92ea9e93b21c36082e0dd04d7cb1
> ---
>
> libavcodec/bitstream.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/bitstream.c b/libavcodec/bitstream.c
> index 8762e5f4b2..590b490527 100644
> --- a/libavcodec/bitstream.c
> +++ b/libavcodec/bitstream.c
> @@ -226,6 +226,10 @@ static int build_table(VLC *vlc, int table_nb_bits, int
> nb_codes,
> /* note: realloc has been done, so reload tables */
> table = (volatile VLC_TYPE (*)[2])&vlc->table[table_index];
> table[j][0] = index; //code
> +if (table[j][0] != index) {
> +avpriv_request_sample(NULL, "strange codes");
This broke building with --enable-hardcoded-tables, patch sent.
Carl Eugen
___
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]Fix build with --enable-hardcoded-tables
Hi! Attached patch fixes ticket #7962 for me, please comment. Thank you, Carl Eugen From 2b82532897074d3f17c0a5f0a17da3a601d821d7 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Wed, 19 Jun 2019 13:41:01 +0200 Subject: [PATCH] lavc/tableprint_vlc: Remove avpriv_request_sample() from included files. Fixes compilation with --enable-hardcoded-tables. Fixes ticket #7962. --- libavcodec/tableprint_vlc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/tableprint_vlc.h b/libavcodec/tableprint_vlc.h index 3004be3f9c..b3ff36562b 100644 --- a/libavcodec/tableprint_vlc.h +++ b/libavcodec/tableprint_vlc.h @@ -36,6 +36,7 @@ #define AVCODEC_AVCODEC_H #define AVCODEC_INTERNAL_H #define AV_INPUT_BUFFER_PADDING_SIZE 64 // the value does not matter for this +#define avpriv_request_sample(...) #include "tableprint.h" #include "get_bits.h" #include "mathtables.c" -- 2.21.0 ___ 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] avformat/hlsenc: enhanced %v handling with variant names
2019.06.19. 12:17 keltezéssel, Liu Steven írta: 在 2019年6月19日，下午6:00，Bodecs Bela 写道： 2019.06.19. 11:37 keltezéssel, Michael Niedermayer írta: On Tue, Jun 18, 2019 at 11:09:12PM +0200, Bodecs Bela wrote: Dear All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Currently %v is substituted by its variant index value (0, 1, 2 etc.). In some use cases it would be handy to specify names for variants instead of numerical indexes. This patch makes it possible to use names instead of default indexes. In var_stream_map option each or some of the variant streams may use an optional name attributum (e.g. -var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is specified for a variant, then this name value will be used as substitution value of %v instead of the default index value. example: ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \ -map 0:v:0 -map 0:a:0 -map 0:v:1 -map 0:a:1 -f hls -var_stream_map "v:0,a:0,name:my_hd v:1,a:1,name:mysd" \ http://example.com/live/out_%v.m3u8 This example creates two hls variant streams, the two output media playlist with file names out_my_hd.m3u8 and out_mysd.m3u8 will be created. Please review this patch. best regards, maybe i made a mistake but this seems not to apply Applying: avformat/hlsenc: enhanced %v handling with variant names error: sha1 information is lacking or useless (libavformat/hlsenc.c). error: could not build fake ancestor Patch failed at 0001 avformat/hlsenc: enhanced %v handling with variant names hint: Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [...] I think it relates to the fact - as I mentioned my other post - that I created two related patches and I send them into the list as unrelated patches. I will wait for my earlier patch to be applied and then I reissue this patch again. I have pushed the first patch, and this patch cannot be merged: muhanmoeMacBook:ffmpeg StevenLiu$ git am ~/Downloads/0001-avformat-hlsenc-enhanced-v-handling-with-variant-nam.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given. muhanmoeMacBook:ffmpeg StevenLiu$ patch -p1 < ~/Downloads/0001-avformat-hlsenc-enhanced-v-handling-with-variant-nam.patch (Stripping trailing CRs from patch.) patching file doc/muxers.texi (Stripping trailing CRs from patch.) patching file libavformat/hlsenc.c Hunk #8 FAILED at 2693. Hunk #9 FAILED at 2754. Hunk #10 FAILED at 2811. Hunk #11 FAILED at 2876. Hunk #12 succeeded at 2938 (offset 11 lines). 4 out of 12 hunks FAILED -- saving rejects to file libavformat/hlsenc.c.rej muhanmoeMacBook:ffmpeg StevenLiu$ best, bb ___ 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". I have created the patch again to the current head. Please try it. ___ 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". From 3e9f4cb98420a7edb6517281c125975c16f185b9 Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Wed, 19 Jun 2019 15:05:25 +0200 Subject: [PATCH] avformat/hlsenc: enhanced %v handling with variant names When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Currently %v is substituted by its variant index value (0, 1, 2 etc.). In some use cases it would be handy to specify names for variants instead of numerical indexes. This patch makes it possible to use names instead of default indexes. In var_stream_map option each or some of the variant streams may use an optional name attributum (e.g. -var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is specified for a variant, then this name value will be used as substitution value of %v instead of the default index value. Signed-off-by: Bela Bodecs --- doc/muxers.texi | 16 ++- libavformat/hlsenc.c | 110 +++ 2 files changed, 96 insertions(+), 30 deletions(-) diff --git a/doc/muxers.texi b/doc/muxers.texi index 50147c4d20..8370b6dc2e 100644 --- a/doc/muxers.texi +++ b/doc/muxers.texi @@ -943,7 +943,21 @@ This example creates
Re: [FFmpeg-devel] [PATCH v2] avfilter/vaapi: add overlay_vaapi filter
On Wed, Jun 19, 2019 at 5:26 PM Zhou, Zachary wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > myp...@gmail.com
> > Sent: Wednesday, June 19, 2019 10:13 AM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter/vaapi: add overlay_vaapi
> > filter
> >
> > ?
> > On Tue, Jun 11, 2019 at 10:52 AM Zachary Zhou
> > wrote:
> > >
> > > ---
> > > configure | 1 +
> > > libavfilter/Makefile | 1 +
> > > libavfilter/allfilters.c | 1 +
> > > libavfilter/vaapi_vpp.c| 95 +
> > > libavfilter/vaapi_vpp.h| 5 +
> > > libavfilter/vf_overlay_vaapi.c | 357
> > > +
> > > 6 files changed, 460 insertions(+)
> > > create mode 100644 libavfilter/vf_overlay_vaapi.c
> > >
> > > diff --git a/configure b/configure
> > > index 32fc26356c..f469e6a3b1 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -3478,6 +3478,7 @@ openclsrc_filter_deps="opencl"
> > > overlay_opencl_filter_deps="opencl"
> > > overlay_qsv_filter_deps="libmfx"
> > > overlay_qsv_filter_select="qsvvpp"
> > > +overlay_vaapi_filter_deps="vaapi"
> > > owdenoise_filter_deps="gpl"
> > > pan_filter_deps="swresample"
> > > perspective_filter_deps="gpl"
> > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile index
> > > 07ea8d7edc..5cbf1a7e41 100644
> > > --- a/libavfilter/Makefile
> > > +++ b/libavfilter/Makefile
> > > @@ -311,6 +311,7 @@ OBJS-$(CONFIG_OVERLAY_FILTER)+=
> > vf_overlay.o framesync.o
> > > OBJS-$(CONFIG_OVERLAY_OPENCL_FILTER) += vf_overlay_opencl.o
> > opencl.o \
> > > opencl/overlay.o
> > > framesync.o
> > > OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o
> > framesync.o
> > > +OBJS-$(CONFIG_OVERLAY_VAAPI_FILTER) += vf_overlay_vaapi.o
> > framesync.o
> > > OBJS-$(CONFIG_OWDENOISE_FILTER) += vf_owdenoise.o
> > > OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
> > > OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
> > > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index
> > > 9c846b1ddd..27ee1df78b 100644
> > > --- a/libavfilter/allfilters.c
> > > +++ b/libavfilter/allfilters.c
> > > @@ -295,6 +295,7 @@ extern AVFilter ff_vf_oscilloscope; extern
> > > AVFilter ff_vf_overlay; extern AVFilter ff_vf_overlay_opencl; extern
> > > AVFilter ff_vf_overlay_qsv;
> > > +extern AVFilter ff_vf_overlay_vaapi;
> > > extern AVFilter ff_vf_owdenoise;
> > > extern AVFilter ff_vf_pad;
> > > extern AVFilter ff_vf_palettegen;
> > > diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c index
> > > b5b245c8af..a8caa5b532 100644
> > > --- a/libavfilter/vaapi_vpp.c
> > > +++ b/libavfilter/vaapi_vpp.c
> > > @@ -663,6 +663,101 @@ fail:
> > > return err;
> > > }
> > >
> > > +int ff_vaapi_vpp_render_overlay(AVFilterContext *avctx,
> > > +VAProcPipelineParameterBuffer *params,
> > > +VAProcPipelineParameterBuffer
> > > *subpic_params,
> > > +VASurfaceID output_surface) {
> > > +VABufferID params_id;
> > > +VABufferID subpic_params_id;
> > > +VAStatus vas;
> > > +int err = 0;
> > > +VAAPIVPPContext *ctx = avctx->priv;
> > > +
> > > +vas = vaBeginPicture(ctx->hwctx->display,
> > > + ctx->va_context, output_surface);
> > > +if (vas != VA_STATUS_SUCCESS) {
> > > +av_log(avctx, AV_LOG_ERROR, "Failed to attach new picture: "
> > > + "%d (%s).\n", vas, vaErrorStr(vas));
> > > +err = AVERROR(EIO);
> > > +goto fail;
> > > +}
> > > +
> > > +vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
> > > + VAProcPipelineParameterBufferType,
> > > + sizeof(*params), 1, params, ¶ms_id);
> > > +if (vas != VA_STATUS_SUCCESS) {
> > > +av_log(avctx, AV_LOG_ERROR, "Failed to create parameter buffer: "
> > > + "%d (%s).\n", vas, vaErrorStr(vas));
> > > +err = AVERROR(EIO);
> > > +goto fail_after_begin;
> > > +}
> > > +av_log(avctx, AV_LOG_DEBUG, "Pipeline parameter buffer is %#x.\n",
> > > + params_id);
> > > +
> > > +
> > > +vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
> > > + VAProcPipelineParameterBufferType,
> > > + sizeof(*subpic_params), 1, subpic_params,
> > &subpic_params_id);
> > > +if (vas != VA_STATUS_SUCCESS) {
> > > +av_log(avctx, AV_LOG_ERROR, "Failed to create parameter buffer: "
> > > + "%d (%s).\n", vas, vaErrorStr(vas));
> > > +err = AVERROR(EIO);
> > > +goto fail_after_begin;
> > > +}
> > > +av_log(avctx, AV_LOG_DEBUG, "Pipeline subpic parameter
Re: [FFmpeg-devel] [PATCH] movenc: calculate track_duration without packet duration
On 19/06/2019 06:43, Gyan wrote: >> setting track_duration is inconsistent; some times it includes >> duration and some times not. > It may be best to check the commits for these assignments to see if the > inconsistency is deliberate. > The track duration is written into the media header box for the track. I > also see it being used elsewhere to adjust dts. Do those roles remain > intact? > > Does FATE pass? Wouldn't the correct fix be to fix the places where duration is *not* used? Writing the track duration without taking into account the actual packet duration of the last packet is just wrong. That's not the track's duration, and is in fact very problematic for low frame rate files, such a slide shows; QuickTime will cut off at the end of the media and track duration, dropping possibly a whole slide, for example. - Derek ___ 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 v6] Fix integer parameters size check in SDP fmtp line
=== PROBLEM ===
I was trying to record h264 + aac streams from an RTSP server to mp4 file.
using this command line:
ffmpeg -v verbose -y -i "rtsp:///my_resources" -codec copy -bsf:a
aac_adtstoasc test.mp4
FFmpeg then fail to record audio and output this logs:
[rtsp @ 0xcda1f0] The profile-level-id field size is invalid (40)
[rtsp @ 0xcda1f0] Error parsing AU headers
...
[rtsp @ 0xcda1f0] Could not find codec parameters for stream 1 (Audio: aac,
48000 Hz, 1 channels): unspecified sample format
In SDP provided by my RTSP server I had this fmtp line:
a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr; config=1188;
sizeLength=13; indexLength=3; indexDeltaLength=3;
In FFmpeg code, I found a check introduced by commit
24130234cd9dd733116d17b724ea4c8e12ce097a. It disallows values greater than 32
for fmtp line parameters.
However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual Streams) give
examples of "profile-level-id" values for AAC, up to 55.
Furthermore, RFC-4566 (SDP: Session Description Protocol) do not give any limit
of size on interger parameters given in fmtp line.
=== FIX ===
Instead of prohibit values over 32, I propose to check the possible integer
overflow.
The use of strtol allow to check the string validity and the possible overflow.
Value is then checked against INT32_MIN and INT32_MAX. Using INT32_MIN/MAX
ensure to have the same behavior on 32 or 64 bits platforms.
This patch fix my problem and I now can record my RTSP AAC stream to mp4.
It has passed the full fate tests suite sucessfully.
Signed-off-by: Olivier Maignial
---
Changes V5 -> V6:
- Simplify code
libavformat/rtpdec_mpeg4.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
index 4f70599..9c4f8a1 100644
--- a/libavformat/rtpdec_mpeg4.c
+++ b/libavformat/rtpdec_mpeg4.c
@@ -289,15 +289,20 @@ static int parse_fmtp(AVFormatContext *s,
for (i = 0; attr_names[i].str; ++i) {
if (!av_strcasecmp(attr, attr_names[i].str)) {
if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
-int val = atoi(value);
-if (val > 32) {
+char *end_ptr = NULL;
+errno = 0;
+long int val = strtol(value, &end_ptr, 10);
+if (end_ptr == value || end_ptr[0] != '\0' ||
+errno == ERANGE ||
+val < INT32_MIN || val > INT32_MAX) {
av_log(s, AV_LOG_ERROR,
- "The %s field size is invalid (%d)\n",
- attr, val);
+ "The %s field value is not a valid number, or
overflows int32: %s\n",
+ attr, value);
return AVERROR_INVALIDDATA;
}
+
*(int *)((char *)data+
-attr_names[i].offset) = val;
+attr_names[i].offset) = (int) val;
} else if (attr_names[i].type == ATTR_NAME_TYPE_STR) {
char *val = av_strdup(value);
if (!val)
--
2.7.4
___
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] movenc: calculate track_duration without packet duration
On 19/06/2019 15:36, Derek Buitenhuis wrote: On 19/06/2019 06:43, Gyan wrote: setting track_duration is inconsistent; some times it includes duration and some times not. It may be best to check the commits for these assignments to see if the inconsistency is deliberate. The track duration is written into the media header box for the track. I also see it being used elsewhere to adjust dts. Do those roles remain intact? Does FATE pass? Wouldn't the correct fix be to fix the places where duration is *not* used? Writing the track duration without taking into account the actual packet duration of the last packet is just wrong. That's not the track's duration, and is in fact very problematic for low frame rate files, such a slide shows; QuickTime will cut off at the end of the media and track duration, dropping possibly a whole slide, for example. Hi, thanks for your comments. I agree that track_duration should include duration, I will take a look at this tomorrow. but why do you require that dts > prev_dts + prev_dur when dur is unknown ? I think this check is too strict. a better check would be: dts > prev_dts a very simple example of how to demonstrate this: $ ffmpeg -y -loglevel info \ -listen 1 -i rtmp://127.0.0.1:1935/live \ -f dash out.mpd and then use ffmpeg to send FLV/RTMP stream to 127.0.0.1 after some seconds ffmpeg prints this warning: [mp4 @ 0x7faffe065600] Application provided duration: -2 / timestamp: 1761244 is out of range for mov/mp4 format /alfred ___ 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] AMF: Vulkan initialization support for encoder.
Added linux support for amf encoder through vulkan.
To use h.264(AMD VCE) encoder on linux amdgru-pro version 19.20+ and
amf-amdgpu-pro package(amdgru-pro contains, but does not install automatically)
are required.
Initialization of amf encoder occurs in this order:
1) trying to initialize through dx11
2) trying to initialize through dx9
3) trying to initialize through vulkan
Only Vulkan initialization available on linux.
---
libavcodec/amfenc.c | 22 --
libavcodec/amfenc.h | 1 +
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 384d8efc92..5f42c2328a 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -234,6 +234,7 @@ static int amf_init_context(AVCodecContext *avctx)
ctx->trace->pVtbl->SetWriterLevel(ctx->trace, FFMPEG_AMF_WRITER_ID,
AMF_TRACE_TRACE);
res = ctx->factory->pVtbl->CreateContext(ctx->factory, &ctx->context);
+ctx->context1 = NULL;
AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "CreateContext()
failed with error %d\n", res);
// If a device was passed to the encoder, try to initialise from that.
@@ -311,8 +312,19 @@ static int amf_init_context(AVCodecContext *avctx)
if (res == AMF_OK) {
av_log(avctx, AV_LOG_VERBOSE, "AMF initialisation succeeded
via D3D9.\n");
} else {
-av_log(avctx, AV_LOG_ERROR, "AMF initialisation failed via
D3D9: error %d.\n", res);
-return AVERROR(ENOSYS);
+AMFGuid guid = IID_AMFContext1();
+res = ctx->context->pVtbl->QueryInterface(ctx->context, &guid,
(void**)&ctx->context1);
+AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN,
"CreateContext1() failed with error %d\n", res);
+
+res = ctx->context1->pVtbl->InitVulkan(ctx->context1, NULL);
+if (res != AMF_OK) {
+if (res == AMF_NOT_SUPPORTED)
+av_log(avctx, AV_LOG_ERROR, "AMF via Vulkan is not
supported on the given device.\n");
+else
+av_log(avctx, AV_LOG_ERROR, "AMF failed to initialise
on the given Vulkan device: %d.\n", res);
+return AVERROR(ENOSYS);
+}
+av_log(avctx, AV_LOG_VERBOSE, "AMF initialisation succeeded
via Vulkan.\n");
}
}
}
@@ -373,6 +385,12 @@ int av_cold ff_amf_encode_close(AVCodecContext *avctx)
ctx->context->pVtbl->Release(ctx->context);
ctx->context = NULL;
}
+
+if (ctx->context1) {
+ctx->context1->pVtbl->Terminate(ctx->context1);
+ctx->context1->pVtbl->Release(ctx->context1);
+ctx->context1 = NULL;
+}
av_buffer_unref(&ctx->hw_device_ctx);
av_buffer_unref(&ctx->hw_frames_ctx);
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index b1361842bd..9c4ea7c071 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -54,6 +54,7 @@ typedef struct AmfContext {
amf_uint64 version; ///< version of AMF runtime
AmfTraceWriter tracer; ///< AMF writer registered with AMF
AMFContext *context; ///< AMF context
+AMFContext1*context1;///< AMF context1 with vulkan support
//encoder
AMFComponent *encoder; ///< AMF encoder object
amf_booleof; ///< flag indicating EOF happened
--
2.19.1.windows.1
___
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 2/4] avcodec/hevc_ps: Fix integer overflow with num_tile_rows
On 6/19/2019 6:22 AM, Michael Niedermayer wrote:
> On Mon, Jun 17, 2019 at 07:55:45PM -0300, James Almer wrote:
>> On 6/17/2019 6:54 PM, Michael Niedermayer wrote:
>>> On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
> type 'int'
> Fixes:
> 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/hevc_ps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 80df417e4f..0ed6682bb4 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -1596,7 +1596,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> AVCodecContext *avctx,
> if (pps->num_tile_rows <= 0 ||
> pps->num_tile_rows >= sps->height) {
> av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of
> range: %d\n",
> - pps->num_tile_rows - 1);
> + pps->num_tile_rows - 1U);
The proper fix for this is making pps->num_tile_rows/cols unsigned.
> [...]
>>>
>>> is this here ok if num_tile_rows is 0 ?
>>> for (i = 0; i < pps->num_tile_rows - 1; i++) { (example line from ffmpeg
>>> git)
>>>
>>> i would guess nearly everyone wold say yes without having seen the
>>> discussion about the type. but of course if this is unsigned its not
>>> going to be safe with it being 0.
>>
>> pps->num_tile_rows is set to a value returned by "get_ue_golomb_long() +
>> 1", which will always be in the 1..UINT32_MAX range. It can't be 0, as
>> it would be a bug. Int is definitely not the right type for it.
>
> i dont think num_tile_rows of more than 2^31 (that is the negative when
> signed range)
> makes much sense but sure i can change it to unsigned if preferred.
Of course it doesn't. In pretty much any sample it will be at least 1
and at most 22, which is the max value allowed by hevc level 6.2 in
table A.6. Only if the stream reports an undefined level it could go up
to, if i'm reading this right, sps->ctb_height and not sps->height as
the decoder is currently checking. This means you can even replace
get_ue_golomb_long() for a get_ue_golomb(). That would also fix this.
In any case, the bitstream value is unsigned, so the struct field should
be unsigned as well. Having it be signed and assigning it a value using
a function that potentially returns huge unsigned values introduced this
issue to being with, so instead of working around it using type
promotion, just make it follow the spec.
>
> [...]
>
>
> ___
> 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".
Re: [FFmpeg-devel] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: > ffmpeg | branch: master | Bodecs Bela | Mon Jun 17 > 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | committer: > Steven Liu > > av_format/hlsenc: fix %v handling by format_name function > > Hi All, > > When multiple variant streams are specified by var_stream_map option, %v > placeholder in various names ensures that each variant has its unique > names. Most of %v handlng is done in format_name function. Currently > in this function the result buffer is the same as the > input pattern buffer, so you must allocate it before calling format_name > function. It also means, that it is silently assumed that the result > string will NOT be > longer that the pattern string. It is true most of the time, because %v > may appear only once in the pattern string and number of variant streams > is less than 100 in practical cases. But theoretically it will fail if > specified number of variant streams is greater than 100 (i.e. longer > than 2 digits). > This patch fixes this behaviour by altering format_name function to > allocate the > result buffer and return it to the caller. > > Please, review this patch. > > best, > > Bela > >From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 > From: Bela Bodecs > Date: Mon, 17 Jun 2019 14:31:36 +0200 > Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function > > When multiple variant streams are specified by var_stream_map option, %v > placeholder in various names ensures that each variant has its unique > names. Most of %v handlng is done in format_name function. Currently > in this function the result buffer is the same as the input pattern > buffer, so you must allocate it before calling format_name function. It > also means, that it is silently assumed that the result string will NOT > be longer that the pattern string. It is true most of the time, because > %v may appear only once in the pattern string and number of variant > streams is less than 100 in practical cases. But theoretically it will > fail if specified number of variant streams is greater than 100. This > patch fixes this behaviour by altering format_name function to allocate > the result buffer and return it to the caller. > > Signed-off-by: Bela Bodecs This broke fate (segfaults) also it produces new compiler warnings which probably are pointing to the cause libavformat/hlsenc.c: In function ‘hls_init’: libavformat/hlsenc.c:2643:9: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2643:9: warning: passing argument 3 of ‘format_name’ makes integer from pointer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of type ‘char *’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2712:13: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->basename, basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2767:25: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] format_name(vs->fmp4_init_filename, fmp4_init_filename_len, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2832:17: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->vtt_m3u8_name, vtt_basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ 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 2/4] avcodec/hevc_ps: Fix integer overflow with num_tile_rows
On Wed, Jun 19, 2019 at 12:54:25PM -0300, James Almer wrote:
> On 6/19/2019 6:22 AM, Michael Niedermayer wrote:
> > On Mon, Jun 17, 2019 at 07:55:45PM -0300, James Almer wrote:
> >> On 6/17/2019 6:54 PM, Michael Niedermayer wrote:
> >>> On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
> On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
> > Fixes: signed integer overflow: -2147483648 - 1 cannot be represented
> > in type 'int'
> > Fixes:
> > 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/hevc_ps.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index 80df417e4f..0ed6682bb4 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1596,7 +1596,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> > AVCodecContext *avctx,
> > if (pps->num_tile_rows <= 0 ||
> > pps->num_tile_rows >= sps->height) {
> > av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of
> > range: %d\n",
> > - pps->num_tile_rows - 1);
> > + pps->num_tile_rows - 1U);
>
> The proper fix for this is making pps->num_tile_rows/cols unsigned.
> > [...]
> >>>
> >>> is this here ok if num_tile_rows is 0 ?
> >>> for (i = 0; i < pps->num_tile_rows - 1; i++) { (example line from ffmpeg
> >>> git)
> >>>
> >>> i would guess nearly everyone wold say yes without having seen the
> >>> discussion about the type. but of course if this is unsigned its not
> >>> going to be safe with it being 0.
> >>
> >> pps->num_tile_rows is set to a value returned by "get_ue_golomb_long() +
> >> 1", which will always be in the 1..UINT32_MAX range. It can't be 0, as
> >> it would be a bug. Int is definitely not the right type for it.
> >
> > i dont think num_tile_rows of more than 2^31 (that is the negative when
> > signed range)
> > makes much sense but sure i can change it to unsigned if preferred.
>
> Of course it doesn't. In pretty much any sample it will be at least 1
> and at most 22, which is the max value allowed by hevc level 6.2 in
> table A.6. Only if the stream reports an undefined level it could go up
> to, if i'm reading this right, sps->ctb_height and not sps->height as
> the decoder is currently checking. This means you can even replace
> get_ue_golomb_long() for a get_ue_golomb(). That would also fix this.
>
> In any case, the bitstream value is unsigned, so the struct field should
> be unsigned as well. Having it be signed and assigning it a value using
> a function that potentially returns huge unsigned values introduced this
> issue to being with, so instead of working around it using type
> promotion, just make it follow the spec.
what would be your feeling/oppinon about making the field uint16_t ?
this would make it unsigned in the struct but avoid the problems with
unsigned int ?
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
signature.asc
Description: PGP signature
___
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] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
2019.06.19. 19:37 keltezéssel, Michael Niedermayer írta: On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: ffmpeg | branch: master | Bodecs Bela | Mon Jun 17 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | committer: Steven Liu av_format/hlsenc: fix %v handling by format_name function Hi All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100 (i.e. longer than 2 digits). This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Please, review this patch. best, Bela >From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Mon, 17 Jun 2019 14:31:36 +0200 Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100. This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Signed-off-by: Bela Bodecs This broke fate (segfaults) also it produces new compiler warnings which probably are pointing to the cause libavformat/hlsenc.c: In function ‘hls_init’: libavformat/hlsenc.c:2643:9: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2643:9: warning: passing argument 3 of ‘format_name’ makes integer from pointer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of type ‘char *’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2712:13: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->basename, basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2767:25: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] format_name(vs->fmp4_init_filename, fmp4_init_filename_len, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2832:17: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->vtt_m3u8_name, vtt_basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) [...] Are you sure, you have applied my patch file? Because in the patch the first error should not have been: - ret = format_name(s->url, i, vs->m3u8_name); + ret = format_name(s->url, &vs->m3u8_name, i, vs->varname); bb ___ 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/listin
Re: [FFmpeg-devel] [PATCH] avformat/oggdec: only parse headers before data
On Mon, Jun 17, 2019 at 05:59:40PM -0700, Chris Cunningham wrote:
> This behavior was added in 2010 to suport some old (and invalid) ogm
> files.
> https://github.com/FFmpeg/FFmpeg/commit/81b743eb1026547270b88ac6a5cb451a3907ee94
>
> But this makes it possible to change the codec in the later headers,
> causing codec to be out of sync with internal avctx (eventually
> triggering Abrt). Updating the internal ctx for this degenerate case
> was deemed not worth it. See discussion here:
> https://patchwork.ffmpeg.org/patch/11983/
> ---
> libavformat/oggdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
> index e815f42134..19d77f3107 100644
> --- a/libavformat/oggdec.c
> +++ b/libavformat/oggdec.c
> @@ -545,7 +545,7 @@ static int ogg_packet(AVFormatContext *s, int *sid, int
> *dstart, int *dsize,
> ogg->curidx= idx;
> os->incomplete = 0;
>
> -if (os->header) {
> +if (!ogg->headers) {
> if ((ret = os->codec->header(s, idx)) < 0) {
> av_log(s, AV_LOG_ERROR, "Header processing failed: %s\n",
> av_err2str(ret));
> return ret;
breaks:
./ffmpeg -i bgc.sub.dub.ogm -vframes 3 -y test.webm
sample: http://samples.mplayerhq.hu/ogg/bgc.sub.dub.ogm
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
signature.asc
Description: PGP signature
___
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] avcodec/utils: Check bits_per_coded_sample
This avoids the need for each decoder separately having to handle this case
Fixes: shift exponent -100663046 is negative
Fixes: out of array access
Fixes:
15270/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5727829913763840
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/utils.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index cc04b73471..1b1feca38c 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -962,6 +962,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
ret = AVERROR(EINVAL);
goto free_and_end;
}
+if (avctx->bits_per_coded_sample < 0) {
+ret = AVERROR(EINVAL);
+goto free_and_end;
+}
if (avctx->sub_charenc) {
if (avctx->codec_type != AVMEDIA_TYPE_SUBTITLE) {
av_log(avctx, AV_LOG_ERROR, "Character encoding is only "
--
2.21.0
___
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 2/3] avcodec/iff: Check bpp for validity
On Wed, Jun 19, 2019 at 08:11:50PM +1000, Peter Ross wrote:
> On Wed, Jun 19, 2019 at 11:44:36AM +0200, Michael Niedermayer wrote:
> > On Wed, Jun 19, 2019 at 07:34:19PM +1000, Peter Ross wrote:
> > > On Wed, Jun 19, 2019 at 01:53:02AM +0200, Michael Niedermayer wrote:
> > > > Fixes: shift exponent -100663046 is negative
> > > > Fixes: out of array access
> > > > Fixes:
> > > > 15270/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5727829913763840
> > > >
> > > > Found-by: continuous fuzzing process
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavcodec/iff.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/iff.c b/libavcodec/iff.c
> > > > index 33cf2e3a94..48a0340604 100644
> > > > --- a/libavcodec/iff.c
> > > > +++ b/libavcodec/iff.c
> > > > @@ -382,7 +382,7 @@ static av_cold int decode_init(AVCodecContext
> > > > *avctx)
> > > > IffContext *s = avctx->priv_data;
> > > > int err;
> > > >
> > > > -if (avctx->bits_per_coded_sample <= 8) {
> > > > +if (avctx->bits_per_coded_sample <= 8U) {
> > > > int palette_size;
> > > >
> > > > if (avctx->extradata_size >= 2)
> > > > @@ -391,7 +391,7 @@ static av_cold int decode_init(AVCodecContext
> > > > *avctx)
> > > > palette_size = 0;
> > > > avctx->pix_fmt = (avctx->bits_per_coded_sample < 8) ||
> > > > (avctx->extradata_size >= 2 && palette_size)
> > > > ? AV_PIX_FMT_PAL8 : AV_PIX_FMT_GRAY8;
> > > > -} else if (avctx->bits_per_coded_sample <= 32) {
> > > > +} else if (avctx->bits_per_coded_sample <= 32U) {
> > > > if (avctx->codec_tag == MKTAG('R', 'G', 'B', '8')) {
> > > > avctx->pix_fmt = AV_PIX_FMT_RGB32;
> > > > } else if (avctx->codec_tag == MKTAG('R', 'G', 'B', 'N')) {
> > > > --
> > > > 2.21.0
> > >
> > > hey michael, can you post the test case file?
> > >
> > > AVCodecParameters.bits_per_coded_sample is signed, but looking at
> > > *libavformat*/iff.c,
> > > i can't fathom how its getting below zero.
> >
> > even better i can explain it
> > in target_dec_fuzzer.c there is:
> > ctx->bits_per_coded_sample =
> > bytestream2_get_le32(&gbc);
> >
> > quite possibly this is not possble with libavformat and this codec
> > currently.
> > A API user from his own demuxer or a future demuxer in libavformat could set
> > it though.
>
> understood, this patch is ok.
>
> i fear there are many of other places where signed test is done on
> bits_per_coded sample
> leading to shift explosion. given enough time, fuzz will eventually catch
> them all.
>
> how radical of a change would just making
> AVCodecParameters.bits_per_coded_sample unsigned be?
Ive just posted a patch that checks this for all decoders in a central place
this should avoid each decoder having to deal with it
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
signature.asc
Description: PGP signature
___
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]Fix build with --enable-hardcoded-tables
On Wed, Jun 19, 2019 at 01:43:28PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #7962 for me, please comment. > > Thank you, Carl Eugen > tableprint_vlc.h |1 + > 1 file changed, 1 insertion(+) > 9d5e5217e6a19d8e203da311a0cf108daf66129d > 0001-lavc-tableprint_vlc-Remove-avpriv_request_sample-fro.patch > From 2b82532897074d3f17c0a5f0a17da3a601d821d7 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Wed, 19 Jun 2019 13:41:01 +0200 > Subject: [PATCH] lavc/tableprint_vlc: Remove avpriv_request_sample() from > included files. > > Fixes compilation with --enable-hardcoded-tables. > Fixes ticket #7962. > --- > libavcodec/tableprint_vlc.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/tableprint_vlc.h b/libavcodec/tableprint_vlc.h > index 3004be3f9c..b3ff36562b 100644 > --- a/libavcodec/tableprint_vlc.h > +++ b/libavcodec/tableprint_vlc.h > @@ -36,6 +36,7 @@ > #define AVCODEC_AVCODEC_H > #define AVCODEC_INTERNAL_H > #define AV_INPUT_BUFFER_PADDING_SIZE 64 // the value does not matter for this > +#define avpriv_request_sample(...) > #include "tableprint.h" > #include "get_bits.h" > #include "mathtables.c" should be ok if tested thanks alot [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: PGP signature ___ 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 2/4] avcodec/hevc_ps: Fix integer overflow with num_tile_rows
On 6/19/2019 3:13 PM, Michael Niedermayer wrote:
> On Wed, Jun 19, 2019 at 12:54:25PM -0300, James Almer wrote:
>> On 6/19/2019 6:22 AM, Michael Niedermayer wrote:
>>> On Mon, Jun 17, 2019 at 07:55:45PM -0300, James Almer wrote:
On 6/17/2019 6:54 PM, Michael Niedermayer wrote:
> On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
>> On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
>>> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented
>>> in type 'int'
>>> Fixes:
>>> 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
>>>
>>> Found-by: continuous fuzzing process
>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavcodec/hevc_ps.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>>> index 80df417e4f..0ed6682bb4 100644
>>> --- a/libavcodec/hevc_ps.c
>>> +++ b/libavcodec/hevc_ps.c
>>> @@ -1596,7 +1596,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
>>> AVCodecContext *avctx,
>>> if (pps->num_tile_rows <= 0 ||
>>> pps->num_tile_rows >= sps->height) {
>>> av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of
>>> range: %d\n",
>>> - pps->num_tile_rows - 1);
>>> + pps->num_tile_rows - 1U);
>>
>> The proper fix for this is making pps->num_tile_rows/cols unsigned.
>>> [...]
>
> is this here ok if num_tile_rows is 0 ?
> for (i = 0; i < pps->num_tile_rows - 1; i++) { (example line from ffmpeg
> git)
>
> i would guess nearly everyone wold say yes without having seen the
> discussion about the type. but of course if this is unsigned its not
> going to be safe with it being 0.
pps->num_tile_rows is set to a value returned by "get_ue_golomb_long() +
1", which will always be in the 1..UINT32_MAX range. It can't be 0, as
it would be a bug. Int is definitely not the right type for it.
>>>
>>> i dont think num_tile_rows of more than 2^31 (that is the negative when
>>> signed range)
>>> makes much sense but sure i can change it to unsigned if preferred.
>>
>> Of course it doesn't. In pretty much any sample it will be at least 1
>> and at most 22, which is the max value allowed by hevc level 6.2 in
>> table A.6. Only if the stream reports an undefined level it could go up
>> to, if i'm reading this right, sps->ctb_height and not sps->height as
>> the decoder is currently checking. This means you can even replace
>> get_ue_golomb_long() for a get_ue_golomb(). That would also fix this.
>>
>> In any case, the bitstream value is unsigned, so the struct field should
>> be unsigned as well. Having it be signed and assigning it a value using
>> a function that potentially returns huge unsigned values introduced this
>> issue to being with, so instead of working around it using type
>> promotion, just make it follow the spec.
>
> what would be your feeling/oppinon about making the field uint16_t ?
> this would make it unsigned in the struct but avoid the problems with
> unsigned int ?
That's fine. Could even make it uint8_t, like cbs_h265.h does. I'd also
change it to use get_ue_golomb() while at it. And please do it for both
rows and columns. Can be in separate patches if you want the rows one to
explicitly address the fuzzing testcase.
Can you also confirm my suspicion that the checks should be comparing
the values with sps->ctb_height/weight and not with sps->height/weight?
>
> Thanks
>
> [...]
>
>
> ___
> 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".
Re: [FFmpeg-devel] [PATCH] libavcodec: Reduce the size of some arrays
On Wed, Jun 19, 2019 at 04:39:47AM +0200, Andreas Rheinhardt wrote: > This commit uses smaller types for some static const arrays to reduce > their size in case the entries can be represented in the smaller type. > The biggest savings came from inv_map_table in vp9.c. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/a64multienc.c | 6 +++--- > libavcodec/ac3enc.c | 2 +- > libavcodec/adpcm.c| 8 > libavcodec/aic.c | 4 ++-- > libavcodec/atrac3plus.c | 12 ++-- > libavcodec/atrac3plusdsp.c| 4 ++-- > libavcodec/atrac9dec.c| 2 +- > libavcodec/cbs_h264_syntax_template.c | 2 +- > libavcodec/cbs_vp9_syntax_template.c | 4 ++-- > libavcodec/vp9.c | 2 +- > 10 files changed, 23 insertions(+), 23 deletions(-) should be ok thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___ 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 v3] vf_drawtext - Add variables
Adds pkt_pos, pkt_duration, and pkt_size to drawtext as variables for text expansion, and adds documentation for pict_type which already exists. [PATCH v3] vf_drawtext - Add variables.patch Description: Binary data ___ 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] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
On 6/19/2019 3:19 PM, Bodecs Bela wrote: > > 2019.06.19. 19:37 keltezéssel, Michael Niedermayer írta: >> On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: >>> ffmpeg | branch: master | Bodecs Bela | Mon Jun >>> 17 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | >>> committer: Steven Liu >>> >>> av_format/hlsenc: fix %v handling by format_name function >>> >>> Hi All, >>> >>> When multiple variant streams are specified by var_stream_map option, %v >>> placeholder in various names ensures that each variant has its unique >>> names. Most of %v handlng is done in format_name function. Currently >>> in this function the result buffer is the same as the >>> input pattern buffer, so you must allocate it before calling format_name >>> function. It also means, that it is silently assumed that the result >>> string will NOT be >>> longer that the pattern string. It is true most of the time, because %v >>> may appear only once in the pattern string and number of variant streams >>> is less than 100 in practical cases. But theoretically it will fail if >>> specified number of variant streams is greater than 100 (i.e. longer >>> than 2 digits). >>> This patch fixes this behaviour by altering format_name function to >>> allocate the >>> result buffer and return it to the caller. >>> >>> Please, review this patch. >>> >>> best, >>> >>> Bela >>> >From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 >>> From: Bela Bodecs >>> Date: Mon, 17 Jun 2019 14:31:36 +0200 >>> Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name >>> function >>> >>> When multiple variant streams are specified by var_stream_map option, %v >>> placeholder in various names ensures that each variant has its unique >>> names. Most of %v handlng is done in format_name function. Currently >>> in this function the result buffer is the same as the input pattern >>> buffer, so you must allocate it before calling format_name function. It >>> also means, that it is silently assumed that the result string will NOT >>> be longer that the pattern string. It is true most of the time, because >>> %v may appear only once in the pattern string and number of variant >>> streams is less than 100 in practical cases. But theoretically it will >>> fail if specified number of variant streams is greater than 100. This >>> patch fixes this behaviour by altering format_name function to allocate >>> the result buffer and return it to the caller. >>> >>> Signed-off-by: Bela Bodecs >> This broke fate (segfaults) also it produces new compiler warnings which >> probably are pointing to the cause >> >> libavformat/hlsenc.c: In function ‘hls_init’: >> libavformat/hlsenc.c:2643:9: warning: passing argument 2 of >> ‘format_name’ makes pointer from integer without a cast [enabled by >> default] >> ret = format_name(s->url, i, vs->m3u8_name); >> ^ >> libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is >> of type ‘int’ >> static int format_name(const char *buf, char **s, int index) >> ^ >> libavformat/hlsenc.c:2643:9: warning: passing argument 3 of >> ‘format_name’ makes integer from pointer without a cast [enabled by >> default] >> ret = format_name(s->url, i, vs->m3u8_name); >> ^ >> libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of >> type ‘char *’ >> static int format_name(const char *buf, char **s, int index) >> ^ >> libavformat/hlsenc.c:2712:13: warning: passing argument 2 of >> ‘format_name’ makes pointer from integer without a cast [enabled by >> default] >> ret = format_name(vs->basename, basename_size, i); >> ^ >> libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is >> of type ‘int’ >> static int format_name(const char *buf, char **s, int index) >> ^ >> libavformat/hlsenc.c:2767:25: warning: passing argument 2 of >> ‘format_name’ makes pointer from integer without a cast [enabled by >> default] >> format_name(vs->fmp4_init_filename, >> fmp4_init_filename_len, i); >> ^ >> libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is >> of type ‘int’ >> static int format_name(const char *buf, char **s, int index) >> ^ >> libavformat/hlsenc.c:2832:17: warning: passing argument 2 of >> ‘format_name’ makes pointer from integer without a cast [enabled by >> default] >> ret = format_name(vs->vtt_m3u8_name, >> vtt_basename_size, i); >> ^ >> libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is >> of type ‘int’ >> static int format_name(const char *buf, char **s, int index) >> >> >> [...] >> > Are you sure, you have applied my patch file? Because in the patch the > first error should not have been: > > - ret = format_name(s->url, i, vs->m3u8_name); > + ret = format_name(s->url, &vs->m3u8_name, i, vs->varname); > > b
Re: [FFmpeg-devel] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
2019.06.19. 19:37 keltezéssel, Michael Niedermayer írta: On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: ffmpeg | branch: master | Bodecs Bela | Mon Jun 17 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | committer: Steven Liu av_format/hlsenc: fix %v handling by format_name function Hi All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100 (i.e. longer than 2 digits). This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Please, review this patch. best, Bela >From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Mon, 17 Jun 2019 14:31:36 +0200 Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100. This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Signed-off-by: Bela Bodecs This broke fate (segfaults) also it produces new compiler warnings which probably are pointing to the cause libavformat/hlsenc.c: In function ‘hls_init’: libavformat/hlsenc.c:2643:9: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2643:9: warning: passing argument 3 of ‘format_name’ makes integer from pointer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of type ‘char *’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2712:13: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->basename, basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2767:25: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] format_name(vs->fmp4_init_filename, fmp4_init_filename_len, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2832:17: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->vtt_m3u8_name, vtt_basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) [...] Dear Michael, thank you for review my patch. This patch requires one of my earlier other patch to be applied. Steven Liu applied that earlier patch very shortly before you tested this patch. Maybe you applied this patch against an earlier head than Seven Liu applied the necessary patch? I have tested the current head with my sent public patch file without any problem. The commands I have used at 2019jun19 22:40 git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg cd ffmpeg git apply --stat 0003-avformat-hlsenc-enhanced-v-handling-with-variant-nam.patch git apply --check 0003-avformat-hlsenc-enhanced-v-
[FFmpeg-devel] [PATCH 2/3] avcodec/alsdec: Fix undefined behavior in decode_rice()
Fixes: left shift of 72 by 26 places cannot be represented in type 'int'
Fixes:
15279/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5700665621348352
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/alsdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index da6285cab0..b7ce5c7844 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -487,7 +487,7 @@ static void parse_bs_info(const uint32_t bs_info, unsigned
int n,
static int32_t decode_rice(GetBitContext *gb, unsigned int k)
{
int max = get_bits_left(gb) - k;
-int q = get_unary(gb, 0, max);
+unsigned q = get_unary(gb, 0, max);
int r = k ? get_bits1(gb) : !(q & 1);
if (k > 1) {
--
2.22.0
___
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 3/3] avcodec/alsdec: Fix integer overflow with shifting samples
Fixes: signed integer overflow: -346039050 * 8 cannot be represented in type 'int' Fixes: 15283/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5692700268953600 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/alsdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c index b7ce5c7844..e50a287f19 100644 --- a/libavcodec/alsdec.c +++ b/libavcodec/alsdec.c @@ -1033,7 +1033,7 @@ static int decode_block(ALSDecContext *ctx, ALSBlockData *bd) if (*bd->shift_lsbs) for (smp = 0; smp < bd->block_length; smp++) -bd->raw_samples[smp] <<= *bd->shift_lsbs; +bd->raw_samples[smp] = (unsigned)bd->raw_samples[smp] << *bd->shift_lsbs; return 0; } -- 2.22.0 ___ 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 1/3] avcodec/alsdec: Fixes invalid shifts in read_var_block_data() and INTERLEAVE_OUTPUT()
Fixes: left shift of negative value -6
Fixes:
15275/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5742361767837696
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/alsdec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index ca8701e6d0..da6285cab0 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -767,8 +767,8 @@ static int read_var_block_data(ALSDecContext *ctx,
ALSBlockData *bd)
if (*bd->use_ltp) {
int r, c;
-bd->ltp_gain[0] = decode_rice(gb, 1) << 3;
-bd->ltp_gain[1] = decode_rice(gb, 2) << 3;
+bd->ltp_gain[0] = decode_rice(gb, 1) * 8;
+bd->ltp_gain[1] = decode_rice(gb, 2) * 8;
r = get_unary(gb, 0, 4);
c = get_bits(gb, 2);
@@ -779,8 +779,8 @@ static int read_var_block_data(ALSDecContext *ctx,
ALSBlockData *bd)
bd->ltp_gain[2] = ltp_gain_values[r][c];
-bd->ltp_gain[3] = decode_rice(gb, 2) << 3;
-bd->ltp_gain[4] = decode_rice(gb, 1) << 3;
+bd->ltp_gain[3] = decode_rice(gb, 2) * 8;
+bd->ltp_gain[4] = decode_rice(gb, 1) * 8;
*bd->ltp_lag = get_bits(gb, ctx->ltp_lag_length);
*bd->ltp_lag += FFMAX(4, opt_order + 1);
@@ -1796,11 +1796,11 @@ static int decode_frame(AVCodecContext *avctx, void
*data, int *got_frame_ptr,
if (!ctx->cs_switch) {
\
for (sample = 0; sample < ctx->cur_frame_length; sample++)
\
for (c = 0; c < avctx->channels; c++)
\
-*dest++ = ctx->raw_samples[c][sample] << shift;
\
+*dest++ = ctx->raw_samples[c][sample] * (1 << shift);
\
} else {
\
for (sample = 0; sample < ctx->cur_frame_length; sample++)
\
for (c = 0; c < avctx->channels; c++)
\
-*dest++ = ctx->raw_samples[sconf->chan_pos[c]][sample] <<
shift; \
+*dest++ = ctx->raw_samples[sconf->chan_pos[c]][sample] *
(1 << shift); \
}
\
}
--
2.22.0
___
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 v3] vf_drawtext - Add variables
> Am 19.06.2019 um 22:45 schrieb greg Luce : > > Adds pkt_pos, pkt_duration, and pkt_size to drawtext as variables for > text expansion, and adds documentation for pict_type which already > exists. Who has written the patch that you attached? Thank you, Carl Eugen ___ 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] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
2019.06.19. 23:49 keltezéssel, Bodecs Bela írta: 2019.06.19. 19:37 keltezéssel, Michael Niedermayer írta: On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: ffmpeg | branch: master | Bodecs Bela | Mon Jun 17 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | committer: Steven Liu av_format/hlsenc: fix %v handling by format_name function Hi All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100 (i.e. longer than 2 digits). This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Please, review this patch. best, Bela >From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Mon, 17 Jun 2019 14:31:36 +0200 Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100. This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Signed-off-by: Bela Bodecs This broke fate (segfaults) also it produces new compiler warnings which probably are pointing to the cause libavformat/hlsenc.c: In function ‘hls_init’: libavformat/hlsenc.c:2643:9: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2643:9: warning: passing argument 3 of ‘format_name’ makes integer from pointer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of type ‘char *’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2712:13: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->basename, basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2767:25: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] format_name(vs->fmp4_init_filename, fmp4_init_filename_len, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2832:17: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->vtt_m3u8_name, vtt_basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) [...] Dear Michael, thank you for review my patch. This patch requires one of my earlier other patch to be applied. Steven Liu applied that earlier patch very shortly before you tested this patch. Maybe you applied this patch against an earlier head than Seven Liu applied the necessary patch? I have tested the current head with my sent public patch file without any problem. The commands I have used at 2019jun19 22:40 git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg cd ffmpeg git apply --stat 0003-avformat-hlsenc-enhanced-v-handl
Re: [FFmpeg-devel] [PATCH v3] vf_drawtext - Add variables
> Who has written the patch that you attached? > > Thank you, Carl Eugen The C code was written by kepstin I wrote the change to the documentation with help from several people There's a trac ticket at https://trac.ffmpeg.org/ticket/7947 ___ 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] [V2] Updated version
I have incorporated James' suggestions regarding the comments. This of course necessitated a rebase and because there were merge conflicts to be solved in h264_redundant_pps I'm resending all patches after #9. I also add the patches from my earlier patchsets [1] (dealing mostly with mpeg2) and [2] (about updating the AVCodecParameters). - Andreas [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/244952.html [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/236990.html Andreas Rheinhardt (22): av1_metadata: Error out if fragment is empty cbs: Remove superfluous checks for ff_cbs_delete_unit cbs_h264, h264_metadata: Deleting SEI messages never fails h264_redundant_pps: Avoid allocations and copies of packet structures h264_redundant_pps: Fix looping over an access unit's units h265_metadata: Avoid allocations and copies of packet structures h265_metadata: Correct error check mpeg2_metadata: Avoid allocations and copies of packet structures mpeg2_metadata: Localize inserting of sequence display extensions vp9_metadata: Avoid allocations and copies of packet structures mpeg2_metadata, cbs_mpeg2: Fix handling of colour_description cbs: Remove useless initializations cbs_mpeg2: Fix parsing of picture and slice headers cbs_mpeg2: Remove zero byte stuffing av1/h264_metadata: Don't reinitialize data cbs: Add function to update video codec parameters av1_metadata: Add option to update codec parameters mpeg2_metadata: Additionally update AVCodecParameters vp9_metadata: Improve spec-compliance and warnings vp9_metadata: Update AVCodecParameters h264_metadata: Update AVCodecParameters hevc_metadata: Update AVCodecParameters doc/bitstream_filters.texi | 43 - libavcodec/av1_metadata_bsf.c | 64 ++ libavcodec/cbs.c | 35 libavcodec/cbs.h | 17 libavcodec/cbs_av1.c | 14 +-- libavcodec/cbs_h264.h | 8 +- libavcodec/cbs_h2645.c | 22 ++--- libavcodec/cbs_jpeg.c | 2 +- libavcodec/cbs_mpeg2.c | 86 +- libavcodec/cbs_mpeg2.h | 14 +-- libavcodec/cbs_mpeg2_syntax_template.c | 76 +--- libavcodec/cbs_vp9.c | 8 +- libavcodec/filter_units_bsf.c | 1 + libavcodec/h264_metadata_bsf.c | 116 ++--- libavcodec/h264_redundant_pps_bsf.c| 26 +++--- libavcodec/h265_metadata_bsf.c | 64 ++ libavcodec/mpeg2_metadata_bsf.c| 73 +--- libavcodec/vp9_metadata_bsf.c | 80 - tests/ref/fate/cbs-mpeg2-sony-ct3 | 2 +- 19 files changed, 500 insertions(+), 251 deletions(-) -- 2.21.0 ___ 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 10/31] av1_metadata: Error out if fragment is empty
If the fragment is empty after parsing (i.e. it contains no OBUs), then
the check for the type of the fragment's first OBU is nonsensical; so
error out in this case just as h264_metadata and hevc_metadata do.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/av1_metadata_bsf.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
index 842b80c201..bb2ca2075b 100644
--- a/libavcodec/av1_metadata_bsf.c
+++ b/libavcodec/av1_metadata_bsf.c
@@ -133,6 +133,12 @@ static int av1_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
goto fail;
}
+if (frag->nb_units == 0) {
+av_log(bsf, AV_LOG_ERROR, "No OBU in packet.\n");
+err = AVERROR_INVALIDDATA;
+goto fail;
+}
+
for (i = 0; i < frag->nb_units; i++) {
if (frag->units[i].type == AV1_OBU_SEQUENCE_HEADER) {
obu = frag->units[i].content;
--
2.21.0
___
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 11/31] cbs: Remove superfluous checks for ff_cbs_delete_unit
ff_cbs_delete_unit never fails if the index of the unit to delete is
valid; document this behaviour explicitly and remove the checks for
whether ff_cbs_delete_unit failed, because all the callers of
ff_cbs_delete_unit already made sure the index to be valid. And add some
comments to the callers to ensure that it stays that way.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/av1_metadata_bsf.c | 12 +---
libavcodec/cbs.h| 2 ++
libavcodec/filter_units_bsf.c | 1 +
libavcodec/h264_metadata_bsf.c | 10 --
libavcodec/h264_redundant_pps_bsf.c | 5 ++---
libavcodec/h265_metadata_bsf.c | 2 ++
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
index bb2ca2075b..9345095277 100644
--- a/libavcodec/av1_metadata_bsf.c
+++ b/libavcodec/av1_metadata_bsf.c
@@ -151,6 +151,8 @@ static int av1_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
// If a Temporal Delimiter is present, it must be the first OBU.
if (frag->units[0].type == AV1_OBU_TEMPORAL_DELIMITER) {
if (ctx->td == REMOVE)
+// This call never fails because we have already excluded
+// fragments without a single unit.
ff_cbs_delete_unit(ctx->cbc, frag, 0);
} else if (ctx->td == INSERT) {
td = (AV1RawOBU) {
@@ -167,13 +169,9 @@ static int av1_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
if (ctx->delete_padding) {
for (i = frag->nb_units - 1; i >= 0; i--) {
-if (frag->units[i].type == AV1_OBU_PADDING) {
-err = ff_cbs_delete_unit(ctx->cbc, frag, i);
-if (err < 0) {
-av_log(bsf, AV_LOG_ERROR, "Failed to delete Padding
OBU.\n");
-goto fail;
-}
-}
+if (frag->units[i].type == AV1_OBU_PADDING)
+// This call never fails as the fragment has a unit at pos. i.
+ff_cbs_delete_unit(ctx->cbc, frag, i);
}
}
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index 5260a39c63..e1e6055ceb 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -380,6 +380,8 @@ int ff_cbs_insert_unit_data(CodedBitstreamContext *ctx,
/**
* Delete a unit from a fragment and free all memory it uses.
+ *
+ * Never returns failure if position is >= 0 and < frag->nb_units.
*/
int ff_cbs_delete_unit(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag,
diff --git a/libavcodec/filter_units_bsf.c b/libavcodec/filter_units_bsf.c
index 380f23e5a7..3068e464f0 100644
--- a/libavcodec/filter_units_bsf.c
+++ b/libavcodec/filter_units_bsf.c
@@ -124,6 +124,7 @@ static int filter_units_filter(AVBSFContext *bsf, AVPacket
*pkt)
}
if (ctx->mode == REMOVE ? j < ctx->nb_types
: j >= ctx->nb_types)
+// This call never fails as the fragment has a unit at pos. i.
ff_cbs_delete_unit(ctx->cbc, frag, i);
}
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index f7ca1f0f09..e3c29cc9ad 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -309,6 +309,8 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
// If an AUD is present, it must be the first NAL unit.
if (au->units[0].type == H264_NAL_AUD) {
if (ctx->aud == REMOVE)
+// This call never fails because we have already excluded
+// access units without a single unit.
ff_cbs_delete_unit(ctx->cbc, au, 0);
} else {
if (ctx->aud == INSERT) {
@@ -428,12 +430,8 @@ static int h264_metadata_filter(AVBSFContext *bsf,
AVPacket *pkt)
for (i = au->nb_units - 1; i >= 0; i--) {
if (au->units[i].type == H264_NAL_FILLER_DATA) {
// Filler NAL units.
-err = ff_cbs_delete_unit(ctx->cbc, au, i);
-if (err < 0) {
-av_log(bsf, AV_LOG_ERROR, "Failed to delete "
- "filler NAL.\n");
-goto fail;
-}
+// This call never fails as the fragment has a unit at pos. i.
+ff_cbs_delete_unit(ctx->cbc, au, i);
continue;
}
diff --git a/libavcodec/h264_redundant_pps_bsf.c
b/libavcodec/h264_redundant_pps_bsf.c
index db8717d69a..f59c4f57c0 100644
--- a/libavcodec/h264_redundant_pps_bsf.c
+++ b/libavcodec/h264_redundant_pps_bsf.c
@@ -95,9 +95,8 @@ static int h264_redundant_pps_filter(AVBSFContext *bsf,
AVPacket *out)
if (!au_has_sps) {
av_log(bsf, AV_LOG_VERBOSE, "Deleting redundant PPS "
"at %"PRId64".\n", in->pts);
-err = ff_cbs_delete_unit(ctx->input, au, i);
-if (err < 0)
-goto fail;
+// This call never fails as the frag
[FFmpeg-devel] [PATCH 12/31] cbs_h264, h264_metadata: Deleting SEI messages never fails
Deleting a unit from a fragment in CBS only fails if there is no unit
in the fragment corresponding to the position given as argument to
ff_cbs_delete_unit. Given that ff_cbs_h264_delete_sei_message asserts
this to be so, we know that the call to ff_cbs_delete_unit can never
fail and hence ff_cbs_h264_delete_sei_message doesn't need a return
value at all. The existing checks for these return values can be deleted.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h264.h | 8
libavcodec/cbs_h2645.c | 14 +++---
libavcodec/h264_metadata_bsf.c | 21 +
3 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index a31be298ba..f63c19ffc0 100644
--- a/libavcodec/cbs_h264.h
+++ b/libavcodec/cbs_h264.h
@@ -479,9 +479,9 @@ int ff_cbs_h264_add_sei_message(CodedBitstreamContext *ctx,
* Deletes from nal_unit, which must be an SEI NAL unit. If this is the
* last message in nal_unit, also deletes it from access_unit.
*/
-int ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
- CodedBitstreamFragment *access_unit,
- CodedBitstreamUnit *nal_unit,
- int position);
+void ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
+CodedBitstreamFragment *access_unit,
+CodedBitstreamUnit *nal_unit,
+int position);
#endif /* AVCODEC_CBS_H264_H */
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 0456937710..117e13e0c7 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1644,10 +1644,10 @@ int ff_cbs_h264_add_sei_message(CodedBitstreamContext
*ctx,
return 0;
}
-int ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
- CodedBitstreamFragment *au,
- CodedBitstreamUnit *nal,
- int position)
+void ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
+CodedBitstreamFragment *au,
+CodedBitstreamUnit *nal,
+int position)
{
H264RawSEI *sei = nal->content;
@@ -1664,7 +1664,9 @@ int ff_cbs_h264_delete_sei_message(CodedBitstreamContext
*ctx,
}
av_assert0(i < au->nb_units && "NAL unit not in access unit.");
-return ff_cbs_delete_unit(ctx, au, i);
+// This call never fails because we already asserted
+// that i is a valid index of one of au's units.
+ff_cbs_delete_unit(ctx, au, i);
} else {
cbs_h264_free_sei_payload(&sei->payload[position]);
@@ -1672,7 +1674,5 @@ int ff_cbs_h264_delete_sei_message(CodedBitstreamContext
*ctx,
memmove(sei->payload + position,
sei->payload + position + 1,
(sei->payload_count - position) * sizeof(*sei->payload));
-
-return 0;
}
}
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index e3c29cc9ad..d760ee3182 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -441,15 +441,9 @@ static int h264_metadata_filter(AVBSFContext *bsf,
AVPacket *pkt)
for (j = sei->payload_count - 1; j >= 0; j--) {
if (sei->payload[j].payload_type ==
-H264_SEI_TYPE_FILLER_PAYLOAD) {
-err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
- &au->units[i], j);
-if (err < 0) {
-av_log(bsf, AV_LOG_ERROR, "Failed to delete "
- "filler SEI message.\n");
-goto fail;
-}
-}
+H264_SEI_TYPE_FILLER_PAYLOAD)
+ff_cbs_h264_delete_sei_message(ctx->cbc, au,
+ &au->units[i], j);
}
}
}
@@ -473,13 +467,8 @@ static int h264_metadata_filter(AVBSFContext *bsf,
AVPacket *pkt)
if (ctx->display_orientation == REMOVE ||
ctx->display_orientation == INSERT) {
-err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
- &au->units[i], j);
-if (err < 0) {
-av_log(bsf, AV_LOG_ERROR, "Failed to delete "
- "display orientation SEI message.\n");
-goto fail;
-}
+ff_cbs_h264_delete_sei_message(ctx->cbc, au,
+ &au->units[i], j);
continue;
[FFmpeg-devel] [PATCH 13/31] h264_redundant_pps: Avoid allocations and copies of packet structures
This commit changes h264_redundant_pps to (a) use ff_bsf_get_packet_ref
instead of ff_bsf_get_packet (thereby avoiding one malloc and free per
filtered packet) and (b) to use only one packet structure at all,
thereby avoiding a call to av_packet_copy_props.
(b) has been made possible by the recent changes to ff_cbs_write_packet.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_redundant_pps_bsf.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/libavcodec/h264_redundant_pps_bsf.c
b/libavcodec/h264_redundant_pps_bsf.c
index f59c4f57c0..e1f8f673f9 100644
--- a/libavcodec/h264_redundant_pps_bsf.c
+++ b/libavcodec/h264_redundant_pps_bsf.c
@@ -66,19 +66,18 @@ static int
h264_redundant_pps_fixup_slice(H264RedundantPPSContext *ctx,
return 0;
}
-static int h264_redundant_pps_filter(AVBSFContext *bsf, AVPacket *out)
+static int h264_redundant_pps_filter(AVBSFContext *bsf, AVPacket *pkt)
{
H264RedundantPPSContext *ctx = bsf->priv_data;
-AVPacket *in;
CodedBitstreamFragment *au = &ctx->access_unit;
int au_has_sps;
int err, i;
-err = ff_bsf_get_packet(bsf, &in);
+err = ff_bsf_get_packet_ref(bsf, pkt);
if (err < 0)
return err;
-err = ff_cbs_read_packet(ctx->input, au, in);
+err = ff_cbs_read_packet(ctx->input, au, pkt);
if (err < 0)
goto fail;
@@ -94,7 +93,7 @@ static int h264_redundant_pps_filter(AVBSFContext *bsf,
AVPacket *out)
goto fail;
if (!au_has_sps) {
av_log(bsf, AV_LOG_VERBOSE, "Deleting redundant PPS "
- "at %"PRId64".\n", in->pts);
+ "at %"PRId64".\n", pkt->pts);
// This call never fails as the fragment has a unit at pos. i.
ff_cbs_delete_unit(ctx->input, au, i);
}
@@ -106,21 +105,15 @@ static int h264_redundant_pps_filter(AVBSFContext *bsf,
AVPacket *out)
}
}
-err = ff_cbs_write_packet(ctx->output, out, au);
-if (err < 0)
-goto fail;
-
-
-err = av_packet_copy_props(out, in);
+err = ff_cbs_write_packet(ctx->output, pkt, au);
if (err < 0)
goto fail;
err = 0;
fail:
ff_cbs_fragment_reset(ctx->output, au);
-av_packet_free(&in);
if (err < 0)
-av_packet_unref(out);
+av_packet_unref(pkt);
return err;
}
--
2.21.0
___
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 16/31] h265_metadata: Correct error check
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h265_metadata_bsf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
index 6009a1990d..2f28342a26 100644
--- a/libavcodec/h265_metadata_bsf.c
+++ b/libavcodec/h265_metadata_bsf.c
@@ -291,7 +291,7 @@ static int h265_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
err = ff_cbs_insert_unit_content(ctx->cbc, au,
0, HEVC_NAL_AUD, aud, NULL);
-if (err) {
+if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to insert AUD.\n");
goto fail;
}
--
2.21.0
___
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 15/31] h265_metadata: Avoid allocations and copies of packet structures
This commit changes h265_metadata to (a) use ff_bsf_get_packet_ref
instead of ff_bsf_get_packet (thereby avoiding one malloc and free per
filtered packet) and (b) to use only one packet structure at all,
thereby avoiding a call to av_packet_copy_props.
(b) has been made possible by the recent changes to ff_cbs_write_packet.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h265_metadata_bsf.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
index 3436f3d0a3..6009a1990d 100644
--- a/libavcodec/h265_metadata_bsf.c
+++ b/libavcodec/h265_metadata_bsf.c
@@ -230,18 +230,17 @@ static int h265_metadata_update_sps(AVBSFContext *bsf,
return 0;
}
-static int h265_metadata_filter(AVBSFContext *bsf, AVPacket *out)
+static int h265_metadata_filter(AVBSFContext *bsf, AVPacket *pkt)
{
H265MetadataContext *ctx = bsf->priv_data;
-AVPacket *in = NULL;
CodedBitstreamFragment *au = &ctx->access_unit;
int err, i;
-err = ff_bsf_get_packet(bsf, &in);
+err = ff_bsf_get_packet_ref(bsf, pkt);
if (err < 0)
return err;
-err = ff_cbs_read_packet(ctx->cbc, au, in);
+err = ff_cbs_read_packet(ctx->cbc, au, pkt);
if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to read packet.\n");
goto fail;
@@ -312,23 +311,18 @@ static int h265_metadata_filter(AVBSFContext *bsf,
AVPacket *out)
}
}
-err = ff_cbs_write_packet(ctx->cbc, out, au);
+err = ff_cbs_write_packet(ctx->cbc, pkt, au);
if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
goto fail;
}
-err = av_packet_copy_props(out, in);
-if (err < 0)
-goto fail;
-
err = 0;
fail:
ff_cbs_fragment_reset(ctx->cbc, au);
if (err < 0)
-av_packet_unref(out);
-av_packet_free(&in);
+av_packet_unref(pkt);
return err;
}
--
2.21.0
___
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 17/31] mpeg2_metadata: Avoid allocations and copies of packet structures
This commit changes mpeg2_metadata to (a) use ff_bsf_get_packet_ref
instead of ff_bsf_get_packet (thereby avoiding one malloc and free per
filtered packet) and (b) to use only one packet structure at all,
thereby avoiding a call to av_packet_copy_props.
(b) has been made possible by the recent changes to ff_cbs_write_packet.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg2_metadata_bsf.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index ba3a74afda..082137d786 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -179,18 +179,17 @@ static int mpeg2_metadata_update_fragment(AVBSFContext
*bsf,
return 0;
}
-static int mpeg2_metadata_filter(AVBSFContext *bsf, AVPacket *out)
+static int mpeg2_metadata_filter(AVBSFContext *bsf, AVPacket *pkt)
{
MPEG2MetadataContext *ctx = bsf->priv_data;
-AVPacket *in = NULL;
CodedBitstreamFragment *frag = &ctx->fragment;
int err;
-err = ff_bsf_get_packet(bsf, &in);
+err = ff_bsf_get_packet_ref(bsf, pkt);
if (err < 0)
return err;
-err = ff_cbs_read_packet(ctx->cbc, frag, in);
+err = ff_cbs_read_packet(ctx->cbc, frag, pkt);
if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to read packet.\n");
goto fail;
@@ -202,23 +201,18 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf,
AVPacket *out)
goto fail;
}
-err = ff_cbs_write_packet(ctx->cbc, out, frag);
+err = ff_cbs_write_packet(ctx->cbc, pkt, frag);
if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
goto fail;
}
-err = av_packet_copy_props(out, in);
-if (err < 0)
-goto fail;
-
err = 0;
fail:
ff_cbs_fragment_reset(ctx->cbc, frag);
if (err < 0)
-av_packet_unref(out);
-av_packet_free(&in);
+av_packet_unref(pkt);
return err;
}
--
2.21.0
___
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 14/31] h264_redundant_pps: Fix looping over an access unit's units
When looping over an access unit's units in positive direction and deleting some of them, one needs to make sure that a unit that is at the position of a unit that just got deleted gets checked, too. Signed-off-by: Andreas Rheinhardt --- libavcodec/h264_redundant_pps_bsf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/h264_redundant_pps_bsf.c b/libavcodec/h264_redundant_pps_bsf.c index e1f8f673f9..ed34f9dc6e 100644 --- a/libavcodec/h264_redundant_pps_bsf.c +++ b/libavcodec/h264_redundant_pps_bsf.c @@ -96,6 +96,8 @@ static int h264_redundant_pps_filter(AVBSFContext *bsf, AVPacket *pkt) "at %"PRId64".\n", pkt->pts); // This call never fails as the fragment has a unit at pos. i. ff_cbs_delete_unit(ctx->input, au, i); +i--; +continue; } } if (nal->type == H264_NAL_SLICE || -- 2.21.0 ___ 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 18/31] mpeg2_metadata: Localize inserting of sequence display extensions
If a new sequence display extension had to be added, this was up until
now done at two places: One where a sequence display extension was
initialized with default values and one where the actual sequence
display extension was inserted into the fragment. This division of
labour is unnecessary and pointless; it has been changed.
Furthermore, if a sequence display extension has to be added, the
earlier code set some fields to their default value twice. This has been
changed, too.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg2_metadata_bsf.c | 34 -
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index 082137d786..6779ffd4c4 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -53,7 +53,7 @@ static int mpeg2_metadata_update_fragment(AVBSFContext *bsf,
MPEG2RawSequenceHeader*sh = NULL;
MPEG2RawSequenceExtension *se = NULL;
MPEG2RawSequenceDisplayExtension *sde = NULL;
-int i, se_pos, add_sde = 0;
+int i, se_pos;
for (i = 0; i < frag->nb_units; i++) {
if (frag->units[i].type == MPEG2_START_SEQUENCE_HEADER) {
@@ -115,7 +115,7 @@ static int mpeg2_metadata_update_fragment(AVBSFContext *bsf,
ctx->transfer_characteristics >= 0 ||
ctx->matrix_coefficients >= 0) {
if (!sde) {
-add_sde = 1;
+int err;
ctx->sequence_display_extension.extension_start_code =
MPEG2_START_EXTENSION;
ctx->sequence_display_extension.extension_start_code_identifier =
@@ -135,6 +135,16 @@ static int mpeg2_metadata_update_fragment(AVBSFContext
*bsf,
.display_vertical_size =
se->vertical_size_extension << 12 |
sh->vertical_size_value,
};
+
+err = ff_cbs_insert_unit_content(ctx->cbc, frag, se_pos + 1,
+ MPEG2_START_EXTENSION,
+ &ctx->sequence_display_extension,
+ NULL);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to insert new sequence "
+ "display extension.\n");
+return err;
+}
}
if (ctx->video_format >= 0)
@@ -147,32 +157,12 @@ static int mpeg2_metadata_update_fragment(AVBSFContext
*bsf,
if (ctx->colour_primaries >= 0)
sde->colour_primaries = ctx->colour_primaries;
-else if (add_sde)
-sde->colour_primaries = 2;
if (ctx->transfer_characteristics >= 0)
sde->transfer_characteristics = ctx->transfer_characteristics;
-else if (add_sde)
-sde->transfer_characteristics = 2;
if (ctx->matrix_coefficients >= 0)
sde->matrix_coefficients = ctx->matrix_coefficients;
-else if (add_sde)
-sde->matrix_coefficients = 2;
-}
-}
-
-if (add_sde) {
-int err;
-
-err = ff_cbs_insert_unit_content(ctx->cbc, frag, se_pos + 1,
- MPEG2_START_EXTENSION,
- &ctx->sequence_display_extension,
- NULL);
-if (err < 0) {
-av_log(bsf, AV_LOG_ERROR, "Failed to insert new sequence "
- "display extension.\n");
-return err;
}
}
--
2.21.0
___
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 20/31] mpeg2_metadata, cbs_mpeg2: Fix handling of colour_description
If a sequence display extension is read with colour_description equal to
zero, but a user wants to add one or more of the colour_description
elements, then the colour_description elements the user did not explicitly
request to be set are set to zero and not to the value equal to
unknown/unspecified (namely 2). A value of zero is not only inappropriate,
but explicitly forbidden. This is fixed by inferring the right default
values during the reading process if the elements are absent; moreover,
changing any of the colour_description elements to zero is now no longer
possible.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_mpeg2.c | 15 +++
libavcodec/cbs_mpeg2_syntax_template.c | 4
libavcodec/mpeg2_metadata_bsf.c| 12
3 files changed, 31 insertions(+)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index cb202f835b..ac2a7b0b1a 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -82,6 +82,10 @@
(get_bits_left(rw) >= width && \
(var = show_bits(rw, width)) == (compare))
+#define infer(name, value) do { \
+current->name = value; \
+} while (0)
+
#include "cbs_mpeg2_syntax_template.c"
#undef READ
@@ -91,6 +95,7 @@
#undef xsi
#undef marker_bit
#undef nextbits
+#undef infer
#define WRITE
@@ -116,6 +121,15 @@
#define nextbits(width, compare, var) (var)
+#define infer(name, value) do { \
+if (current->name != (value)) { \
+av_log(ctx->log_ctx, AV_LOG_WARNING, "Warning: " \
+ "%s does not match inferred value: " \
+ "%"PRId64", but should be %"PRId64".\n", \
+ #name, (int64_t)current->name, (int64_t)(value)); \
+} \
+} while (0)
+
#include "cbs_mpeg2_syntax_template.c"
#undef WRITE
@@ -125,6 +139,7 @@
#undef xsi
#undef marker_bit
#undef nextbits
+#undef infer
static void cbs_mpeg2_free_user_data(void *unit, uint8_t *content)
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c
b/libavcodec/cbs_mpeg2_syntax_template.c
index e0cf716874..d9ef480f39 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -144,6 +144,10 @@ static int
FUNC(sequence_display_extension)(CodedBitstreamContext *ctx, RWContex
uir(8, transfer_characteristics);
uir(8, matrix_coefficients);
#endif
+} else {
+infer(colour_primaries, 2);
+infer(transfer_characteristics, 2);
+infer(matrix_coefficients, 2);
}
ui(14, display_horizontal_size);
diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index 6779ffd4c4..3f371a028d 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -213,6 +213,18 @@ static int mpeg2_metadata_init(AVBSFContext *bsf)
CodedBitstreamFragment *frag = &ctx->fragment;
int err;
+#define VALIDITY_CHECK(name) do { \
+if (!ctx->name) { \
+av_log(bsf, AV_LOG_ERROR, "The value 0 for %s is " \
+ "forbidden.\n", #name); \
+return AVERROR(EINVAL); \
+} \
+} while (0)
+VALIDITY_CHECK(colour_primaries);
+VALIDITY_CHECK(transfer_characteristics);
+VALIDITY_CHECK(matrix_coefficients);
+#undef VALIDITY_CHECK
+
err = ff_cbs_init(&ctx->cbc, AV_CODEC_ID_MPEG2VIDEO, bsf);
if (err < 0)
return err;
--
2.21.0
___
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 19/31] vp9_metadata: Avoid allocations and copies of packet structures
This commit changes vp9_metadata to (a) use ff_bsf_get_packet_ref
instead of ff_bsf_get_packet (thereby avoiding one malloc and free per
filtered packet) and (b) to use only one packet structure at all,
thereby avoiding a call to av_packet_copy_props.
(b) has been made possible by the recent changes to ff_cbs_write_packet.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp9_metadata_bsf.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vp9_metadata_bsf.c b/libavcodec/vp9_metadata_bsf.c
index b79f08af6c..1bde1b96aa 100644
--- a/libavcodec/vp9_metadata_bsf.c
+++ b/libavcodec/vp9_metadata_bsf.c
@@ -37,18 +37,17 @@ typedef struct VP9MetadataContext {
} VP9MetadataContext;
-static int vp9_metadata_filter(AVBSFContext *bsf, AVPacket *out)
+static int vp9_metadata_filter(AVBSFContext *bsf, AVPacket *pkt)
{
VP9MetadataContext *ctx = bsf->priv_data;
-AVPacket *in = NULL;
CodedBitstreamFragment *frag = &ctx->fragment;
int err, i;
-err = ff_bsf_get_packet(bsf, &in);
+err = ff_bsf_get_packet_ref(bsf, pkt);
if (err < 0)
return err;
-err = ff_cbs_read_packet(ctx->cbc, frag, in);
+err = ff_cbs_read_packet(ctx->cbc, frag, pkt);
if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to read packet.\n");
goto fail;
@@ -74,23 +73,18 @@ static int vp9_metadata_filter(AVBSFContext *bsf, AVPacket
*out)
}
}
-err = ff_cbs_write_packet(ctx->cbc, out, frag);
+err = ff_cbs_write_packet(ctx->cbc, pkt, frag);
if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
goto fail;
}
-err = av_packet_copy_props(out, in);
-if (err < 0)
-goto fail;
-
err = 0;
fail:
ff_cbs_fragment_reset(ctx->cbc, frag);
if (err < 0)
-av_packet_unref(out);
-av_packet_free(&in);
+av_packet_unref(pkt);
return err;
}
--
2.21.0
___
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 22/31] cbs_mpeg2: Fix parsing of picture and slice headers
1. The extra information in slice headers was parsed incorrectly:
In the first reading pass to derive the length of the extra information,
one should look at bits n, n + 9, n + 18, ... and check whether they
equal one (further extra information) or zero (end of extra information),
but instead bits n, n + 8, n + 16, ... were inspected. The second pass
of reading (where the length is already known and the bytes between the
length-determining bits are copied into a buffer) did not record what
was in bits n, n + 9, n + 18, ..., presuming they equal one. And during
writing, the bytes in the buffer are interleaved with set bits and
written. This means that if the detected length of the extra information
was greater than the real length, the output was corrupted. Fortunately
no sample is known that made use of this mechanism: The extra information
in slices is still marked as reserved in the specifications. cbs_mpeg2
is now ready in case this changes.
2. Furthermore, the buffer is now padded and slightly different, but
very similar code for reading resp. writing has been replaced by code
used for both. This was made possible by a new macro, the equivalent
to cbs_h2645's fixed().
3. These changes also made it possible to remove the extra_bit_slice
element from the MPEG2RawSliceHeader structure. Said element was always
zero except when the detected length of the extra information was less
than the real length.
4. The extra information in picture headers (which uses essentially the
same syntax as the extra information in slice headers) has simply been
forgotten. This meant that if this extra information was present, it was
discarded during reading; and unfortunately writing created invalid
bitstreams in this case (an extra_bit_picture - the last set bit of the
whole unit - indicated that there would be a further byte of data,
although the output didn't contain said data).
This has been fixed; both types of extra information are now parsed via
the same code and essentially passed through.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_mpeg2.c | 43 ---
libavcodec/cbs_mpeg2.h | 14 ++---
libavcodec/cbs_mpeg2_syntax_template.c | 72 ++
3 files changed, 71 insertions(+), 58 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 2466f569f6..516b728a64 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -48,17 +48,26 @@
xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
#define uirs(width, name, subs, ...) \
xui(width, name, current->name, 1, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
+#define xui(width, name, var, range_min, range_max, subs, ...) \
+xuia(width, #name, var, range_min, range_max, subs, __VA_ARGS__)
#define sis(width, name, subs, ...) \
xsi(width, name, current->name, subs, __VA_ARGS__)
+#define marker_bit() \
+bit("marker_bit", 1)
+#define bit(string, value) do { \
+av_unused uint32_t bit = value; \
+xuia(1, string, bit, value, value, 0); \
+} while (0)
+
#define READ
#define READWRITE read
#define RWContext GetBitContext
-#define xui(width, name, var, range_min, range_max, subs, ...) do { \
+#define xuia(width, string, var, range_min, range_max, subs, ...) do { \
uint32_t value; \
-CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
+CHECK(ff_cbs_read_unsigned(ctx, rw, width, string, \
SUBSCRIPTS(subs, __VA_ARGS__), \
&value, range_min, range_max)); \
var = value; \
@@ -73,11 +82,6 @@
var = value; \
} while (0)
-#define marker_bit() do { \
-av_unused uint32_t one; \
-CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", NULL, &one, 1,
1)); \
-} while (0)
-
#define nextbits(width, compare, var) \
(get_bits_left(rw) >= width && \
(var = show_bits(rw, width)) == (compare))
@@ -91,9 +95,8 @@
#undef READ
#undef READWRITE
#undef RWContext
-#undef xui
+#undef xuia
#undef xsi
-#undef marker_bit
#undef nextbits
#undef infer
@@ -102,8 +105,8 @@
#define READWRITE write
#define RWContext PutBitContext
-#define xui(width, name, var, range_min, range_max, subs, ...) do { \
-CHECK(ff_cbs_write_unsigned(ctx, rw, width, #name, \
+#define xuia(width, string, var, range_min, range_max, subs, ...) do { \
+CHECK(ff_cbs_write_unsigned(ctx, rw, width, string, \
SUBSCRIPTS(subs, __VA_ARGS__), \
var, range_min, range_max)); \
} while (0)
@@ -115,10 +118,6 @@
MAX_INT_BITS(width))); \
} while (0)
-#define marker_bit() do { \
-CHECK(ff_cbs_write_unsigned(ctx, rw, 1, "marker_bit", NULL, 1, 1, 1));
\
-} while (0)
-
#define nextbits(width, compare, var) (var)
#define infer(name, value) do { \
@@ -135,13
[FFmpeg-devel] [PATCH 23/31] cbs_mpeg2: Remove zero byte stuffing
Remove superfluous trailing zeros from slices. Because MPEG-2 slices
can end with zero bits a safe number of trailing zero bits is always
kept.
More explicitly, 6 + max{f_code[i][1] - 1, i = 0,1, f_code[i][1] != 0xf}
is an upper bound for the number of possible trailing zeros that are
part of the slice. Here f_code[i][1] is the relevant value of the
picture coding extension the slice belongs to and the maximum of the
empty set is zero.
It is this number of trailing zero bits that is actually kept.
That this is really an upper bound can be seen as follows:
a) Every slice actually ends with a macroblock.
b) If the last macroblock of a slice ends with a block(i) structure
with pattern_code[i] != 0, then the slice ends with an "End of block"
VLC code (namely the "End of block" code of the last block with
pattern_code[i] != 0).
These codes are 10 and 0110, so that in this case there is exactly one
trailing zero bit.
c) Otherwise, all pattern_code[i] are zero. In this case,
if macroblock_pattern is set for the last macroblock of the slice, then
by the definition of pattern_code[i] in 6.3.17.4 cbp (derived
according to table B.9) must be zero and also the
coded_block_pattern_1/2 (if existing) must consist of zeros alone. The
value zero for cbp is coded by 1 so that the maximum number of
trailing zeros in this case is the length of coded_block_pattern_1/2 which
have a length of two resp. six bits. So six trailing zero bits at most.
d) Otherwise, if the slice actually ends with the marker bit of the
last macroblock, then there are certainly no trailing zero bits at
all.
e) Otherwise, if the slice ends with a motion_vectors(s) structure
(with s = 0 or 1 -- it doesn't matter which one), then it ends with a
motion_vector(r,s) (r, s = 0, 1 -- it doesn't matter) structure. This
structure ends with motion_code[r][s][1] (always existing) potentially
followed by motion_residual[r][s][1] and dmvector[1]. If dmvector[1]
exists, and contains a bit different from 0, there is at most one
trailing zero bit; if dmvector[1] consists of zeros alone, its length
is one according to B.11. motion_residual[r][s][1] (if it exists) has
a length of f_code[s][1] - 1 bits and can consist of zero bits alone.
Given that the value 0xf for f_code indicates that there is no motion
vector of the mentioned type, the length of motion_residual[r][s][1] is
bounded by max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf}. The
motion_code[r][s][1] can end with at most five zero bits (see B.10)
and always contains a bit set to one, so that in this case there are
at most 5 + max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf} + 1
zero trailing bits.
f) Otherwise, if the last macroblock of the slice ends with a
quantiser_scale_code, then there are at most four trailing zero bits,
because quantiser_scale_code has a length of five bits and must not
attain the value zero.
g) Otherwise, the last macroblock ends with the macroblock_modes
syntax structure. The potentially existing dct_type at the end might
be a zero bit; the frame/field_motion_type isn't present here, because
otherwise we would have a motion_vectors(i) (i = 0 or 1 or both) syntax
structure, so that e) (or b)-d)) would have applied.
spatial_temporal_weight_code might entirely consist of two zero bits.
The macroblock_type VLC code always contains a 1 bit and ends with two
zero bits at most (see B.2-B.8 for this), so we have maximally 2+2+1
trailing zero bits.
The fate test cbs-mpeg2-sony-ct3 had to be adapted because the input
file contains trailing zeros that were stripped away; the filesize is
reduced from 135 KB to 117 KB. Of course, decoding the smaller output
still produces the same frames.
Most of these savings happen in between slices rather than after the
last slice: The chomp bitstream filter can only reduce the filesize
by 50 bytes.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_mpeg2.c| 26 --
tests/ref/fate/cbs-mpeg2-sony-ct3 | 2 +-
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 516b728a64..0630fe17d8 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -170,7 +170,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
uint8_t *unit_data;
uint32_t start_code = -1, next_start_code = -1;
size_t unit_size;
-int err, i, unit_type;
+int err, i, unit_type, max_trailing_bits = 14;
start = avpriv_find_start_code(frag->data, frag->data + frag->data_size,
&start_code);
@@ -187,10 +187,32 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
unit_size = end - (start - 1);
} else {
// Unit runs from start to the beginning of the start code
-// pointed to by end (including any padding zeroes).
+// pointed to by end (preliminarily including any padding zeroes).
unit_size = (end - 4) - (start
[FFmpeg-devel] [PATCH 21/31] cbs: Remove useless initializations
Up until now, a temporary variable was used and initialized every time a
value was read in CBS; if reading turned out to be successfull, this
value was overwritten (without having ever been looked at) with the
value read if reading was successfull; on failure the variable wasn't
touched either. Therefore these initializations can be and have been
removed.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_av1.c | 14 +++---
libavcodec/cbs_h2645.c | 8
libavcodec/cbs_jpeg.c | 2 +-
libavcodec/cbs_mpeg2.c | 2 +-
libavcodec/cbs_vp9.c | 8
5 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index eb6b801790..288ef8e14b 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -574,7 +574,7 @@ static size_t cbs_av1_get_payload_bytes_left(GetBitContext
*gbc)
#define RWContext GetBitContext
#define xf(width, name, var, range_min, range_max, subs, ...) do { \
-uint32_t value = range_min; \
+uint32_t value; \
CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
&value, range_min, range_max)); \
@@ -582,7 +582,7 @@ static size_t cbs_av1_get_payload_bytes_left(GetBitContext
*gbc)
} while (0)
#define xsu(width, name, var, subs, ...) do { \
-int32_t value = 0; \
+int32_t value; \
CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), &value, \
MIN_INT_BITS(width), \
@@ -591,27 +591,27 @@ static size_t
cbs_av1_get_payload_bytes_left(GetBitContext *gbc)
} while (0)
#define uvlc(name, range_min, range_max) do { \
-uint32_t value = range_min; \
+uint32_t value; \
CHECK(cbs_av1_read_uvlc(ctx, rw, #name, \
&value, range_min, range_max)); \
current->name = value; \
} while (0)
#define ns(max_value, name, subs, ...) do { \
-uint32_t value = 0; \
+uint32_t value; \
CHECK(cbs_av1_read_ns(ctx, rw, max_value, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), &value)); \
current->name = value; \
} while (0)
#define increment(name, min, max) do { \
-uint32_t value = 0; \
+uint32_t value; \
CHECK(cbs_av1_read_increment(ctx, rw, min, max, #name, &value)); \
current->name = value; \
} while (0)
#define subexp(name, max, subs, ...) do { \
-uint32_t value = 0; \
+uint32_t value; \
CHECK(cbs_av1_read_subexp(ctx, rw, max, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), &value)); \
current->name = value; \
@@ -629,7 +629,7 @@ static size_t cbs_av1_get_payload_bytes_left(GetBitContext
*gbc)
} while (0)
#define leb128(name) do { \
-uint64_t value = 0; \
+uint64_t value; \
CHECK(cbs_av1_read_leb128(ctx, rw, #name, &value)); \
current->name = value; \
} while (0)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 117e13e0c7..125f9146c6 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -290,28 +290,28 @@ static int cbs_write_se_golomb(CodedBitstreamContext
*ctx, PutBitContext *pbc,
#define RWContext GetBitContext
#define xu(width, name, var, range_min, range_max, subs, ...) do { \
-uint32_t value = range_min; \
+uint32_t value; \
CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
&value, range_min, range_max)); \
var = value; \
} while (0)
#define xue(name, var, range_min, range_max, subs, ...) do { \
-uint32_t value = range_min; \
+uint32_t value; \
CHECK(cbs_read_ue_golomb(ctx, rw, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
&value, range_min, range_max)); \
var = value; \
} while (0)
#define xi(width, name, var, range_min, range_max, subs, ...) do { \
-int32_t value = range_min; \
+int32_t value; \
CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
&value, range_min, range_max)); \
var = value; \
} while (0)
#define xse(name, var, range_min, range_max, subs, ...) do { \
-int32_t value = range_min; \
+int32_t value; \
CHECK(cbs_read_se_golomb(ctx, rw, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
&value, range_min, range_max)); \
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index 83857bbba2..c46abd0a45 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -
[FFmpeg-devel] [PATCH 26/31] av1_metadata: Add option to update codec parameters
Up until now, this BSF only changed the bitstream and the extradata,
not the rest of the AVCodecParameters. The result is that e.g. some
muxers use outdated information to write header information that
conflicts with (and potentially precedes) the new information at the
bitstream level, so that using the bitstream filter might not have the
desired effect.
This commit changes this. It adds a mechanism by which the new
information can be used to update the AVCodecParameters, too. This is
the new default and an option has been added to revert to the old
behaviour.
Signed-off-by: Andreas Rheinhardt
---
doc/bitstream_filters.texi| 6 ++
libavcodec/av1_metadata_bsf.c | 39 +++
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 40e8adad0f..f625c8f768 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -90,6 +90,12 @@ has a fixed framerate. Ignored if @option{tick_rate} is not
also set.
@item delete_padding
Deletes Padding OBUs.
+@item full_update
+If this is set, an effort is made to update the AVCodecParameters in addition
+to the bitstream. If unset, muxers might add header information based upon
+the old AVCodecParameters that contradicts and potentially precedes the
+changes made at the bitstream level. On by default.
+
@end table
@section chomp
diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
index 7d9d15b1a0..fce1a194b7 100644
--- a/libavcodec/av1_metadata_bsf.c
+++ b/libavcodec/av1_metadata_bsf.c
@@ -48,11 +48,15 @@ typedef struct AV1MetadataContext {
int num_ticks_per_picture;
int delete_padding;
+
+int full_update;
} AV1MetadataContext;
static int av1_metadata_update_sequence_header(AVBSFContext *bsf,
- AV1RawSequenceHeader *seq)
+ AV1RawSequenceHeader *seq,
+ int *color_range,
+ int *chroma_sample_position)
{
AV1MetadataContext *ctx = bsf->priv_data;
AV1RawColorConfig *clc = &seq->color_config;
@@ -79,6 +83,8 @@ static int av1_metadata_update_sequence_header(AVBSFContext
*bsf,
"on RGB streams encoded in BT.709 sRGB.\n");
} else {
clc->color_range = ctx->color_range;
+if (color_range)
+*color_range = ctx->color_range + 1;
}
}
@@ -88,6 +94,8 @@ static int av1_metadata_update_sequence_header(AVBSFContext
*bsf,
"can only be set for 4:2:0 streams.\n");
} else {
clc->chroma_sample_position = ctx->chroma_sample_position;
+if (chroma_sample_position)
+*chroma_sample_position = ctx->chroma_sample_position;
}
}
@@ -137,7 +145,8 @@ static int av1_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
for (i = 0; i < frag->nb_units; i++) {
if (frag->units[i].type == AV1_OBU_SEQUENCE_HEADER) {
obu = frag->units[i].content;
-err = av1_metadata_update_sequence_header(bsf,
&obu->obu.sequence_header);
+err = av1_metadata_update_sequence_header(bsf,
&obu->obu.sequence_header,
+ NULL, NULL);
if (err < 0)
goto fail;
}
@@ -191,7 +200,7 @@ static int av1_metadata_init(AVBSFContext *bsf)
AV1MetadataContext *ctx = bsf->priv_data;
CodedBitstreamFragment *frag = &ctx->access_unit;
AV1RawOBU *obu;
-int err, i;
+int err, i, color_range = -1, chroma_sample_position = -1;
err = ff_cbs_init(&ctx->cbc, AV_CODEC_ID_AV1, bsf);
if (err < 0)
@@ -207,7 +216,8 @@ static int av1_metadata_init(AVBSFContext *bsf)
for (i = 0; i < frag->nb_units; i++) {
if (frag->units[i].type == AV1_OBU_SEQUENCE_HEADER) {
obu = frag->units[i].content;
-err = av1_metadata_update_sequence_header(bsf,
&obu->obu.sequence_header);
+err = av1_metadata_update_sequence_header(bsf,
&obu->obu.sequence_header,
+ &color_range,
&chroma_sample_position);
if (err < 0)
goto fail;
}
@@ -220,6 +230,24 @@ static int av1_metadata_init(AVBSFContext *bsf)
}
}
+if (ctx->full_update) {
+if (chroma_sample_position >= 0) {
+static const uint8_t conversion_table[4] = {
+AVCHROMA_LOC_UNSPECIFIED,
+AVCHROMA_LOC_LEFT,
+AVCHROMA_LOC_TOPLEFT,
+AVCHROMA_LOC_UNSPECIFIED
+};
+chroma_sample_position = conversion_table[chroma_sample_position];
+}
+
+ff_cbs_update_video_parameters(ctx->cbc, bsf->par_out, -1, -1, -1, -1,
+
[FFmpeg-devel] [PATCH 27/31] mpeg2_metadata: Additionally update AVCodecParameters
Otherwise the muxer could add header data that is based on the old
AVCodecParameters that contradicts and potentially nullifies the
modifications made to the bitstream.
An option to revert to the old behaviour is included.
The documentation has been updated to reflect the change.
Signed-off-by: Andreas Rheinhardt
---
doc/bitstream_filters.texi | 6 ++
libavcodec/mpeg2_metadata_bsf.c | 11 +++
2 files changed, 17 insertions(+)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index f625c8f768..e5ce7bc0a3 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -490,6 +490,12 @@ table 6-6).
Set the colour description in the stream (see H.262 section 6.3.6
and tables 6-7, 6-8 and 6-9).
+@item full_update
+If this is set, an effort is made to update the AVCodecParameters in addition
+to the bitstream. If unset, muxers might add header information based upon
+the old AVCodecParameters that contradicts and potentially precedes
+the changes made at the bitstream level. On by default.
+
@end table
@section mpeg4_unpack_bframes
diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index 3f371a028d..8396922979 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -43,6 +43,8 @@ typedef struct MPEG2MetadataContext {
int matrix_coefficients;
int mpeg1_warned;
+
+int full_update;
} MPEG2MetadataContext;
@@ -249,6 +251,12 @@ static int mpeg2_metadata_init(AVBSFContext *bsf)
}
}
+if (ctx->full_update)
+ff_cbs_update_video_parameters(ctx->cbc, bsf->par_out, -1, -1, -1,
+ -1, -1, -1, ctx->colour_primaries,
+ ctx->transfer_characteristics,
+ ctx->matrix_coefficients, -1, -1);
+
err = 0;
fail:
ff_cbs_fragment_reset(ctx->cbc, frag);
@@ -287,6 +295,9 @@ static const AVOption mpeg2_metadata_options[] = {
OFFSET(matrix_coefficients), AV_OPT_TYPE_INT,
{ .i64 = -1 }, -1, 255, FLAGS },
+{ "full_update", "Update not only bitstream, but also AVCodecParameters",
+OFFSET(full_update), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, FLAGS},
+
{ NULL }
};
--
2.21.0
___
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 25/31] cbs: Add function to update video codec parameters
If any of the *_metadata filter based upon cbs currently updates a video
codec parameter like color information, the AVCodecParameters are not
updated accordingly, so that e.g. muxers write header values based upon
outdated information that may precede and thereby nullify the new values
on the bitstream level.
This commit adds a function to also update the video codec parameters
so that the above situation can be fixed in a unified manner.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs.c | 35 +++
libavcodec/cbs.h | 15 +++
2 files changed, 50 insertions(+)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 47679eca1b..37b080b5ba 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -342,6 +342,41 @@ int ff_cbs_write_extradata(CodedBitstreamContext *ctx,
return 0;
}
+void ff_cbs_update_video_parameters(CodedBitstreamContext *ctx,
+AVCodecParameters *par, int profile,
+int level, int width, int height,
+int field_order, int color_range,
+int color_primaries, int color_trc,
+int color_space, int chroma_location,
+int video_delay)
+{
+#define SET_IF_NONNEGATIVE(elem) \
+if (elem >= 0) \
+par->elem = elem;
+SET_IF_NONNEGATIVE(profile)
+SET_IF_NONNEGATIVE(level)
+SET_IF_NONNEGATIVE(width)
+SET_IF_NONNEGATIVE(height)
+SET_IF_NONNEGATIVE(field_order)
+SET_IF_NONNEGATIVE(video_delay)
+#undef SET_IF_NONNEGATIVE
+
+#define SET_IF_VALID(elem, upper_bound) \
+if (0 <= elem && elem < upper_bound) \
+par->elem = elem;
+SET_IF_VALID(color_range, AVCOL_RANGE_NB)
+SET_IF_VALID(color_trc, AVCOL_TRC_NB)
+SET_IF_VALID(color_space, AVCOL_SPC_NB)
+SET_IF_VALID(chroma_location, AVCHROMA_LOC_NB)
+#undef SET_IF_VALID
+
+if (0 <= color_primaries && color_primaries <= AVCOL_PRI_SMPTE432
+ || color_primaries == AVCOL_PRI_JEDEC_P22)
+par->color_primaries = color_primaries;
+
+return;
+}
+
int ff_cbs_write_packet(CodedBitstreamContext *ctx,
AVPacket *pkt,
CodedBitstreamFragment *frag)
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index e1e6055ceb..1655f790cd 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -304,6 +304,21 @@ int ff_cbs_write_extradata(CodedBitstreamContext *ctx,
AVCodecParameters *par,
CodedBitstreamFragment *frag);
+/**
+ * Update the parameters of an AVCodecParameters structure
+ *
+ * If a parameter is negative, the corresponding member is not
+ * modified. For the color/chroma parameters, only values that
+ * are part of the relevant enumeration are written.
+ */
+void ff_cbs_update_video_parameters(CodedBitstreamContext *ctx,
+AVCodecParameters *par, int profile,
+int level, int width, int height,
+int field_order, int color_range,
+int color_primaries, int color_trc,
+int color_space, int chroma_location,
+int video_delay);
+
/**
* Write the bitstream of a fragment to a packet.
*
--
2.21.0
___
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 24/31] av1/h264_metadata: Don't reinitialize data
If the relevant elements (the color description elements for AV1 and the
VUI elements in general for H.264 (since 1156b507)) are absent, then their
correct values (usually meaning unknown) have already been inferred by
the reading process, so that it is unnecessary to initialize them again
in the av1/h264_metadata filters even when they were initially absent.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/av1_metadata_bsf.c | 7 +--
libavcodec/h264_metadata_bsf.c | 37 ++
2 files changed, 12 insertions(+), 32 deletions(-)
diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
index 9345095277..7d9d15b1a0 100644
--- a/libavcodec/av1_metadata_bsf.c
+++ b/libavcodec/av1_metadata_bsf.c
@@ -61,12 +61,7 @@ static int av1_metadata_update_sequence_header(AVBSFContext
*bsf,
if (ctx->color_primaries >= 0 ||
ctx->transfer_characteristics >= 0 ||
ctx->matrix_coefficients >= 0) {
-if (!clc->color_description_present_flag) {
-clc->color_description_present_flag = 1;
-clc->color_primaries = AVCOL_PRI_UNSPECIFIED;
-clc->transfer_characteristics = AVCOL_TRC_UNSPECIFIED;
-clc->matrix_coefficients = AVCOL_SPC_UNSPECIFIED;
-}
+clc->color_description_present_flag = 1;
if (ctx->color_primaries >= 0)
clc->color_primaries = ctx->color_primaries;
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index d760ee3182..40886bdde0 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -122,13 +122,12 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
need_vui = 1;
}
-#define SET_OR_INFER(field, value, present_flag, infer) do { \
-if (value >= 0) { \
-field = value; \
+#define SET_IF_SET(field) do { \
+if (ctx->field >= 0) { \
+sps->vui.field = ctx->field; \
need_vui = 1; \
-} else if (!present_flag) \
-field = infer; \
-} while (0)
+} \
+} while (0)
if (ctx->video_format >= 0 ||
ctx->video_full_range_flag>= 0 ||
@@ -136,33 +135,21 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
ctx->transfer_characteristics >= 0 ||
ctx->matrix_coefficients >= 0) {
-SET_OR_INFER(sps->vui.video_format, ctx->video_format,
- sps->vui.video_signal_type_present_flag, 5);
+SET_IF_SET(video_format);
-SET_OR_INFER(sps->vui.video_full_range_flag,
- ctx->video_full_range_flag,
- sps->vui.video_signal_type_present_flag, 0);
+SET_IF_SET(video_full_range_flag);
if (ctx->colour_primaries >= 0 ||
ctx->transfer_characteristics >= 0 ||
ctx->matrix_coefficients >= 0) {
-SET_OR_INFER(sps->vui.colour_primaries,
- ctx->colour_primaries,
- sps->vui.colour_description_present_flag, 2);
-
-SET_OR_INFER(sps->vui.transfer_characteristics,
- ctx->transfer_characteristics,
- sps->vui.colour_description_present_flag, 2);
-
-SET_OR_INFER(sps->vui.matrix_coefficients,
- ctx->matrix_coefficients,
- sps->vui.colour_description_present_flag, 2);
+SET_IF_SET(colour_primaries);
+SET_IF_SET(transfer_characteristics);
+SET_IF_SET(matrix_coefficients);
sps->vui.colour_description_present_flag = 1;
}
sps->vui.video_signal_type_present_flag = 1;
-need_vui = 1;
}
if (ctx->chroma_sample_loc_type >= 0) {
@@ -186,9 +173,7 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
sps->vui.timing_info_present_flag = 1;
need_vui = 1;
}
-SET_OR_INFER(sps->vui.fixed_frame_rate_flag,
- ctx->fixed_frame_rate_flag,
- sps->vui.timing_info_present_flag, 0);
+SET_IF_SET(fixed_frame_rate_flag);
if (sps->separate_colour_plane_flag || sps->chroma_format_idc == 0) {
crop_unit_x = 1;
--
2.21.0
___
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 30/31] h264_metadata: Update AVCodecParameters
This commit adds an option to also update the AVCodecParameters to align
them with the changes at the bitstream level. It is on by default.
Given the importance of correct frame dimensions they are updated
even when the new option is disabled.
The commit also adds documentation for the new option.
Signed-off-by: Andreas Rheinhardt
---
doc/bitstream_filters.texi | 8 ++
libavcodec/h264_metadata_bsf.c | 48 ++
2 files changed, 51 insertions(+), 5 deletions(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 80be525e0f..8030be233c 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -285,6 +285,14 @@ level_idc value (for example, @samp{42}), or the special
name @samp{auto}
indicating that the filter should attempt to guess the level from the
input stream properties.
+@item full_update
+If this is set, an effort is made to update the AVCodecParameters in addition
+to the bitstream. If unset, muxers might add header information based upon
+the old AVCodecParameters that contradicts and potentially precedes
+the changes made at the bitstream level. On by default.
+
+The frame dimensions are always updated and not affected by this option.
+
@end table
@section h264_mp4toannexb
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 40886bdde0..0a993c9d99 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -82,11 +82,13 @@ typedef struct H264MetadataContext {
int flip;
int level;
+
+int full_update;
} H264MetadataContext;
-static int h264_metadata_update_sps(AVBSFContext *bsf,
-H264RawSPS *sps)
+static int h264_metadata_update_sps(AVBSFContext *bsf, H264RawSPS *sps,
+int *width, int *height, int *level)
{
H264MetadataContext *ctx = bsf->priv_data;
int need_vui = 0;
@@ -201,6 +203,14 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
CROP(bottom, crop_unit_y);
#undef CROP
+if (width && height) {
+*width = 16 * (sps->pic_width_in_mbs_minus1 + 1) - crop_unit_x *
+ (sps->frame_crop_left_offset + sps->frame_crop_right_offset);
+*height = 16 * (sps->pic_height_in_map_units_minus1 + 1)
+ * (2 - sps->frame_mbs_only_flag) - crop_unit_y *
+ (sps->frame_crop_top_offset + sps->frame_crop_bottom_offset);
+}
+
if (ctx->level != LEVEL_UNSET) {
int level_idc;
@@ -260,6 +270,9 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
} else {
sps->level_idc = level_idc;
}
+
+if (level)
+*level = sps->level_idc;
}
if (need_vui)
@@ -349,7 +362,8 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
has_sps = 0;
for (i = 0; i < au->nb_units; i++) {
if (au->units[i].type == H264_NAL_SPS) {
-err = h264_metadata_update_sps(bsf, au->units[i].content);
+err = h264_metadata_update_sps(bsf, au->units[i].content,
+ NULL, NULL, NULL);
if (err < 0)
goto fail;
has_sps = 1;
@@ -575,7 +589,7 @@ static int h264_metadata_init(AVBSFContext *bsf)
{
H264MetadataContext *ctx = bsf->priv_data;
CodedBitstreamFragment *au = &ctx->access_unit;
-int err, i;
+int err, i, width = -1, height = -1, level = -1;
err = ff_cbs_init(&ctx->cbc, AV_CODEC_ID_H264, bsf);
if (err < 0)
@@ -590,7 +604,8 @@ static int h264_metadata_init(AVBSFContext *bsf)
for (i = 0; i < au->nb_units; i++) {
if (au->units[i].type == H264_NAL_SPS) {
-err = h264_metadata_update_sps(bsf, au->units[i].content);
+err = h264_metadata_update_sps(bsf, au->units[i].content,
+ &width, &height, &level);
if (err < 0)
goto fail;
}
@@ -603,6 +618,26 @@ static int h264_metadata_init(AVBSFContext *bsf)
}
}
+if (ctx->full_update) {
+int color_range = ctx->video_full_range_flag;
+int chroma_location = ctx->chroma_sample_loc_type;
+
+if (color_range >= 0)
+color_range++;
+if (chroma_location >= 0)
+chroma_location++;
+
+ff_cbs_update_video_parameters(ctx->cbc, bsf->par_out, -1, level,
+ width, height, -1, color_range,
+ ctx->colour_primaries,
+ ctx->transfer_characteristics,
+ ctx->matrix_coefficients,
+ chroma_location, -1);
+} else
+ff_cbs_update_video_parameters(ctx->cbc, bsf->par_out, -1,
+ -1, width, height, -1, -1,
+
[FFmpeg-devel] [PATCH 29/31] vp9_metadata: Update AVCodecParameters
This commit adds an option to not only update the bitstream parameters
when using the vp9_metadata bitstream filter, but also the relevant
AVCodecParameters. The new option is on by default.
This commit also adds documentation for this value.
Signed-off-by: Andreas Rheinhardt
---
doc/bitstream_filters.texi| 7 +++
libavcodec/vp9_metadata_bsf.c | 24
2 files changed, 31 insertions(+)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index c9dff7ae03..80be525e0f 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -680,6 +680,13 @@ imposed by the color space will take precedence over this
value.
@item tv
@item pc
@end table
+
+@item full_update
+If this is set, an effort is made to update the AVCodecParameters in addition
+to the bitstream. If unset, muxers might add header information based upon
+the old AVCodecParameters that contradicts and potentially precedes
+the changes made at the bitstream level. On by default.
+
@end table
@section vp9_superframe
diff --git a/libavcodec/vp9_metadata_bsf.c b/libavcodec/vp9_metadata_bsf.c
index 52e962b1c0..338d6d2af3 100644
--- a/libavcodec/vp9_metadata_bsf.c
+++ b/libavcodec/vp9_metadata_bsf.c
@@ -34,6 +34,8 @@ typedef struct VP9MetadataContext {
int color_range;
int color_warnings;
+
+int full_update;
} VP9MetadataContext;
@@ -109,6 +111,25 @@ static int vp9_metadata_init(AVBSFContext *bsf)
{
VP9MetadataContext *ctx = bsf->priv_data;
+if (ctx->full_update) {
+AVCodecParameters *par = bsf->par_out;
+static const uint8_t conversion_table[8] = {
+AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG,
+AVCOL_SPC_BT709, AVCOL_SPC_SMPTE170M,
+AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL,
+AVCOL_SPC_RESERVED,AVCOL_SPC_RGB
+};
+
+if (ctx->color_space >= 0 && (par->profile & 1 ||
+ ctx->color_space != VP9_CS_RGB))
+par->color_space = conversion_table[ctx->color_space];
+
+if (par->color_space == AVCOL_SPC_RGB)
+par->color_range = AVCOL_RANGE_JPEG;
+else if (ctx->color_range >= 0)
+par->color_range = ctx->color_range + 1;
+}
+
return ff_cbs_init(&ctx->cbc, AV_CODEC_ID_VP9, bsf);
}
@@ -149,6 +170,9 @@ static const AVOption vp9_metadata_options[] = {
{ "pc", "PC (full) range",0, AV_OPT_TYPE_CONST,
{ .i64 = 1 }, .flags = FLAGS, .unit = "cr" },
+{ "full_update", "Update not only bitstream, but also AVCodecParameters",
+OFFSET(full_update), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, FLAGS},
+
{ NULL }
};
--
2.21.0
___
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 31/31] hevc_metadata: Update AVCodecParameters
This commit adds an option to also update the AVCodecParameters to align
them with the changes at the bitstream level. It is on by default.
Given the importance of correct frame dimensions they are updated
even when the new option is disabled. Notice that for field-based HEVC
the derived height is the height of a frame, which deviates from current
FFmpeg behaviour.
This commit also adds documentation for the new value.
Signed-off-by: Andreas Rheinhardt
---
doc/bitstream_filters.texi | 8 +++
libavcodec/h265_metadata_bsf.c | 44 ++
2 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 8030be233c..cc50a4e9fe 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -375,6 +375,14 @@ will replace the current ones if the stream is already
cropped.
These fields are set in pixels. Note that some sizes may not be
representable if the chroma is subsampled (H.265 section 7.4.3.2.1).
+@item full_update
+If this is set, an effort is made to update the AVCodecParameters in addition
+to the bitstream. If unset, muxers might add header information based upon
+the old AVCodecParameters that contradicts and potentially precedes the
+changes made at the bitstream level. On by default.
+
+The frame dimensions are always updated and not affected by this option.
+
@end table
@section hevc_mp4toannexb
diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
index 2f28342a26..71bad9b64a 100644
--- a/libavcodec/h265_metadata_bsf.c
+++ b/libavcodec/h265_metadata_bsf.c
@@ -58,6 +58,8 @@ typedef struct H265MetadataContext {
int crop_right;
int crop_top;
int crop_bottom;
+
+int full_update;
} H265MetadataContext;
@@ -89,8 +91,8 @@ static int h265_metadata_update_vps(AVBSFContext *bsf,
return 0;
}
-static int h265_metadata_update_sps(AVBSFContext *bsf,
-H265RawSPS *sps)
+static int h265_metadata_update_sps(AVBSFContext *bsf, H265RawSPS *sps,
+int *width, int *height)
{
H265MetadataContext *ctx = bsf->priv_data;
int need_vui = 0;
@@ -224,6 +226,13 @@ static int h265_metadata_update_sps(AVBSFContext *bsf,
CROP(bottom, crop_unit_y);
#undef CROP
+if (width && height) {
+*width = sps->pic_width_in_luma_samples - crop_unit_x *
+ (sps->conf_win_left_offset + sps->conf_win_right_offset);
+*height = (1 + sps->vui.field_seq_flag) *
(sps->pic_height_in_luma_samples
+- crop_unit_y * (sps->conf_win_top_offset +
sps->conf_win_bottom_offset));
+}
+
if (need_vui)
sps->vui_parameters_present_flag = 1;
@@ -305,7 +314,8 @@ static int h265_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
goto fail;
}
if (au->units[i].type == HEVC_NAL_SPS) {
-err = h265_metadata_update_sps(bsf, au->units[i].content);
+err = h265_metadata_update_sps(bsf, au->units[i].content,
+ NULL, NULL);
if (err < 0)
goto fail;
}
@@ -331,7 +341,7 @@ static int h265_metadata_init(AVBSFContext *bsf)
{
H265MetadataContext *ctx = bsf->priv_data;
CodedBitstreamFragment *au = &ctx->access_unit;
-int err, i;
+int err, i, width = -1, height = -1;
err = ff_cbs_init(&ctx->cbc, AV_CODEC_ID_HEVC, bsf);
if (err < 0)
@@ -351,7 +361,8 @@ static int h265_metadata_init(AVBSFContext *bsf)
goto fail;
}
if (au->units[i].type == HEVC_NAL_SPS) {
-err = h265_metadata_update_sps(bsf, au->units[i].content);
+err = h265_metadata_update_sps(bsf, au->units[i].content,
+ &width, &height);
if (err < 0)
goto fail;
}
@@ -364,6 +375,26 @@ static int h265_metadata_init(AVBSFContext *bsf)
}
}
+if (ctx->full_update) {
+int color_range = ctx->video_full_range_flag;
+int chroma_location = ctx->chroma_sample_loc_type;
+
+if (color_range >= 0)
+color_range++;
+if (chroma_location >= 0)
+chroma_location++;
+
+ff_cbs_update_video_parameters(ctx->cbc, bsf->par_out, -1, -1,
+ width, height, -1, color_range,
+ ctx->colour_primaries,
+ ctx->transfer_characteristics,
+ ctx->matrix_coefficients,
+ chroma_location, -1);
+} else
+ff_cbs_update_video_parameters(ctx->cbc, bsf->par_out, -1,
+ -1, width, height, -1, -1,
+ -1, -1, -1, -1, -1);
+
err = 0;
fail:
ff_cbs_f
[FFmpeg-devel] [PATCH 28/31] vp9_metadata: Improve spec-compliance and warnings
The earlier version had three deficits:
1. It allowed to set the stream to RGB although this is not allowed when
the profile is 0 or 2.
2. If it set the stream to RGB, then it did not automatically set the
range to full range; the result was that one got a warning every time a
frame with color_config element was processed if the frame originally
had TV range and the user didn't explicitly choose PC range. Now one
gets only one warning in such a situation.
3. Intra-only frames in profile 0 are automatically BT.601, but if the
user wished another color space, he was not informed about his wishes
being unfulfillable.
The commit also improves the documentation about this.
Signed-off-by: Andreas Rheinhardt
---
doc/bitstream_filters.texi| 8 ---
libavcodec/vp9_metadata_bsf.c | 40 ---
2 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index e5ce7bc0a3..c9dff7ae03 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -660,7 +660,9 @@ Modify metadata embedded in a VP9 stream.
@table @option
@item color_space
-Set the color space value in the frame header.
+Set the color space value in the frame header. Note that any frame
+set to RGB will be implicitly set to PC range and that RGB is
+incompatible with profiles 0 and 2.
@table @samp
@item unknown
@item bt601
@@ -672,8 +674,8 @@ Set the color space value in the frame header.
@end table
@item color_range
-Set the color range value in the frame header. Note that this cannot
-be set in RGB streams.
+Set the color range value in the frame header. Note that any value
+imposed by the color space will take precedence over this value.
@table @samp
@item tv
@item pc
diff --git a/libavcodec/vp9_metadata_bsf.c b/libavcodec/vp9_metadata_bsf.c
index 1bde1b96aa..52e962b1c0 100644
--- a/libavcodec/vp9_metadata_bsf.c
+++ b/libavcodec/vp9_metadata_bsf.c
@@ -33,7 +33,7 @@ typedef struct VP9MetadataContext {
int color_space;
int color_range;
-int color_range_rgb_warned;
+int color_warnings;
} VP9MetadataContext;
@@ -56,20 +56,36 @@ static int vp9_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
for (i = 0; i < frag->nb_units; i++) {
VP9RawFrame *frame = frag->units[i].content;
VP9RawFrameHeader *header = &frame->header;
+int profile = (header->profile_high_bit << 1) +
header->profile_low_bit;
+
+if (header->frame_type == VP9_KEY_FRAME ||
+header->intra_only && profile > 0) {
+if (ctx->color_space >= 0) {
+if (!(profile & 1) && ctx->color_space == VP9_CS_RGB) {
+if (!(ctx->color_warnings & 2)) {
+av_log(bsf, AV_LOG_WARNING, "Warning: RGB "
+ "incompatible with profiles 0 and 2.\n");
+ctx->color_warnings |= 2;
+}
+} else
+header->color_space = ctx->color_space;
+}
-if (ctx->color_space >= 0) {
-header->color_space = ctx->color_space;
-}
-if (ctx->color_range >= 0) {
-if (ctx->color_range == 0 &&
-header->color_space == VP9_CS_RGB &&
-!ctx->color_range_rgb_warned) {
-av_log(bsf, AV_LOG_WARNING, "Warning: color_range cannot "
- "be set to limited in RGB streams.\n");
-ctx->color_range_rgb_warned = 1;
-} else {
+if (ctx->color_range >= 0)
header->color_range = ctx->color_range;
+if (header->color_space == VP9_CS_RGB) {
+if (!(ctx->color_warnings & 1) && !header->color_range) {
+av_log(bsf, AV_LOG_WARNING, "Warning: Color space RGB "
+ "implicitly sets color range to PC range.\n");
+ctx->color_warnings |= 1;
+}
+header->color_range = 1;
}
+} else if (!(ctx->color_warnings & 4) && header->intra_only &&
!profile &&
+ ctx->color_space >= 0 && ctx->color_space != VP9_CS_BT_601)
{
+av_log(bsf, AV_LOG_WARNING, "Warning: Intra-only frames in "
+ "profile 0 are automatically BT.601.\n");
+ctx->color_warnings |= 4;
}
}
--
2.21.0
___
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] libavformat/flvenc: Use avpriv_mpeg4audio_sample_rates
Up until now flvenc.c included aacenctab.h which included
mpeg4audio_sample_rates (a clone of avpriv_mpeg4audio_sample_rates) as
static const array. But given that avpriv_mpeg4audio_sample_rates is
avpriv, it can be used instead.
Signed-off-by: Andreas Rheinhardt
---
libavformat/flvenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index e4863f1fc7..01873e5c5a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -33,7 +33,7 @@
#include "metadata.h"
#include "libavutil/opt.h"
#include "libavcodec/put_bits.h"
-#include "libavcodec/aacenctab.h"
+#include "libavcodec/mpeg4audio.h"
static const AVCodecTag flv_video_codec_ids[] = {
@@ -514,7 +514,7 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
for (samplerate_index = 0; samplerate_index < 16;
samplerate_index++)
if (flv->audio_par->sample_rate
-== mpeg4audio_sample_rates[samplerate_index])
+==
avpriv_mpeg4audio_sample_rates[samplerate_index])
break;
init_put_bits(&pbc, data, sizeof(data));
--
2.21.0
___
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 V3 1/3] tools/python: add script to convert TensorFlow model (.pb) to native model (.model)
> -Original Message-
> From: Guo, Yejun
> Sent: Thursday, June 13, 2019 1:31 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun
> Subject: [PATCH V3 1/3] tools/python: add script to convert TensorFlow model
> (.pb) to native model (.model)
>
> For example, given TensorFlow model file espcn.pb,
> to generate native model file espcn.model, just run:
> python convert.py espcn.pb
>
> In current implementation, the native model file is generated for
> specific dnn network with hard-code python scripts maintained out of ffmpeg.
> For example, srcnn network used by vf_sr is generated with
> https://github.com/HighVoltageRocknRoll/sr/blob/master/generate_header_a
> nd_model.py#L85
>
> In this patch, the script is designed as a general solution which
> converts general TensorFlow model .pb file into .model file. The script
> now has some tricky to be compatible with current implemention, will
> be refined step by step.
>
> The script is also added into ffmpeg source tree. It is expected there
> will be many more patches and community needs the ownership of it.
>
> Another technical direction is to do the conversion in c/c++ code within
> ffmpeg source tree. While .pb file is organized with protocol buffers,
> it is not easy to do such work with tiny c/c++ code, see more discussion
> at http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244496.html. So,
> choose the python script.
>
> Signed-off-by: Guo, Yejun
> ---
> .gitignore | 1 +
> tools/python/convert.py | 52 +
> tools/python/convert_from_tensorflow.py | 201
>
> 3 files changed, 254 insertions(+)
> create mode 100644 tools/python/convert.py
> create mode 100644 tools/python/convert_from_tensorflow.py
this patch set ping for review, thanks.
>
> diff --git a/.gitignore b/.gitignore
> index 0e57cb0..2450ee8 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -36,3 +36,4 @@
> /lcov/
> /src
> /mapfile
> +/tools/python/__pycache__/
> diff --git a/tools/python/convert.py b/tools/python/convert.py
> new file mode 100644
> index 000..662b429
> --- /dev/null
> +++ b/tools/python/convert.py
> @@ -0,0 +1,52 @@
> +# Copyright (c) 2019 Guo Yejun
> +#
> +# 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
> +#
>
> ==
> +
> +# verified with Python 3.5.2 on Ubuntu 16.04
> +import argparse
> +import os
> +from convert_from_tensorflow import *
> +
> +def get_arguments():
> +parser = argparse.ArgumentParser(description='generate native mode
> model with weights from deep learning model')
> +parser.add_argument('--outdir', type=str, default='./', help='where to
> put
> generated files')
> +parser.add_argument('--infmt', type=str, default='tensorflow',
> help='format of the deep learning model')
> +parser.add_argument('infile', help='path to the deep learning model with
> weights')
> +
> +return parser.parse_args()
> +
> +def main():
> +args = get_arguments()
> +
> +if not os.path.isfile(args.infile):
> +print('the specified input file %s does not exist' % args.infile)
> +exit(1)
> +
> +if not os.path.exists(args.outdir):
> +print('create output directory %s' % args.outdir)
> +os.mkdir(args.outdir)
> +
> +basefile = os.path.split(args.infile)[1]
> +basefile = os.path.splitext(basefile)[0]
> +outfile = os.path.join(args.outdir, basefile) + '.model'
> +
> +if args.infmt == 'tensorflow':
> +convert_from_tensorflow(args.infile, outfile)
> +
> +if __name__ == '__main__':
> +main()
> diff --git a/tools/python/convert_from_tensorflow.py
> b/tools/python/convert_from_tensorflow.py
> new file mode 100644
> index 000..37049e5
> --- /dev/null
> +++ b/tools/python/convert_from_tensorflow.py
> @@ -0,0 +1,201 @@
> +# Copyright (c) 2019 Guo Yejun
> +#
> +# 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 hop
Re: [FFmpeg-devel] [PATCH] avformat/oggdec: only parse headers before data
On Wed, Jun 19, 2019 at 11:25 AM Michael Niedermayer wrote: > breaks: > ./ffmpeg -i bgc.sub.dub.ogm -vframes 3 -y test.webm > sample: http://samples.mplayerhq.hu/ogg/bgc.sub.dub.ogm > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > Thanks Michael. That file is example of the "invalid" sort we were discussing previously. As I understand it, the spec requires that data packets not be interleaved with header packets - the headers for all streams should conclude before data packets begin. In this file we see a few headers followed by a data packet (stream 0), followed by more headers for streams 1 - 3. We knew this change would break such files. Can we live it? James, any workaround? If not I'm still open to setting st->internal->need_context_update as discussed in the earlier patch (https://patchwork.ffmpeg.org/patch/11983/) Chris ___ 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] avformat/oggdec: only parse headers before data
On Wed, Jun 19, 2019 at 7:11 PM Chris Cunningham wrote: > On Wed, Jun 19, 2019 at 11:25 AM Michael Niedermayer > wrote: > >> breaks: >> ./ffmpeg -i bgc.sub.dub.ogm -vframes 3 -y test.webm >> sample: http://samples.mplayerhq.hu/ogg/bgc.sub.dub.ogm >> >> [...] >> >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> > > Thanks Michael. > > That file is example of the "invalid" sort we were discussing previously. > As I understand it, the spec requires that data packets not be interleaved > with header packets - the headers for all streams should conclude before > data packets begin. In this file we see a few headers followed by a data > packet (stream 0), followed by more headers for streams 1 - 3. > > We knew this change would break such files. Can we live it? James, any > workaround? If not I'm still open to > setting st->internal->need_context_update as discussed in the earlier patch > (https://patchwork.ffmpeg.org/patch/11983/) > > Chris > Quick refresher on my fuzzer input avformat_find_stream_info finds 3 streams [0] AV_CODEC_ID_OPUS [1] AV_CODEC_ID_TEXT [2] AV_CODEC_ID_NONE A bit later we're reading frames out and stream 2 encounters a header that changes the codec from NONE -> AV_CODEC_ID_GSM_MS. ogm_header() assigns this to codecpar->codec_id, but st->internal->avctx->codec_id is never updated (remains NONE). This mismatch ultimately triggers an assert0 in gsm_parse (expecting only gsm codecs). Things tried so far: - keep codec internal in sync (need_context_update = 1) https://patchwork.ffmpeg.org/patch/11983/ - don't allow codec id = none in ogm parse https://patchwork.ffmpeg.org/patch/13529/ - and disallow headers after data (this thread) I think this last one misses the mark slightly. It happens that the a codec change corresponds with a header that comes after data packets start, but I think it could just as easily have occurred without that interleaved data packet. The root question is whether there is some way to know "this header is garbage" ... but a header that assigns a reasonable gsm codec (particularly when the codec was not yet known) seems pretty reasonable. ___ 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] avformat/oggdec: only parse headers before data
On 6/19/2019 11:11 PM, Chris Cunningham wrote: > On Wed, Jun 19, 2019 at 11:25 AM Michael Niedermayer > wrote: > > breaks: > ./ffmpeg -i bgc.sub.dub.ogm -vframes 3 -y test.webm > sample: http://samples.mplayerhq.hu/ogg/bgc.sub.dub.ogm > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > Thanks Michael. > > That file is example of the "invalid" sort we were discussing > previously. As I understand it, the spec requires that data packets not > be interleaved with header packets - the headers for all streams should > conclude before data packets begin. In this file we see a few headers > followed by a data packet (stream 0), followed by more headers for > streams 1 - 3. > > We knew this change would break such files. Can we live it? James, any > workaround? If not I'm still open to > setting st->internal->need_context_update as discussed in the earlier > patch (https://patchwork.ffmpeg.org/patch/11983/) I'm fine going the need_context_update route if trying to skip extra headers is being so problematic. > > Chris ___ 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] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
> 在 2019年6月20日，上午1:37，Michael Niedermayer 写道： > > On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: >> ffmpeg | branch: master | Bodecs Bela | Mon Jun 17 >> 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | committer: >> Steven Liu >> >> av_format/hlsenc: fix %v handling by format_name function >> >> Hi All, >> >> When multiple variant streams are specified by var_stream_map option, %v >> placeholder in various names ensures that each variant has its unique >> names. Most of %v handlng is done in format_name function. Currently >> in this function the result buffer is the same as the >> input pattern buffer, so you must allocate it before calling format_name >> function. It also means, that it is silently assumed that the result >> string will NOT be >> longer that the pattern string. It is true most of the time, because %v >> may appear only once in the pattern string and number of variant streams >> is less than 100 in practical cases. But theoretically it will fail if >> specified number of variant streams is greater than 100 (i.e. longer >> than 2 digits). >> This patch fixes this behaviour by altering format_name function to >> allocate the >> result buffer and return it to the caller. >> >> Please, review this patch. >> >> best, >> >> Bela >>> From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 >> From: Bela Bodecs >> Date: Mon, 17 Jun 2019 14:31:36 +0200 >> Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function >> >> When multiple variant streams are specified by var_stream_map option, %v >> placeholder in various names ensures that each variant has its unique >> names. Most of %v handlng is done in format_name function. Currently >> in this function the result buffer is the same as the input pattern >> buffer, so you must allocate it before calling format_name function. It >> also means, that it is silently assumed that the result string will NOT >> be longer that the pattern string. It is true most of the time, because >> %v may appear only once in the pattern string and number of variant >> streams is less than 100 in practical cases. But theoretically it will >> fail if specified number of variant streams is greater than 100. This >> patch fixes this behaviour by altering format_name function to allocate >> the result buffer and return it to the caller. >> >> Signed-off-by: Bela Bodecs > > This broke fate (segfaults) also it produces new compiler warnings which > probably are pointing to the cause > > libavformat/hlsenc.c: In function ‘hls_init’: > libavformat/hlsenc.c:2643:9: warning: passing argument 2 of ‘format_name’ > makes pointer from integer without a cast [enabled by default] > ret = format_name(s->url, i, vs->m3u8_name); > ^ > libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of > type ‘int’ > static int format_name(const char *buf, char **s, int index) >^ > libavformat/hlsenc.c:2643:9: warning: passing argument 3 of ‘format_name’ > makes integer from pointer without a cast [enabled by default] > ret = format_name(s->url, i, vs->m3u8_name); > ^ > libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of type > ‘char *’ > static int format_name(const char *buf, char **s, int index) >^ > libavformat/hlsenc.c:2712:13: warning: passing argument 2 of ‘format_name’ > makes pointer from integer without a cast [enabled by default] > ret = format_name(vs->basename, basename_size, i); > ^ > libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of > type ‘int’ > static int format_name(const char *buf, char **s, int index) >^ > libavformat/hlsenc.c:2767:25: warning: passing argument 2 of ‘format_name’ > makes pointer from integer without a cast [enabled by default] > format_name(vs->fmp4_init_filename, > fmp4_init_filename_len, i); > ^ > libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of > type ‘int’ > static int format_name(const char *buf, char **s, int index) >^ > libavformat/hlsenc.c:2832:17: warning: passing argument 2 of ‘format_name’ > makes pointer from integer without a cast [enabled by default] > ret = format_name(vs->vtt_m3u8_name, vtt_basename_size, i); > ^ > libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of > type ‘int’ > static int format_name(const char *buf, char **s, int index) > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User > questions about the command line tools should be sent to the ffmpeg-user ML. > And questions about how to use libav* should be sent to the libav-user ML. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > h
Re: [FFmpeg-devel] [PATCH] dash: change default MP4 extension to .m4s
On 6/19/19 3:08 PM, Alfred E. Heggestad wrote:
> On 19/06/2019 07:21, Jeyapal, Karthick wrote:
>>
>> On 6/18/19 1:48 PM, Alfred E. Heggestad wrote:
>>> On 18/06/2019 04:02, Steven Liu wrote:
Alfred E. Heggestad 于2019年6月17日周一 下午4:02写道：
>
>From 923da82598bddd1ed05750427dbc71e607d296a2 Mon Sep 17 00:00:00 2001
> From: "Alfred E. Heggestad"
> Date: Mon, 17 Jun 2019 09:59:04 +0200
> Subject: [PATCH] dash: change default MP4 extension to .m4s
>
> this was changed in commit 281a21ed50849e3c8c0d03005230e9fd07c24370
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 3fd7e78166..a51a1da0ca 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -166,7 +166,7 @@ static struct format_string {
> const char *str;
> } formats[] = {
> { SEGMENT_TYPE_AUTO, "auto" },
> -{ SEGMENT_TYPE_MP4, "mp4" },
> +{ SEGMENT_TYPE_MP4, "m4s" },
> { SEGMENT_TYPE_WEBM, "webm" },
> { 0, NULL }
> };
> --
> 2.20.1 (Apple Git-117)
>
> ___
> 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".
LGTM
>>>
>>> the background for this is the extension for DASH media files
>>> used to be *.m4s and it is now *.mp4
>>>
>>>
>>> the patch is a suggestion and should be checked by the DASH experts
>>>
>>> what is correct according to the standard ?
>>>
>>> the media-file is not really an .mp4 file, it cannot be
>>> played with e.g. ffplay:
>>>
>>>$ ffplay chunk-stream1-1.m4s
>> Thanks for submitting the patch. I agree that m4s should be extension for
>> media segments.
>> mp4 should be used only for complete files.
>> With respect to the patch, dashenc generates either multiple segments or a
>> single file(with byte range as segments) based on "single_file" option.
>> The default of mp4 is correct when "single_file" is enabled. But it is wrong
>> when "single_file" is disabled. The proposed patch just reverses this
>> situation.
>> I would suggest the patch should handle both cases correctly.
>
> Hi,
>
> many thanks for your review comments.
>
> I have updated the patch based on your comments, please see below.
>
>
> this code works in my application (both single and multi files)
> but the code should be reviewed by someone who has better
> knowledge with the code.
Thanks for sending a revised patch promptly.
I think your patch below might adversely affect the following code
avio_printf(out, "\t\t\tformat_name, os->codec_str, bandwidth_str,
s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
mimetype will become "video/m4s" for if the file extension is m4s. But I am not
sure if it is correct or if such a mimetype exists.
I guess mimetype should remain as "video/mp4" even if the file extension is m4s.
Please let me know your views on this.
>
>
> ...
>
>
>
> From 2059bfad56eadbccee968cc34dd594089a1e8984 Mon Sep 17 00:00:00 2001
> From: "Alfred E. Heggestad"
> Date: Wed, 19 Jun 2019 11:33:13 +0200
> Subject: [PATCH] dash: change default MP4 extension to .m4s
>
> ---
> libavformat/dashenc.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 3fd7e78166..a60547ef0d 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -250,6 +250,10 @@ static int init_segment_types(AVFormatContext *s)
> c->segment_type_option, s->streams[i]->codecpar->codec_id);
> os->segment_type = segment_type;
> os->format_name = get_format_str(segment_type);
> +
> +if (segment_type == SEGMENT_TYPE_MP4 && !c->single_file)
> +os->format_name = "m4s";
> +
> if (!os->format_name) {
> av_log(s, AV_LOG_ERROR, "Could not select DASH segment
> type for stream %d\n", i);
> return AVERROR_MUXER_NOT_FOUND;
> @@ -1210,7 +1214,7 @@ static int dash_init(AVFormatContext *s)
> }
> }
>
> -ctx->oformat = av_guess_format(os->format_name, NULL, NULL);
> +ctx->oformat =
> av_guess_format(get_format_str(os->segment_type), NULL, NULL);
> if (!ctx->oformat)
> return AVERROR_MUXER_NOT_FOUND;
> os->ctx = ctx;
___
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 2/4] avcodec/hevc_ps: Fix integer overflow with num_tile_rows
On 6/19/2019 3:59 PM, James Almer wrote:
> On 6/19/2019 3:13 PM, Michael Niedermayer wrote:
>> On Wed, Jun 19, 2019 at 12:54:25PM -0300, James Almer wrote:
>>> On 6/19/2019 6:22 AM, Michael Niedermayer wrote:
On Mon, Jun 17, 2019 at 07:55:45PM -0300, James Almer wrote:
> On 6/17/2019 6:54 PM, Michael Niedermayer wrote:
>> On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
>>> On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
Fixes: signed integer overflow: -2147483648 - 1 cannot be represented
in type 'int'
Fixes:
14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hevc_ps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 80df417e4f..0ed6682bb4 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1596,7 +1596,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
AVCodecContext *avctx,
if (pps->num_tile_rows <= 0 ||
pps->num_tile_rows >= sps->height) {
av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of
range: %d\n",
- pps->num_tile_rows - 1);
+ pps->num_tile_rows - 1U);
>>>
>>> The proper fix for this is making pps->num_tile_rows/cols unsigned.
[...]
>>
>> is this here ok if num_tile_rows is 0 ?
>> for (i = 0; i < pps->num_tile_rows - 1; i++) { (example line from ffmpeg
>> git)
>>
>> i would guess nearly everyone wold say yes without having seen the
>> discussion about the type. but of course if this is unsigned its not
>> going to be safe with it being 0.
>
> pps->num_tile_rows is set to a value returned by "get_ue_golomb_long() +
> 1", which will always be in the 1..UINT32_MAX range. It can't be 0, as
> it would be a bug. Int is definitely not the right type for it.
i dont think num_tile_rows of more than 2^31 (that is the negative when
signed range)
makes much sense but sure i can change it to unsigned if preferred.
>>>
>>> Of course it doesn't. In pretty much any sample it will be at least 1
>>> and at most 22, which is the max value allowed by hevc level 6.2 in
>>> table A.6. Only if the stream reports an undefined level it could go up
>>> to, if i'm reading this right, sps->ctb_height and not sps->height as
>>> the decoder is currently checking. This means you can even replace
>>> get_ue_golomb_long() for a get_ue_golomb(). That would also fix this.
>>>
>>> In any case, the bitstream value is unsigned, so the struct field should
>>> be unsigned as well. Having it be signed and assigning it a value using
>>> a function that potentially returns huge unsigned values introduced this
>>> issue to being with, so instead of working around it using type
>>> promotion, just make it follow the spec.
>>
>> what would be your feeling/oppinon about making the field uint16_t ?
>> this would make it unsigned in the struct but avoid the problems with
>> unsigned int ?
>
> That's fine. Could even make it uint8_t, like cbs_h265.h does. I'd also
> change it to use get_ue_golomb() while at it. And please do it for both
> rows and columns. Can be in separate patches if you want the rows one to
> explicitly address the fuzzing testcase.
>
> Can you also confirm my suspicion that the checks should be comparing
> the values with sps->ctb_height/weight and not with sps->height/weight?
Ok, so yes, it is. Should be changed in a separate patch as well.
>
>>
>> Thanks
>>
>> [...]
>>
>>
>> ___
>> 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".
Re: [FFmpeg-devel] [PATCH] avformat/segment: fix muxing tmcd tracks in MOV
On 18-06-2019 07:39 PM, Gyan wrote: Fixes crash when muxing tmcd tracks. Will push soon. ___ 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] libavformat/subfile: Improve AVSEEK_SIZE/SEEK_END seeking
The subfile protocol treats an end of 0 as meaning "until EOF"; this got
implemented by simply setting the end to INT64_MAX. But seeking relative
to EOF or AVSEEK_SIZE seeking hasn't been adapted; the result is that
e.g. the duration of transport streams isn't correctly determined when
this option is used. This is fixed in this patch.
Signed-off-by: Andreas Rheinhardt
---
libavformat/subfile.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libavformat/subfile.c b/libavformat/subfile.c
index b527f2bee1..2f162e0a34 100644
--- a/libavformat/subfile.c
+++ b/libavformat/subfile.c
@@ -116,11 +116,17 @@ static int subfile_read(URLContext *h, unsigned char
*buf, int size)
static int64_t subfile_seek(URLContext *h, int64_t pos, int whence)
{
SubfileContext *c = h->priv_data;
-int64_t new_pos = -1;
+int64_t new_pos = -1, end;
int ret;
+if (whence == AVSEEK_SIZE || whence == SEEK_END) {
+end = c->end;
+if (end == INT64_MAX && (end = ffurl_seek(c->h, 0, AVSEEK_SIZE)) < 0)
+return end;
+}
+
if (whence == AVSEEK_SIZE)
-return c->end - c->start;
+return end - c->start;
switch (whence) {
case SEEK_SET:
new_pos = c->start + pos;
@@ -129,7 +135,7 @@ static int64_t subfile_seek(URLContext *h, int64_t pos, int
whence)
new_pos += pos;
break;
case SEEK_END:
-new_pos = c->end + c->pos;
+new_pos = end + c->pos;
break;
}
if (new_pos < c->start)
--
2.21.0
___
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 V1 2/3] ffmpeg_opt: Respect default disposition when select audio/video
From: Jun Zhao
Respect default disposition when select audio/video
Signed-off-by: Jun Zhao
---
fftools/ffmpeg_opt.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 53d688b..f5ca18a 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2198,7 +2198,8 @@ static int open_output_file(OptionsContext *o, const char
*filename)
for (i = 0; i < nb_input_streams; i++) {
int new_area;
ist = input_streams[i];
-new_area = ist->st->codecpar->width *
ist->st->codecpar->height + 1*!!ist->st->codec_info_nb_frames;
+new_area = ist->st->codecpar->width *
ist->st->codecpar->height + 1*!!ist->st->codec_info_nb_frames
+ + 500*!!(ist->st->disposition &
AV_DISPOSITION_DEFAULT);
if (ist->user_set_discard == AVDISCARD_ALL)
continue;
if((qcr!=MKTAG('A', 'P', 'I', 'C')) && (ist->st->disposition &
AV_DISPOSITION_ATTACHED_PIC))
@@ -2221,7 +,8 @@ static int open_output_file(OptionsContext *o, const char
*filename)
for (i = 0; i < nb_input_streams; i++) {
int score;
ist = input_streams[i];
-score = ist->st->codecpar->channels +
1*!!ist->st->codec_info_nb_frames;
+score = ist->st->codecpar->channels +
1*!!ist->st->codec_info_nb_frames
++ 500*!!(ist->st->disposition &
AV_DISPOSITION_DEFAULT);
if (ist->user_set_discard == AVDISCARD_ALL)
continue;
if (ist->st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
--
1.7.1
___
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 V1 3/3] lavf/dump: More disposition flag dump
From: Jun Zhao More disposition flag dump Signed-off-by: Jun Zhao --- libavformat/dump.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/libavformat/dump.c b/libavformat/dump.c index bb8c72f..1c44656 100644 --- a/libavformat/dump.c +++ b/libavformat/dump.c @@ -547,8 +547,16 @@ static void dump_stream_format(AVFormatContext *ic, int i, av_log(NULL, AV_LOG_INFO, " (visual impaired)"); if (st->disposition & AV_DISPOSITION_CLEAN_EFFECTS) av_log(NULL, AV_LOG_INFO, " (clean effects)"); +if (st->disposition & AV_DISPOSITION_ATTACHED_PIC) +av_log(NULL, AV_LOG_INFO, " (attached pic)"); +if (st->disposition & AV_DISPOSITION_TIMED_THUMBNAILS) +av_log(NULL, AV_LOG_INFO, " (timed thumbnails)"); +if (st->disposition & AV_DISPOSITION_CAPTIONS) +av_log(NULL, AV_LOG_INFO, " (captions)"); if (st->disposition & AV_DISPOSITION_DESCRIPTIONS) av_log(NULL, AV_LOG_INFO, " (descriptions)"); +if (st->disposition & AV_DISPOSITION_METADATA) +av_log(NULL, AV_LOG_INFO, " (metadata)"); if (st->disposition & AV_DISPOSITION_DEPENDENT) av_log(NULL, AV_LOG_INFO, " (dependent)"); if (st->disposition & AV_DISPOSITION_STILL_IMAGE) -- 1.7.1 ___ 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 V1 1/3] lavf/utils: Respect default disposition when select the AVStream
From: Jun Zhao Respect default disposition when select the AVStream Signed-off-by: Jun Zhao --- libavformat/utils.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index 3d764c1..886cd6f 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -4218,7 +4218,8 @@ int av_find_best_stream(AVFormatContext *ic, enum AVMediaType type, continue; } } -disposition = !(st->disposition & (AV_DISPOSITION_HEARING_IMPAIRED | AV_DISPOSITION_VISUAL_IMPAIRED)); +disposition = !(st->disposition & (AV_DISPOSITION_HEARING_IMPAIRED | AV_DISPOSITION_VISUAL_IMPAIRED)) + + !! (st->disposition & AV_DISPOSITION_DEFAULT); count = st->codec_info_nb_frames; bitrate = par->bit_rate; multiframe = FFMIN(5, count); -- 1.7.1 ___ 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] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation
The previous calculation code did not account for the fact that the copy_offset for the start of the frame array is at index 0, yet the scan line number from the rfc4175 RTP header starts at 1. This caused 2 issues to appear: - The first scan line was being copied into the array where the second scan line should be. This caused the resulting video to have a green line at the top of it. - Since the packet containing the last scan line would fail the calculation, the packet with the RTP marker would not be processed which caused a log message saying "Missed previous RTP marker" to be outputted for each frame. Signed-off-by: Jacob Siddall --- libavformat/rtpdec_rfc4175.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c index e9c62c1..ec838fe 100644 --- a/libavformat/rtpdec_rfc4175.c +++ b/libavformat/rtpdec_rfc4175.c @@ -206,7 +206,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext *data, length = payload_len; /* prevent ill-formed packets to write after buffer's end */ -copy_offset = (line * data->width + offset) * data->pgroup / data->xinc; +copy_offset = ((line - 1) * data->width + offset) * data->pgroup / data->xinc; if (copy_offset + length > data->frame_size) return AVERROR_INVALIDDATA; -- 2.20.1 ___ 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 v3] vf_drawtext - Add variables
Am 20.06.2019 um 00:01 schrieb greg Luce : >> Who has written the patch that you attached? >> >> Thank you, Carl Eugen > > The C code was written by kepstin > I wrote the change to the documentation with help from several people > There's a trac ticket at https://trac.ffmpeg.org/ticket/7947 Then please split the patch, fix the author name and mention the ticket in the commit message. Carl Eugen ___ 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".
