Re: [FFmpeg-devel] [PATCH v1 1/3] avfilter/vf_yadif: rename config_props -> config_input, link -> outlink
On Thu, Nov 28, 2019 at 9:34 AM wrote:
>
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_yadif.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
> index 3107924932..0b34c5045b 100644
> --- a/libavfilter/vf_yadif.c
> +++ b/libavfilter/vf_yadif.c
> @@ -311,26 +311,26 @@ static int query_formats(AVFilterContext *ctx)
> return ff_set_common_formats(ctx, fmts_list);
> }
>
> -static int config_props(AVFilterLink *link)
> +static int config_output(AVFilterLink *outlink)
> {
> -AVFilterContext *ctx = link->src;
> +AVFilterContext *ctx = outlink->src;
> YADIFContext *s = ctx->priv;
>
> -link->time_base.num = ctx->inputs[0]->time_base.num;
> -link->time_base.den = ctx->inputs[0]->time_base.den * 2;
> -link->w = ctx->inputs[0]->w;
> -link->h = ctx->inputs[0]->h;
> +outlink->time_base.num = ctx->inputs[0]->time_base.num;
> +outlink->time_base.den = ctx->inputs[0]->time_base.den * 2;
> +outlink->w = ctx->inputs[0]->w;
> +outlink->h = ctx->inputs[0]->h;
>
> if(s->mode & 1)
> -link->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
> +outlink->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
> (AVRational){2, 1});
>
> -if (link->w < 3 || link->h < 3) {
> +if (outlink->w < 3 || outlink->h < 3) {
> av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or lines is
> not supported\n");
> return AVERROR(EINVAL);
> }
>
> -s->csp = av_pix_fmt_desc_get(link->format);
> +s->csp = av_pix_fmt_desc_get(outlink->format);
> s->filter = filter;
> if (s->csp->comp[0].depth > 8) {
> s->filter_line = filter_line_c_16bit;
> @@ -369,7 +369,7 @@ static const AVFilterPad avfilter_vf_yadif_outputs[] = {
> .name = "default",
> .type = AVMEDIA_TYPE_VIDEO,
> .request_frame = ff_yadif_request_frame,
> -.config_props = config_props,
> +.config_props = config_output,
> },
> { NULL }
> };
> --
> 2.21.0
>
Why ？
___
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 4/4] fate/filter-video: add two tests for dnn_processing with format rgb24 and grayf32
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Guo, Yejun > Sent: Friday, November 22, 2019 4:02 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 4/4] fate/filter-video: add two tests for > dnn_processing with format rgb24 and grayf32 > > > > > -Original Message- > > From: Guo, Yejun > > Sent: Friday, November 22, 2019 3:50 PM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Guo, Yejun > > Subject: [PATCH 4/4] fate/filter-video: add two tests for dnn_processing > > with > > format rgb24 and grayf32 > > > > Signed-off-by: Guo, Yejun > > --- > > tests/fate/filter-video.mak| 4 ++ > > ...filter-dnn_processing-halve_first_channel_float | 55 > > ++ > > .../fate/filter-dnn_processing-halve_gray_float| 55 > > ++ > > 3 files changed, 114 insertions(+) > > create mode 100644 > > tests/ref/fate/filter-dnn_processing-halve_first_channel_float > > create mode 100644 tests/ref/fate/filter-dnn_processing-halve_gray_float > > > > diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak > > index b520690..d98fcb7 100644 > > --- a/tests/fate/filter-video.mak > > +++ b/tests/fate/filter-video.mak > > @@ -259,6 +259,10 @@ FATE_FILTER_SAMPLES-$(call ALLYES, > PNG_DECODER > > APNG_DEMUXER FORMAT_FILTER COLOR_ > > FATE_FILTER_VSYNTH-$(CONFIG_PHASE_FILTER) += fate-filter-phase > > fate-filter-phase: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf phase > > > > +FATE_FILTER_VSYNTH-$(CONFIG_DNN_PROCESSING_FILTER) += > > fate-filter-dnn_processing-halve_first_channel_float > > fate-filter-dnn_processing-halve_gray_float > > +fate-filter-dnn_processing-halve_first_channel_float: CMD = framecrc -c:v > > pgmyuv -i $(SRC) -vf > > > dnn_processing=model=$(TARGET_SAMPLES)/dnn_processing/halve_first_cha > > > nnel_float.model:input=dnn_in:output=dnn_out:fmt=rgb24:dnn_backend=nativ > > e > > +fate-filter-dnn_processing-halve_gray_float: CMD = framecrc -c:v pgmyuv -i > > $(SRC) -vf > > > dnn_processing=model=$(TARGET_SAMPLES)/dnn_processing/halve_gray_floa > > t.model:input=dnn_in:output=dnn_out:fmt=grayf32:dnn_backend=native > > + > > These two tests need model files under fate-suite/dnn_processing, I've > attached them > in the email, could someone help to upload them, thanks. > > to see how these two models are generated, please see > https://github.com/guoyejun/dnn_processing, thanks. this patch set asks for review, 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".
Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for H2S
Am Do., 28. Nov. 2019 um 07:56 Uhr schrieb Song, Ruiling
:
> > > Am 28.11.2019 um 06:37 schrieb Sun, Xinpeng :
> > >
> > >>>
> > >>> +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> > >>> +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as input for
> > vaapi tone-mapping\n");
> > >>> +return AVERROR(EINVAL);
> > >>
> > >> Shouldn't this also accept unknown trc?
> > >> (With a warning)
> > >
> > > Sorry if I misunderstand "unknown trc". Did you mean the trc undefined by
> > ffmpeg or the trc unsupported by the driver?
> >
> > My question is:
> > If input_frame->color_trc is AVCOL_TRC_UNSPECIFIED, will the above fail?
> > But shouldn’t the user be able to use the filter in this case?
>
> I am not sure if assuming the input is using SMPTE2084 sounds more acceptable
> in case of unspecified? If yes, I think we can change as you suggested.
(Me neither.)
A warning could be shown instead of failing.
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] [PATCH v2] avfilter: Add tonemap vaapi filter for H2S
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Thursday, November 28, 2019 5:16 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for
> H2S
>
> Am Do., 28. Nov. 2019 um 07:56 Uhr schrieb Song, Ruiling
> :
>
> > > > Am 28.11.2019 um 06:37 schrieb Sun, Xinpeng
> :
> > > >
> > > >>>
> > > >>> +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> > > >>> +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as input
> for
> > > vaapi tone-mapping\n");
> > > >>> +return AVERROR(EINVAL);
> > > >>
> > > >> Shouldn't this also accept unknown trc?
> > > >> (With a warning)
> > > >
> > > > Sorry if I misunderstand "unknown trc". Did you mean the trc
> undefined by
> > > ffmpeg or the trc unsupported by the driver?
> > >
> > > My question is:
> > > If input_frame->color_trc is AVCOL_TRC_UNSPECIFIED, will the above fail?
> > > But shouldn’t the user be able to use the filter in this case?
> >
> > I am not sure if assuming the input is using SMPTE2084 sounds more
> acceptable
> > in case of unspecified? If yes, I think we can change as you suggested.
>
> (Me neither.)
> A warning could be shown instead of failing.
Adding a warning sound good idea. But in order to proceed the tone-mapping, a
default input transfer-function need to be chosen, which I think we can use
SMPTE2084 here.
Ruiling
>
> 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 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 v1] avcodec/vaapi: set more flags for VASurfaceAttrib
Hi,
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Wang, Fei W
> Sent: Wednesday, November 20, 2019 10:40
> To: myp...@gmail.com; FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH v1] avcodec/vaapi: set more flags for
> VASurfaceAttrib
>
>
> > On Tue, Nov 19, 2019 at 4:24 PM Wangfei wrote:
> > >
> > > flags and value.type is needed when pass VASurfaceAttrib to driver.
> > > Otherwise the attribute will be considered invalid in driver.
> > >
> > > Signed-off-by: Wangfei
> > > ---
> > > libavcodec/vaapi_decode.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > > index 69512e1d45..a93aba5a5d 100644
> > > --- a/libavcodec/vaapi_decode.c
> > > +++ b/libavcodec/vaapi_decode.c
> > > @@ -350,6 +350,8 @@ static int
> > > vaapi_decode_find_best_format(AVCodecContext *avctx,
> > >
> > > ctx->pixel_format_attribute = (VASurfaceAttrib) {
> > > .type = VASurfaceAttribPixelFormat,
> > > +.flags = VA_SURFACE_ATTRIB_SETTABLE,
> > > +.value.type= VAGenericValueTypeInteger,
> > I can't found any description in libva about this part, do you have any
> > other
> > docs?
> I checked the logic of vaCreateSurfaces implementation in media-driver, it
> will check flags and value.type in VASurfaceAttrib when using it. If leaks of
> the info, it will consider the attribute is invalid or assert(in this case,
> flags
> checked first, so no assert occurred.):
> https://github.com/intel/media-
> driver/blob/8a8b8ae263a04cb5dd384d4625215cf296d2cc59/media_driver/lin
> ux/common/ddi/media_libva.cpp#L2149
>
> On the other hand, there is another place in ffmpeg-vaapi that sets
> VASurfaceAttrib, and it filled flags and value.type:
> https://github.com/FFmpeg/FFmpeg/blob/d73f06270600c37c74beeceac37f5
> 93838ced383/libavutil/hwcontext_vaapi.c#L527
> So I believe here we need do the same thing.
>
> > > .value.value.i = best_fourcc,
> > > };
Setting flags and type allows driver to assign the expected_fourcc/media_format
of surface
according to the best FourCC, instead of determining by the VA_RT_FORMAT_
defined in
vaapi_format_map[].
With this patch, decoder still works well even if a wrong VA_RT_FORMAT_ was
assigned.
(For example, VA_RT_FORMAT_YUV444 assigned to VA_FOURCC_NV12, when decoding
NV12 clips)
Patch LGTM since it seems to be more robust.(but also may hide some mistakes on
the other hand)
Thanks,
- linjie
___
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 v1 1/3] avfilter/vf_yadif: rename config_props -> config_input, link -> outlink
On Thu, Nov 28, 2019 at 02:24:38PM +0800, myp...@gmail.com wrote:
> On Thu, Nov 28, 2019 at 9:34 AM wrote:
> >
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_yadif.c | 20 ++--
> > 1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
> > index 3107924932..0b34c5045b 100644
> > --- a/libavfilter/vf_yadif.c
> > +++ b/libavfilter/vf_yadif.c
> > @@ -311,26 +311,26 @@ static int query_formats(AVFilterContext *ctx)
> > return ff_set_common_formats(ctx, fmts_list);
> > }
> >
> > -static int config_props(AVFilterLink *link)
> > +static int config_output(AVFilterLink *outlink)
> > {
> > -AVFilterContext *ctx = link->src;
> > +AVFilterContext *ctx = outlink->src;
> > YADIFContext *s = ctx->priv;
> >
> > -link->time_base.num = ctx->inputs[0]->time_base.num;
> > -link->time_base.den = ctx->inputs[0]->time_base.den * 2;
> > -link->w = ctx->inputs[0]->w;
> > -link->h = ctx->inputs[0]->h;
> > +outlink->time_base.num = ctx->inputs[0]->time_base.num;
> > +outlink->time_base.den = ctx->inputs[0]->time_base.den * 2;
> > +outlink->w = ctx->inputs[0]->w;
> > +outlink->h = ctx->inputs[0]->h;
> >
> > if(s->mode & 1)
> > -link->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
> > +outlink->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
> > (AVRational){2, 1});
> >
> > -if (link->w < 3 || link->h < 3) {
> > +if (outlink->w < 3 || outlink->h < 3) {
> > av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or lines
> > is not supported\n");
> > return AVERROR(EINVAL);
> > }
> >
> > -s->csp = av_pix_fmt_desc_get(link->format);
> > +s->csp = av_pix_fmt_desc_get(outlink->format);
> > s->filter = filter;
> > if (s->csp->comp[0].depth > 8) {
> > s->filter_line = filter_line_c_16bit;
> > @@ -369,7 +369,7 @@ static const AVFilterPad avfilter_vf_yadif_outputs[] = {
> > .name = "default",
> > .type = AVMEDIA_TYPE_VIDEO,
> > .request_frame = ff_yadif_request_frame,
> > -.config_props = config_props,
> > +.config_props = config_output,
> > },
> > { NULL }
> > };
> > --
> > 2.21.0
> >
> Why ？
As both input and output have config_props, it's better to make
the function name clear for input or output for readability. So
I change it by the way as I'm touch other place.
___
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] [libdav1d.c]: Add options for spatial layers.
On 11/27/2019 9:25 PM, Thierry Foucu wrote: > Disable by default to output all the layers, to match libaomdec wrapper. > Add option to select the operating point for the spatial layers. > Update the documentation with the new options. > --- > doc/decoders.texi | 6 ++ > libavcodec/libdav1d.c | 8 > 2 files changed, 14 insertions(+) Fixed the range of oppoint (if -1 is the default, it needs to be inside the valid range), bumped micro, and pushed. 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] [PATCH 2/3] lavf/vividas: free the PB when get EOF
From: Jun Zhao free the PB when get EOF. Signed-off-by: Jun Zhao --- libavformat/vividas.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/libavformat/vividas.c b/libavformat/vividas.c index 16642c0..f354d7d 100644 --- a/libavformat/vividas.c +++ b/libavformat/vividas.c @@ -296,8 +296,10 @@ static int track_header(VividasDemuxContext *viv, AVFormatContext *s, uint8_t * for (i=0;ihttps://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] lavf/vividas: check avformat_new_stream() return
From: Jun Zhao
check avformat_new_stream() return.
Signed-off-by: Jun Zhao
---
libavformat/vividas.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index f20af3d..16642c0 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -319,6 +319,8 @@ static int track_header(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *
for (i = 0; i < num_video; i++) {
AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
st->id = i;
@@ -352,6 +354,8 @@ static int track_header(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *
for(i=0;inum_audio;i++) {
int q;
AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
st->id = num_video + i;
--
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".
Re: [FFmpeg-devel] [PATCH 2/3] lavf/vividas: free the PB when get EOF
On Thu, 28. Nov 21:40, Jun Zhao wrote:
> From: Jun Zhao
>
> free the PB when get EOF.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/vividas.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/vividas.c b/libavformat/vividas.c
> index 16642c0..f354d7d 100644
> --- a/libavformat/vividas.c
> +++ b/libavformat/vividas.c
> @@ -296,8 +296,10 @@ static int track_header(VividasDemuxContext *viv,
> AVFormatContext *s, uint8_t *
> for (i=0;i int c = avio_r8(pb);
> for (j=0;j -if (avio_feof(pb))
> +if (avio_feof(pb)) {
> +av_free(pb);
> return AVERROR_EOF;
> +}
> avio_r8(pb); // val_3
> avio_r8(pb); // val_4
> }
I think Michael posted same patch recently
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253390.html
--
Andriy
___
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] lavc/mvha: Check init_get_bits8() for failure
From: Jun Zhao fix potential null pointer dereference Signed-off-by: Jun Zhao --- libavcodec/mvha.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/libavcodec/mvha.c b/libavcodec/mvha.c index 636b5e6..4b03a79 100644 --- a/libavcodec/mvha.c +++ b/libavcodec/mvha.c @@ -190,7 +190,9 @@ static int decode_frame(AVCodecContext *avctx, GetBitContext *gb = &s->gb; int first_symbol, symbol; -init_get_bits8(gb, avpkt->data + 8, avpkt->size - 8); +ret = init_get_bits8(gb, avpkt->data + 8, avpkt->size - 8); +if (ret < 0) +return ret; skip_bits(gb, 24); -- 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/vividas: Avoid allocation of AVIOContext
Put an AVIOContext whose lifetime doesn't extend beyond the function where
it is allocated on the stack instead of allocating and freeing it. This
also avoids the need to free it, which in this case fixes possible
memleaks on error.
Signed-off-by: Andreas Rheinhardt
---
libavformat/vividas.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index f20af3d7c2..88fa89a3cf 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -282,11 +282,9 @@ static int track_header(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *
int64_t off;
int val_1;
int num_video;
-AVIOContext *pb;
+AVIOContext pb0, *pb = &pb0;
-pb = avio_alloc_context(buf, size, 0, NULL, NULL, NULL, NULL);
-if (!pb)
-return AVERROR(ENOMEM);
+ffio_init_context(pb, buf, size, 0, NULL, NULL, NULL, NULL);
ffio_read_varlen(pb); // track_header_len
avio_r8(pb); // '1'
@@ -383,7 +381,6 @@ static int track_header(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *
for (j = 0; j < num_data; j++) {
uint64_t len = ffio_read_varlen(pb);
if (len > INT_MAX/2 - xd_size) {
-av_free(pb);
return AVERROR_INVALIDDATA;
}
data_len[j] = len;
@@ -392,7 +389,6 @@ static int track_header(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *
st->codecpar->extradata_size = 64 + xd_size + xd_size / 255;
if (ff_alloc_extradata(st->codecpar,
st->codecpar->extradata_size)) {
-av_free(pb);
return AVERROR(ENOMEM);
}
@@ -402,7 +398,6 @@ static int track_header(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *
for (j = 0; j < num_data - 1; j++) {
unsigned delta = av_xiphlacing(&p[offset], data_len[j]);
if (delta > data_len[j]) {
-av_free(pb);
return AVERROR_INVALIDDATA;
}
offset += delta;
@@ -423,7 +418,6 @@ static int track_header(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *
}
}
-av_free(pb);
return 0;
}
@@ -432,13 +426,11 @@ static int track_index(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *bu
int64_t off;
int64_t poff;
int maxnp=0;
-AVIOContext *pb;
+AVIOContext pb0, *pb = &pb0;
int i;
int64_t filesize = avio_size(s->pb);
-pb = avio_alloc_context(buf, size, 0, NULL, NULL, NULL, NULL);
-if (!pb)
-return AVERROR(ENOMEM);
+ffio_init_context(pb, buf, size, 0, NULL, NULL, NULL, NULL);
ffio_read_varlen(pb); // track_index_len
avio_r8(pb); // 'c'
@@ -448,7 +440,6 @@ static int track_index(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *bu
viv->sb_blocks = av_calloc(viv->n_sb_blocks, sizeof(VIV_SB_block));
if (!viv->sb_blocks) {
viv->n_sb_blocks = 0;
-av_free(pb);
return AVERROR(ENOMEM);
}
@@ -479,11 +470,9 @@ static int track_index(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *bu
goto error;
viv->sb_entries = av_calloc(maxnp, sizeof(VIV_SB_entry));
-av_free(pb);
return 0;
error:
-av_free(pb);
viv->n_sb_blocks = 0;
av_freep(&viv->sb_blocks);
return AVERROR_INVALIDDATA;
--
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 v2] avfilter/vf_libvmaf: Check for av_frame_alloc failure
On Wed, Nov 27, 2019 at 11:26:15AM +0100, Paul B Mahol wrote: > On 11/27/19, Limin Wang wrote: > > On Wed, Nov 27, 2019 at 11:09:23AM +0100, Nikola Pajkovsky wrote: > >> lance.lmw...@gmail.com writes: > >> > >> > From: Limin Wang > >> > > >> > Reviewed-by: Paul B Mahol > >> > Signed-off-by: Limin Wang > >> > --- > >> > Add Reviewed-by:, pleae help push it > >> > > >> > libavfilter/vf_libvmaf.c | 3 +++ > >> > 1 file changed, 3 insertions(+) > >> > > >> > diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c > >> > index ed3a383..14c3216 100644 > >> > --- a/libavfilter/vf_libvmaf.c > >> > +++ b/libavfilter/vf_libvmaf.c > >> > @@ -235,6 +235,9 @@ static av_cold int init(AVFilterContext *ctx) > >> > > >> > s->gref = av_frame_alloc(); > >> > s->gmain = av_frame_alloc(); > >> > +if (!s->gref || !s->gmain) > >> > +return AVERROR(ENOMEM); > >> > + > >> > >> When av_frame_alloc() return allocated memory for s->gref and > >> av_frame_alloc() fails for s->gmain, it will leak memory for s->gref. > >> > >> Correct code is: > >> > >> s->gref = av_frame_alloc(); > >> if (!s->gref) > >> return AVERROR(ENOMEM); > >> > >> s->gmain = av_frame_alloc(); > >> if (!s->gmain) > >> return AVERROR(ENOMEM); > > > > Thank for your review, I recall they'll be freed in uninit function, so > > my patch looks simple. > > > > Yes, patch should be applied as is. will apply 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".
[FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: Fix erroneous results for mean and stdev with pixel bits >8
From: Limin Wang
The following is one of the testing results, you can observe the result of
16bit isn't correct.
1, yuv420p
./ffmpeg -f lavfi -i
color=black:duration=1:r=1:size=1280x720,format=yuv420p,showinfo
Master:
mean:[16 128 128] stdev:[0.0 0.0 0.0]
After applied the patch:
mean:[16 128 128] stdev:[0.0 0.0 0.0]
2, yuv420p10
./ffmpeg -f lavfi -i
color=black:duration=1:r=1:size=1280x720,format=yuv420p10,showinfo
Master:
mean:[32 1 1] stdev:[32.0 1.0 1.0]
After applied the patch:
mean:[64 512 512] stdev:[0.0 0.0 0.0]
Signed-off-by: Limin Wang
---
libavfilter/vf_showinfo.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 31f6b32..96f7c59 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -202,7 +202,7 @@ static void dump_color_property(AVFilterContext *ctx,
AVFrame *frame)
av_log(ctx, AV_LOG_INFO, "\n");
}
-static void update_sample_stats(const uint8_t *src, int len, int64_t *sum,
int64_t *sum2)
+static void update_sample_stats_8(const uint8_t *src, int len, int64_t *sum,
int64_t *sum2)
{
int i;
@@ -212,6 +212,25 @@ static void update_sample_stats(const uint8_t *src, int
len, int64_t *sum, int64
}
}
+static void update_sample_stats_16(const uint8_t *src, int len, int64_t *sum,
int64_t *sum2)
+{
+const uint16_t *src1 = (const uint16_t *)src;
+int i;
+
+for (i = 0; i < len/2; i++) {
+*sum += src1[i];
+*sum2 += src1[i] * src1[i];
+}
+}
+
+static void update_sample_stats(int depth, const uint8_t *src, int len,
int64_t *sum, int64_t *sum2)
+{
+if (depth <= 8)
+update_sample_stats_8(src, len, sum, sum2);
+else
+update_sample_stats_16(src, len, sum, sum2);
+}
+
static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
{
AVFilterContext *ctx = inlink->dst;
@@ -220,12 +239,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
uint32_t plane_checksum[4] = {0}, checksum = 0;
int64_t sum[4] = {0}, sum2[4] = {0};
int32_t pixelcount[4] = {0};
+int bitdepth = desc->comp[0].depth;
int i, plane, vsub = desc->log2_chroma_h;
for (plane = 0; plane < 4 && s->calculate_checksums && frame->data[plane]
&& frame->linesize[plane]; plane++) {
uint8_t *data = frame->data[plane];
int h = plane == 1 || plane == 2 ? AV_CEIL_RSHIFT(inlink->h, vsub) :
inlink->h;
int linesize = av_image_get_linesize(frame->format, frame->width,
plane);
+int width = linesize >> (bitdepth > 8);
if (linesize < 0)
return linesize;
@@ -234,8 +255,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
plane_checksum[plane] = av_adler32_update(plane_checksum[plane],
data, linesize);
checksum = av_adler32_update(checksum, data, linesize);
-update_sample_stats(data, linesize, sum+plane, sum2+plane);
-pixelcount[plane] += linesize;
+update_sample_stats(bitdepth, data, linesize, sum+plane,
sum2+plane);
+pixelcount[plane] += width;
data += frame->linesize[plane];
}
}
--
2.9.5
___
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 27/29] avformat/flacenc: Add const to ff_flac_write_header() parameter
On Wed, Nov 27, 2019 at 08:48:56AM +0100, Andreas Rheinhardt wrote: > The extradata is not changed at all. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/flacenc.h| 2 +- > libavformat/flacenc_header.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Any man who breaks a law that conscience tells him is unjust and willingly accepts the penalty by staying in jail in order to arouse the conscience of the community on the injustice of the law is at that moment expressing the very highest respect for law. - Martin Luther King Jr 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 1/3] lavf/vividas: check avformat_new_stream() return
Jun Zhao:
> From: Jun Zhao
>
> check avformat_new_stream() return.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/vividas.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/vividas.c b/libavformat/vividas.c
> index f20af3d..16642c0 100644
> --- a/libavformat/vividas.c
> +++ b/libavformat/vividas.c
> @@ -319,6 +319,8 @@ static int track_header(VividasDemuxContext *viv,
> AVFormatContext *s, uint8_t *
>
> for (i = 0; i < num_video; i++) {
> AVStream *st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
>
> st->id = i;
>
> @@ -352,6 +354,8 @@ static int track_header(VividasDemuxContext *viv,
> AVFormatContext *s, uint8_t *
> for(i=0;inum_audio;i++) {
> int q;
> AVStream *st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
>
> st->id = num_video + i;
>
>
Actually, the AVIOContext pb leaks when these errors happen. But don't
bother updating your patch, because pb should actually not be
allocated at all: I'll send a patch using ffio_init_context soon.
- Andreas
___
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] avcodec/vp8: fix multiple ff_thread_finish_setup() calls
On Wed, Nov 27, 2019 at 06:53:08PM +1100, Peter Ross wrote: > On Mon, Nov 25, 2019 at 10:14:41PM +0800, zhilizhao wrote: > > Please help to merge the patch if it’s acceptable, thanks! > > no code changes, it is acceptable as-is. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" 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 3/3] avformat/vividas: Free pb on all error paths in track_header()
Michael Niedermayer:
> Fixes: memleak
> Fixes:
> 19054/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5673287506198528
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/vividas.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/vividas.c b/libavformat/vividas.c
> index f20af3d7c2..2c6a3daca7 100644
> --- a/libavformat/vividas.c
> +++ b/libavformat/vividas.c
> @@ -296,8 +296,10 @@ static int track_header(VividasDemuxContext *viv,
> AVFormatContext *s, uint8_t *
> for (i=0;i int c = avio_r8(pb);
> for (j=0;j -if (avio_feof(pb))
> +if (avio_feof(pb)) {
> +av_free(pb);
> return AVERROR_EOF;
> +}
> avio_r8(pb); // val_3
> avio_r8(pb); // val_4
> }
> @@ -314,6 +316,7 @@ static int track_header(VividasDemuxContext *viv,
> AVFormatContext *s, uint8_t *
> avio_seek(pb, off, SEEK_SET);
> if (num_video != 1) {
> av_log(s, AV_LOG_ERROR, "number of video tracks %d is not 1\n",
> num_video);
> +av_free(pb);
> return AVERROR_PATCHWELCOME;
> }
>
A better solution for this is to not allocate the AVIOContext at all:
Its lifetime does not extend beyond the function it is used in. I
prepared a patch for this [1]. Given that vividas isn't covered by
FATE (apart from the probe function) my patch is untested. But it
should fix your fuzzing memleak. It will also imply that checking
whether avformat_new_stream() failed as is done in [2] won't produce
memleaks.
- Andreas
[1]: https://patchwork.ffmpeg.org/patch/16473/
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253551.html
___
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 v6 1/3] hevc_mp4toannexb: Insert correct parameter sets before IRAP
On Tue, 26. Nov 07:24, Andriy Gelman wrote:
> On Tue, 26. Nov 10:52, Michael Niedermayer wrote:
> > On Mon, Nov 25, 2019 at 09:35:04PM -0500, Andriy Gelman wrote:
> > > On Mon, 25. Nov 01:50, Michael Niedermayer wrote:
> > > > On Sun, Nov 24, 2019 at 11:29:18AM -0500, Andriy Gelman wrote:
> > > > > On Sun, 24. Nov 00:02, Michael Niedermayer wrote:
> > > > > > On Tue, Oct 15, 2019 at 10:50:39PM -0400, Andriy Gelman wrote:
> > > > > > > From: Andriy Gelman
> > > > > > >
> > > > > > > Fixes #7799
> > > > > > >
> > > > > > > Currently, the mp4toannexb filter always inserts the same
> > > > > > > extradata at
> > > > > > > the start of the first IRAP unit. As in ticket #7799, this can
> > > > > > > lead to
> > > > > > > decoding errors if modified parameter sets are signalled in-band.
> > > > > > >
> > > > > > > Decoding errors/visual artifacts are also present in the
> > > > > > > following fate-suite/hevc-conformance datasets for
> > > > > > > hevc->mp4->hevc conversion:
> > > > > > > -RAP_B_Bossen_1.bit
> > > > > > > -RPS_C_ericsson_5.bit
> > > > > > > -SLIST_A_Sony_4.bit
> > > > > > > -SLIST_B_Sony_8.bit
> > > > > > > -SLIST_C_Sony_3.bit
> > > > > > > -SLIST_D_Sony_9.bit
> > > > > > > -TSKIP_A_MS_2.bit
> > > > > > >
> > > > > > > This commit solves these errors by keeping track of VPS/SPS/PPS
> > > > > > > parameter sets
> > > > > > > during the conversion. The correct combination is inserted at the
> > > > > > > start
> > > > > > > of the first IRAP. SEIs from extradata are inserted before each
> > > > > > > IRAP.
> > > > > > >
> > > > > > > This commit also makes an update to the hevc-bsf-mp4toannexb fate
> > > > > > > test
> > > > > > > since the result before this patch contained duplicate parameter
> > > > > > > sets
> > > > > > > in-band.
> > > > > > > ---
> > > > > > > libavcodec/hevc_mp4toannexb_bsf.c | 503
> > > > > > > --
> > > > > > > tests/fate/hevc.mak | 2 +-
> > > > > > > 2 files changed, 472 insertions(+), 33 deletions(-)
> > > > [...]
> > > > > >
> > > > > > [...]
> > > > > > > +/*
> > > > > > > + * Function converts mp4 access unit into annexb
> > > > > > > + * Output packet structure
> > > > > > > + * VPS, SPS, PPS, [SEI(from extradata)], [SEI_PREFIX(from access
> > > > > > > unit)], IRAP, [SEI_SUFFIX]
> > > > > > > + * or
> > > > > > > + * [SEI_PREFIX (from access unit)], [PPS (if not already
> > > > > > > signalled)], VCL(non-irap), [SEI_SUFFIX]
> > > > > > > + */
> > > > > > > static int hevc_mp4toannexb_filter(AVBSFContext *ctx, AVPacket
> > > > > > > *out)
> > > > > > > {
> > > > > > > HEVCBSFContext *s = ctx->priv_data;
> > > > > > > AVPacket *in;
> > > > > > > -GetByteContext gb;
> > > > > > > -
> > > > > > > -int got_irap = 0;
> > > > > > > -int i, ret = 0;
> > > > > > > +H2645Packet pkt;
> > > > > > > +int i, j, prev_size, ret;
> > > > > > > +int irap_done;
> > > > > > >
> > > > > > > ret = ff_bsf_get_packet(ctx, &in);
> > > > > > > if (ret < 0)
> > > > > > > return ret;
> > > > > > >
> > > > > > > +/* output the annexb nalu if extradata is not parsed*/
> > > > > > > if (!s->extradata_parsed) {
> > > > > > > av_packet_move_ref(out, in);
> > > > > > > av_packet_free(&in);
> > > > > > > return 0;
> > > > > > > }
> > > > > > >
> > > > > >
> > > > > > > -bytestream2_init(&gb, in->data, in->size);
> > > > > >
> > > > > > Is this really better without using an existing bytestream* API ?
> > > > >
> > > > > If I use the API, then I'd have to call bytestraem2_init for each nal
> > > > > unit. I
> > > > > also don't use the bytestream2_get_byte function. It seemed simpler
> > > > > to use the WRITE_NAL macro.
> > > > >
> > > > > But maybe I've misunderstood your question.
> > > >
> > > > i had nothing really specific in mind, just the feeling that using none
> > > > of
> > > > the existing APIs there is a bit odd.
> > > >
> > > > but more specifically, what about the write side ?
> > >
> > > If I use the bytestream* API, then I'd have to add extra boiler plate
> > > code each time I resize the output with av_grow_packet(). I'd have to add
> > > something like:
> > >
> > > prev_size = bytestream2_tell_p(...);
> > > bytestream2_init_writer(...);
> > > bytestream2_skip_p(..., prev_size);
> > >
> > > Or maybe the API needs an extra function that reinitializes the pointers
> > > but
> > > keeps the current state of the writer.
> >
> > grow/realloc seems suboptimal to me for any API.
> > cant you find out how much space is needed and allocate/grow just once then
> > init the bytestream2 on that ?
> >
>
> ok, I'll do it this way.
>
After spending so much time on this patch I've just discovered that the
hevc_metadata bsf can do the same job as hevc_mp4toannexb. The former also
inserts correct parameter sets and so fixes #7799... :(
So instead of:
./ffmpeg -i in.mp4 -bsf:v hevc_mp4t
Re: [FFmpeg-devel] [PATCH v6 1/3] hevc_mp4toannexb: Insert correct parameter sets before IRAP
Andriy Gelman:
> On Tue, 26. Nov 07:24, Andriy Gelman wrote:
>> On Tue, 26. Nov 10:52, Michael Niedermayer wrote:
>>> On Mon, Nov 25, 2019 at 09:35:04PM -0500, Andriy Gelman wrote:
On Mon, 25. Nov 01:50, Michael Niedermayer wrote:
> On Sun, Nov 24, 2019 at 11:29:18AM -0500, Andriy Gelman wrote:
>> On Sun, 24. Nov 00:02, Michael Niedermayer wrote:
>>> On Tue, Oct 15, 2019 at 10:50:39PM -0400, Andriy Gelman wrote:
From: Andriy Gelman
Fixes #7799
Currently, the mp4toannexb filter always inserts the same extradata at
the start of the first IRAP unit. As in ticket #7799, this can lead to
decoding errors if modified parameter sets are signalled in-band.
Decoding errors/visual artifacts are also present in the following
fate-suite/hevc-conformance datasets for hevc->mp4->hevc conversion:
-RAP_B_Bossen_1.bit
-RPS_C_ericsson_5.bit
-SLIST_A_Sony_4.bit
-SLIST_B_Sony_8.bit
-SLIST_C_Sony_3.bit
-SLIST_D_Sony_9.bit
-TSKIP_A_MS_2.bit
This commit solves these errors by keeping track of VPS/SPS/PPS
parameter sets
during the conversion. The correct combination is inserted at the start
of the first IRAP. SEIs from extradata are inserted before each IRAP.
This commit also makes an update to the hevc-bsf-mp4toannexb fate test
since the result before this patch contained duplicate parameter sets
in-band.
---
libavcodec/hevc_mp4toannexb_bsf.c | 503 --
tests/fate/hevc.mak | 2 +-
2 files changed, 472 insertions(+), 33 deletions(-)
> [...]
>>>
>>> [...]
+/*
+ * Function converts mp4 access unit into annexb
+ * Output packet structure
+ * VPS, SPS, PPS, [SEI(from extradata)], [SEI_PREFIX(from access
unit)], IRAP, [SEI_SUFFIX]
+ * or
+ * [SEI_PREFIX (from access unit)], [PPS (if not already signalled)],
VCL(non-irap), [SEI_SUFFIX]
+ */
static int hevc_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *out)
{
HEVCBSFContext *s = ctx->priv_data;
AVPacket *in;
-GetByteContext gb;
-
-int got_irap = 0;
-int i, ret = 0;
+H2645Packet pkt;
+int i, j, prev_size, ret;
+int irap_done;
ret = ff_bsf_get_packet(ctx, &in);
if (ret < 0)
return ret;
+/* output the annexb nalu if extradata is not parsed*/
if (!s->extradata_parsed) {
av_packet_move_ref(out, in);
av_packet_free(&in);
return 0;
}
>>>
-bytestream2_init(&gb, in->data, in->size);
>>>
>>> Is this really better without using an existing bytestream* API ?
>>
>> If I use the API, then I'd have to call bytestraem2_init for each nal
>> unit. I
>> also don't use the bytestream2_get_byte function. It seemed simpler to
>> use the WRITE_NAL macro.
>>
>> But maybe I've misunderstood your question.
>
> i had nothing really specific in mind, just the feeling that using none of
> the existing APIs there is a bit odd.
>
> but more specifically, what about the write side ?
If I use the bytestream* API, then I'd have to add extra boiler plate code
each time I resize the output with av_grow_packet(). I'd have to add
something like:
prev_size = bytestream2_tell_p(...);
bytestream2_init_writer(...);
bytestream2_skip_p(..., prev_size);
Or maybe the API needs an extra function that reinitializes the pointers
but
keeps the current state of the writer.
>>>
>>> grow/realloc seems suboptimal to me for any API.
>>> cant you find out how much space is needed and allocate/grow just once then
>>> init the bytestream2 on that ?
>>>
>>
>> ok, I'll do it this way.
>>
>
> After spending so much time on this patch I've just discovered that the
> hevc_metadata bsf can do the same job as hevc_mp4toannexb. The former also
> inserts correct parameter sets and so fixes #7799... :(
>
> So instead of:
> ./ffmpeg -i in.mp4 -bsf:v hevc_mp4toannexb -codec:v copy out.hevc
>
> The user can just run:
> ./ffmpeg -i in.mp4 -bsf:v hevc_metadata -codec:v copy out.hevc
>
> One difference is that hevc_metadata currently only keeps the base layers
> (nuh_layer_id == 0), whereas hevc_mp4toannexb copies everything (before my
> patch). hevc_metadata will have a slightly higher complexity as it parses the
> full
> parameter sets.
>
> Can you give me advice on best way to proceed?
>
> If the nuh_layer_id issue is solved, can we remove the hevc_mp4toannexb f
Re: [FFmpeg-devel] [PATCH v6 1/3] hevc_mp4toannexb: Insert correct parameter sets before IRAP
On Thu, 28. Nov 15:28, Andreas Rheinhardt wrote:
> Andriy Gelman:
> > On Tue, 26. Nov 07:24, Andriy Gelman wrote:
> >> On Tue, 26. Nov 10:52, Michael Niedermayer wrote:
> >>> On Mon, Nov 25, 2019 at 09:35:04PM -0500, Andriy Gelman wrote:
> On Mon, 25. Nov 01:50, Michael Niedermayer wrote:
> > On Sun, Nov 24, 2019 at 11:29:18AM -0500, Andriy Gelman wrote:
> >> On Sun, 24. Nov 00:02, Michael Niedermayer wrote:
> >>> On Tue, Oct 15, 2019 at 10:50:39PM -0400, Andriy Gelman wrote:
> From: Andriy Gelman
>
> Fixes #7799
>
> Currently, the mp4toannexb filter always inserts the same extradata
> at
> the start of the first IRAP unit. As in ticket #7799, this can lead
> to
> decoding errors if modified parameter sets are signalled in-band.
>
> Decoding errors/visual artifacts are also present in the following
> fate-suite/hevc-conformance datasets for hevc->mp4->hevc conversion:
> -RAP_B_Bossen_1.bit
> -RPS_C_ericsson_5.bit
> -SLIST_A_Sony_4.bit
> -SLIST_B_Sony_8.bit
> -SLIST_C_Sony_3.bit
> -SLIST_D_Sony_9.bit
> -TSKIP_A_MS_2.bit
>
> This commit solves these errors by keeping track of VPS/SPS/PPS
> parameter sets
> during the conversion. The correct combination is inserted at the
> start
> of the first IRAP. SEIs from extradata are inserted before each IRAP.
>
> This commit also makes an update to the hevc-bsf-mp4toannexb fate
> test
> since the result before this patch contained duplicate parameter sets
> in-band.
> ---
> libavcodec/hevc_mp4toannexb_bsf.c | 503
> --
> tests/fate/hevc.mak | 2 +-
> 2 files changed, 472 insertions(+), 33 deletions(-)
> > [...]
> >>>
> >>> [...]
> +/*
> + * Function converts mp4 access unit into annexb
> + * Output packet structure
> + * VPS, SPS, PPS, [SEI(from extradata)], [SEI_PREFIX(from access
> unit)], IRAP, [SEI_SUFFIX]
> + * or
> + * [SEI_PREFIX (from access unit)], [PPS (if not already
> signalled)], VCL(non-irap), [SEI_SUFFIX]
> + */
> static int hevc_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *out)
> {
> HEVCBSFContext *s = ctx->priv_data;
> AVPacket *in;
> -GetByteContext gb;
> -
> -int got_irap = 0;
> -int i, ret = 0;
> +H2645Packet pkt;
> +int i, j, prev_size, ret;
> +int irap_done;
>
> ret = ff_bsf_get_packet(ctx, &in);
> if (ret < 0)
> return ret;
>
> +/* output the annexb nalu if extradata is not parsed*/
> if (!s->extradata_parsed) {
> av_packet_move_ref(out, in);
> av_packet_free(&in);
> return 0;
> }
>
> >>>
> -bytestream2_init(&gb, in->data, in->size);
> >>>
> >>> Is this really better without using an existing bytestream* API ?
> >>
> >> If I use the API, then I'd have to call bytestraem2_init for each nal
> >> unit. I
> >> also don't use the bytestream2_get_byte function. It seemed simpler to
> >> use the WRITE_NAL macro.
> >>
> >> But maybe I've misunderstood your question.
> >
> > i had nothing really specific in mind, just the feeling that using none
> > of
> > the existing APIs there is a bit odd.
> >
> > but more specifically, what about the write side ?
>
> If I use the bytestream* API, then I'd have to add extra boiler plate
> code each time I resize the output with av_grow_packet(). I'd have to
> add something like:
>
> prev_size = bytestream2_tell_p(...);
> bytestream2_init_writer(...);
> bytestream2_skip_p(..., prev_size);
>
> Or maybe the API needs an extra function that reinitializes the pointers
> but
> keeps the current state of the writer.
> >>>
> >>> grow/realloc seems suboptimal to me for any API.
> >>> cant you find out how much space is needed and allocate/grow just once
> >>> then
> >>> init the bytestream2 on that ?
> >>>
> >>
> >> ok, I'll do it this way.
> >>
> >
> > After spending so much time on this patch I've just discovered that the
> > hevc_metadata bsf can do the same job as hevc_mp4toannexb. The former also
> > inserts correct parameter sets and so fixes #7799... :(
> >
> > So instead of:
> > ./ffmpeg -i in.mp4 -bsf:v hevc_mp4toannexb -codec:v copy out.hevc
> >
> > The user can just run:
> > ./ffmpeg -i in.mp4 -bsf:v hevc_metadata -codec:v copy out.hevc
> >
> > One difference is tha
Re: [FFmpeg-devel] [PATCH 1/7] avformat/aviobuf: Avoid allocating buffer when using dynamic buffer
On 11/27/2019 9:22 AM, Andreas Rheinhardt wrote: > Up until now, using a dynamic buffer entailed at least three > allocations: One for the AVIOContext, one for the AVIOContext's opaque > (which, among other things, contains the small write buffer), and one > for the big buffer that is independently allocated that is returned when > calling avio_close_dyn_buf(). > > It is possible to avoid the third allocation if one doesn't use a > packetized dynamic buffer, if all the data written so far fit into the > write buffer and if one does not require the actual (big) buffer to have > an indefinite lifetime. This is done by making avio_get_dyn_buf() return > a pointer to the data in the write buffer if nothing has been written to > the main buffer yet. The dynamic buffer will then be freed using > ffio_free_dynamic_buffer (which needed to be modified not to call > avio_close_dyn_buf() internally). > > So a typical use-case like: > > size = avio_close_dyn_buf(dyn_pb, &buf); > do something with buf > av_free(buf); > > can be converted to: > > size = avio_get_dyn_buf(dyn_pb, &buf); > do something with buf > ffio_free_dynamic_buffer(&dyn_pb); > > In more complex scenarios this can simplify freeing as well, because it > is now clear that freeing always has to be performed via > ffio_free_dynamic_buffer(). > > Of course, in case this saves an allocation it also saves a memcpy. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/aviobuf.c | 20 ++-- > 1 file changed, 14 insertions(+), 6 deletions(-) Patchset applied. ___ 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/avc: write the missing bits in the AVC Decoder Configuration Box
On 11/27/2019 9:26 AM, James Almer wrote:
> On 11/26/2019 10:57 AM, Andreas Rheinhardt wrote:
>> On Tue, Nov 26, 2019 at 2:07 PM James Almer wrote:
>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavformat/avc.c | 38 +-
>>> libavformat/avc.h | 1 +
>>> 2 files changed, 34 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/libavformat/avc.c b/libavformat/avc.c
>>> index a041e84357..9bd215c07f 100644
>>> --- a/libavformat/avc.c
>>> +++ b/libavformat/avc.c
>>> @@ -107,11 +107,11 @@ int ff_avc_parse_nal_units_buf(const uint8_t
>>> *buf_in, uint8_t **buf, int *size)
>>>
>>> int ff_isom_write_avcc(AVIOContext *pb, const uint8_t *data, int len)
>>> {
>>> -AVIOContext *sps_pb = NULL, *pps_pb = NULL;
>>> +AVIOContext *sps_pb = NULL, *pps_pb = NULL, *sps_ext_pb = NULL;
>>> uint8_t *buf = NULL, *end, *start = NULL;
>>> -uint8_t *sps = NULL, *pps = NULL;
>>> -uint32_t sps_size = 0, pps_size = 0;
>>> -int ret, nb_sps = 0, nb_pps = 0;
>>> +uint8_t *sps = NULL, *pps = NULL, *sps_ext = NULL;
>>> +uint32_t sps_size = 0, pps_size = 0, sps_ext_size = 0;
>>> +int ret, nb_sps = 0, nb_pps = 0, nb_sps_ext = 0;
>>>
>>> if (len <= 6)
>>> return AVERROR_INVALIDDATA;
>>> @@ -133,6 +133,9 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
>>> *data, int len)
>>> if (ret < 0)
>>> goto fail;
>>> ret = avio_open_dyn_buf(&pps_pb);
>>> +if (ret < 0)
>>> +goto fail;
>>> +ret = avio_open_dyn_buf(&sps_ext_pb);
>>> if (ret < 0)
>>> goto fail;
>>>
>>> @@ -160,12 +163,21 @@ int ff_isom_write_avcc(AVIOContext *pb, const
>>> uint8_t *data, int len)
>>> }
>>> avio_wb16(pps_pb, size);
>>> avio_write(pps_pb, buf, size);
>>> +} else if (nal_type == 13) { /* SPS_EXT */
>>> +nb_sps_ext++;
>>> +if (size > UINT16_MAX || nb_sps_ext >= 256) {
>>> +ret = AVERROR_INVALIDDATA;
>>> +goto fail;
>>> +}
>>> +avio_wb16(sps_ext_pb, size);
>>> +avio_write(sps_ext_pb, buf, size);
>>> }
>>>
>>> buf += size;
>>> }
>>> sps_size = avio_close_dyn_buf(sps_pb, &sps);
>>> pps_size = avio_close_dyn_buf(pps_pb, &pps);
>>> +sps_ext_size = avio_close_dyn_buf(sps_ext_pb, &sps_ext);
>>>
>>> if (sps_size < 6 || !pps_size) {
>>> ret = AVERROR_INVALIDDATA;
>>> @@ -183,13 +195,29 @@ int ff_isom_write_avcc(AVIOContext *pb, const
>>> uint8_t *data, int len)
>>> avio_w8(pb, nb_pps); /* number of pps */
>>> avio_write(pb, pps, pps_size);
>>>
>>> +if (sps[3] != 66 && sps[3] != 77 && sps[3] != 88) {
>>> +H264SequenceParameterSet *seq = ff_avc_decode_sps(sps, sps_size);
>>> +if (!seq)
>>> +goto fail;
>>> +avio_w8(pb, 0xfc | seq->chroma_format_idc); /* 6 bits reserved
>>> (11) + chroma_format_idc */
>>> +avio_w8(pb, 0xf8 | seq->bit_depth_luma - 8); /* 5 bits reserved
>>> (1) + bit_depth_luma_minus8 */
>>> +avio_w8(pb, 0xf8 | seq->bit_depth_chroma - 8); /* 5 bits reserved
>>> (1) + bit_depth_chroma_minus8 */
>>> +avio_w8(pb, nb_sps_ext); /* number of sps ext */
>>> +if (nb_sps_ext)
>>> +avio_write(pb, sps_ext, sps_ext_size);
>>> +av_free(seq);
>>> +}
>>> +
>>> fail:
>>> if (!sps)
>>> avio_close_dyn_buf(sps_pb, &sps);
>>> if (!pps)
>>> avio_close_dyn_buf(pps_pb, &pps);
>>> +if (!sps_ext)
>>> +avio_close_dyn_buf(sps_ext_pb, &sps_ext);
>>>
>>
>> I don't like how these buffers are freed. How about the following approach:
>> You don't close the dynamic buffer above; instead you just call
>> avio_get_dyn_buf(). And here on fail you use ffio_free_dyn_buf()
>> unconditionally instead of these combinations of avio_close_dyn_buf() and
>> av_free().
>
> Ok, will change that and apply this soon.
Changed and applied.
___
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 v6 1/3] hevc_mp4toannexb: Insert correct parameter sets before IRAP
Andriy Gelman:
> On Thu, 28. Nov 15:28, Andreas Rheinhardt wrote:
>> Andriy Gelman:
>>> On Tue, 26. Nov 07:24, Andriy Gelman wrote:
On Tue, 26. Nov 10:52, Michael Niedermayer wrote:
> On Mon, Nov 25, 2019 at 09:35:04PM -0500, Andriy Gelman wrote:
>> On Mon, 25. Nov 01:50, Michael Niedermayer wrote:
>>> On Sun, Nov 24, 2019 at 11:29:18AM -0500, Andriy Gelman wrote:
On Sun, 24. Nov 00:02, Michael Niedermayer wrote:
> On Tue, Oct 15, 2019 at 10:50:39PM -0400, Andriy Gelman wrote:
>> From: Andriy Gelman
>>
>> Fixes #7799
>>
>> Currently, the mp4toannexb filter always inserts the same extradata
>> at
>> the start of the first IRAP unit. As in ticket #7799, this can lead
>> to
>> decoding errors if modified parameter sets are signalled in-band.
>>
>> Decoding errors/visual artifacts are also present in the following
>> fate-suite/hevc-conformance datasets for hevc->mp4->hevc conversion:
>> -RAP_B_Bossen_1.bit
>> -RPS_C_ericsson_5.bit
>> -SLIST_A_Sony_4.bit
>> -SLIST_B_Sony_8.bit
>> -SLIST_C_Sony_3.bit
>> -SLIST_D_Sony_9.bit
>> -TSKIP_A_MS_2.bit
>>
>> This commit solves these errors by keeping track of VPS/SPS/PPS
>> parameter sets
>> during the conversion. The correct combination is inserted at the
>> start
>> of the first IRAP. SEIs from extradata are inserted before each IRAP.
>>
>> This commit also makes an update to the hevc-bsf-mp4toannexb fate
>> test
>> since the result before this patch contained duplicate parameter sets
>> in-band.
>> ---
>> libavcodec/hevc_mp4toannexb_bsf.c | 503
>> --
>> tests/fate/hevc.mak | 2 +-
>> 2 files changed, 472 insertions(+), 33 deletions(-)
>>> [...]
>
> [...]
>> +/*
>> + * Function converts mp4 access unit into annexb
>> + * Output packet structure
>> + * VPS, SPS, PPS, [SEI(from extradata)], [SEI_PREFIX(from access
>> unit)], IRAP, [SEI_SUFFIX]
>> + * or
>> + * [SEI_PREFIX (from access unit)], [PPS (if not already
>> signalled)], VCL(non-irap), [SEI_SUFFIX]
>> + */
>> static int hevc_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *out)
>> {
>> HEVCBSFContext *s = ctx->priv_data;
>> AVPacket *in;
>> -GetByteContext gb;
>> -
>> -int got_irap = 0;
>> -int i, ret = 0;
>> +H2645Packet pkt;
>> +int i, j, prev_size, ret;
>> +int irap_done;
>>
>> ret = ff_bsf_get_packet(ctx, &in);
>> if (ret < 0)
>> return ret;
>>
>> +/* output the annexb nalu if extradata is not parsed*/
>> if (!s->extradata_parsed) {
>> av_packet_move_ref(out, in);
>> av_packet_free(&in);
>> return 0;
>> }
>>
>
>> -bytestream2_init(&gb, in->data, in->size);
>
> Is this really better without using an existing bytestream* API ?
If I use the API, then I'd have to call bytestraem2_init for each nal
unit. I
also don't use the bytestream2_get_byte function. It seemed simpler to
use the WRITE_NAL macro.
But maybe I've misunderstood your question.
>>>
>>> i had nothing really specific in mind, just the feeling that using none
>>> of
>>> the existing APIs there is a bit odd.
>>>
>>> but more specifically, what about the write side ?
>>
>> If I use the bytestream* API, then I'd have to add extra boiler plate
>> code each time I resize the output with av_grow_packet(). I'd have to
>> add something like:
>>
>> prev_size = bytestream2_tell_p(...);
>> bytestream2_init_writer(...);
>> bytestream2_skip_p(..., prev_size);
>>
>> Or maybe the API needs an extra function that reinitializes the pointers
>> but
>> keeps the current state of the writer.
>
> grow/realloc seems suboptimal to me for any API.
> cant you find out how much space is needed and allocate/grow just once
> then
> init the bytestream2 on that ?
>
ok, I'll do it this way.
>>>
>>> After spending so much time on this patch I've just discovered that the
>>> hevc_metadata bsf can do the same job as hevc_mp4toannexb. The former also
>>> inserts correct parameter sets and so fixes #7799... :(
>>>
>>> So instead of:
>>> ./ffmpeg -i in.mp4 -bsf:v hevc_mp4toannexb -codec:v copy out.hevc
>>>
>>> The user can just run:
>>> ./ffmpeg -i in.mp4 -bsf:v hevc_metadata -codec:v copy out.hevc
>>>
>>> One dif
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: remove duplicate code block
On Thu, Nov 28, 2019 at 11:26:24AM +0800, Steven Liu wrote: > > > > 在 2019年11月28日，04:06，Michael Niedermayer 写道： > > > > mm-short.mpg > Hi Michael, > > Where should i download the file mm-short.mpg? you can make it yourself, it is just: dd if=matrixbench_mpeg2.mpg of=mm-short.mpg count=4000 db7c44ab3d2b75d6e61fe61b1a595b31 mm-short.mpg [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. 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/2] libswscale/x86/yuv2rgb: add ssse3 version
On Thu, Nov 28, 2019 at 02:07:08PM +0800, Ting Fu wrote: > Signed-off-by: Ting Fu > --- > libswscale/x86/yuv2rgb.c | 5 + > libswscale/x86/yuv2rgb_template.c | 58 ++- > libswscale/x86/yuv_2_rgb.asm | 163 +++--- > 3 files changed, 208 insertions(+), 18 deletions(-) breaks build on x86-32 make X86ASM libswscale/x86/yuv_2_rgb.o src/libswscale/x86/yuv_2_rgb.asm:400: error: parser: instruction expected src/libswscale/x86/yuv_2_rgb.asm:331: ... from macro `yuv2rgb_fn' defined here src/libswscale/x86/yuv_2_rgb.asm:400: error: parser: instruction expected src/libswscale/x86/yuv_2_rgb.asm:332: ... from macro `yuv2rgb_fn' defined here src/libswscale/x86/yuv_2_rgb.asm:400: error: parser: instruction expected src/libswscale/x86/yuv_2_rgb.asm:333: ... from macro `yuv2rgb_fn' defined here src/libswscale/x86/yuv_2_rgb.asm:401: error: label `BROADCAST' inconsistently redefined src/libswscale/x86/yuv_2_rgb.asm:331: ... from macro `yuv2rgb_fn' defined here src/libswscale/x86/yuv_2_rgb.asm:400: note: label `BROADCAST' originally defined here src/libswscale/x86/yuv_2_rgb.asm:331: ... from macro `yuv2rgb_fn' defined here src/libswscale/x86/yuv_2_rgb.asm:401: error: parser: instruction expected src/libswscale/x86/yuv_2_rgb.asm:331: ... from macro `yuv2rgb_fn' defined here src/libswscale/x86/yuv_2_rgb.asm:401: error: parser: instruction expected src/libswscale/x86/yuv_2_rgb.asm:332: ... from macro `yuv2rgb_fn' defined here src/libswscale/x86/yuv_2_rgb.asm:401: error: parser: instruction expected src/libswscale/x86/yuv_2_rgb.asm:333: ... from macro `yuv2rgb_fn' defined here make: *** [libswscale/x86/yuv_2_rgb.o] Error [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire 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 03/23] avformat/matroskaenc: Use random TrackUID
Carl Eugen Hoyos: > Am Mi., 27. Nov. 2019 um 17:58 Uhr schrieb Andreas Rheinhardt > : > >> I consider this only a slight disadvantage: E.g. the streamhash or the >> framehash muxers would provide easy ways to examine whether the actual >> content of the files (besides the UIDs) are different. > > But that wouldn't show changes in the output of the muxer. > True. But given that this muxer has already written some random data when not in bitexact mode (namely the SegmentUID as well as the FileUID of attachments) for more than nine years I wonder how much this has hindered finding bugs. - Andreas ___ 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 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
On Thu, Nov 28, 2019 at 02:07:07PM +0800, Ting Fu wrote: > Signed-off-by: Ting Fu > --- > libswscale/x86/Makefile | 1 + > libswscale/x86/swscale.c | 16 +- > libswscale/x86/yuv2rgb.c | 81 ++ > libswscale/x86/yuv2rgb_template.c | 441 ++ > libswscale/x86/yuv_2_rgb.asm | 270 ++ > 5 files changed, 394 insertions(+), 415 deletions(-) > create mode 100644 libswscale/x86/yuv_2_rgb.asm This changes the output, i presume that is unintentional ./ffmpeg -cpuflags 0 -i matrixbench_mpeg2.mpg -t 1 -vf format=yuv420p,format=rgb565le -an -f framecrc - 0, 0, 0,1, 829440, 0x1bd78b86 0, 1, 1,1, 829440, 0x85910b33 ... vs. 0, 0, 0,1, 829440, 0x31f4a2bd 0, 1, 1,1, 829440, 0xf0c66218 ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- 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 v2] avfilter/vf_showinfo: Fix erroneous results for mean and stdev with pixel bits >8
On Thu, Nov 28, 2019 at 10:34:41PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > The following is one of the testing results, you can observe the result of > 16bit isn't correct. > 1, yuv420p > ./ffmpeg -f lavfi -i > color=black:duration=1:r=1:size=1280x720,format=yuv420p,showinfo > Master: > mean:[16 128 128] stdev:[0.0 0.0 0.0] > After applied the patch: > mean:[16 128 128] stdev:[0.0 0.0 0.0] > > 2, yuv420p10 > ./ffmpeg -f lavfi -i > color=black:duration=1:r=1:size=1280x720,format=yuv420p10,showinfo > Master: > mean:[32 1 1] stdev:[32.0 1.0 1.0] > After applied the patch: > mean:[64 512 512] stdev:[0.0 0.0 0.0] with >8bit, both little and big endian formats should be tested thx [...] -- 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 v2 1/3] avfilter/vf_yadif: rename config_props -> config_output, link -> outlink
On Thu, Nov 28, 2019 at 09:41:15AM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > Sorry, fix the title typo > > libavfilter/vf_yadif.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch 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/vividas: Avoid allocation of AVIOContext
On Thu, Nov 28, 2019 at 03:31:33PM +0100, Andreas Rheinhardt wrote: > Put an AVIOContext whose lifetime doesn't extend beyond the function where > it is allocated on the stack instead of allocating and freeing it. This > also avoids the need to free it, which in this case fixes possible > memleaks on error. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/vividas.c | 19 --- > 1 file changed, 4 insertions(+), 15 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus 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 1/3] lavf/vividas: check avformat_new_stream() return
On Thu, Nov 28, 2019 at 09:40:58PM +0800, Jun Zhao wrote: > From: Jun Zhao > > check avformat_new_stream() return. > > Signed-off-by: Jun Zhao > --- > libavformat/vividas.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire 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: remove duplicate code block
> 在 2019年11月29日，上午2:48，Michael Niedermayer 写道： > > On Thu, Nov 28, 2019 at 11:26:24AM +0800, Steven Liu wrote: >> >> >>> 在 2019年11月28日，04:06，Michael Niedermayer 写道： >>> >>> mm-short.mpg >> Hi Michael, >> >> Where should i download the file mm-short.mpg? > > you can make it yourself, it is just: > > dd if=matrixbench_mpeg2.mpg of=mm-short.mpg count=4000 StevenLiu:dash StevenLiu$ find fate-suite -name matrixbench_mpeg2.mpg StevenLiu:dash StevenLiu$ There have no file named matrixbench_mpeg2.mpg, I ask for the mpg file for: i want to know what contents of the mpg file, just video stream? audio stream? or other stream? Whatever, i will resubmit a new version patch, try to fix this problem. > > db7c44ab3d2b75d6e61fe61b1a595b31 mm-short.mpg > Thanks Steven ___ 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: remove duplicate code block
Am Fr., 29. Nov. 2019 um 00:43 Uhr schrieb Liu Steven : > > > > > 在 2019年11月29日，上午2:48，Michael Niedermayer 写道： > > > > On Thu, Nov 28, 2019 at 11:26:24AM +0800, Steven Liu wrote: > >> > >> > >>> 在 2019年11月28日，04:06，Michael Niedermayer 写道： > >>> > >>> mm-short.mpg > >> Hi Michael, > >> > >> Where should i download the file mm-short.mpg? > > > > you can make it yourself, it is just: > > > > dd if=matrixbench_mpeg2.mpg of=mm-short.mpg count=4000 > > StevenLiu:dash StevenLiu$ find fate-suite -name matrixbench_mpeg2.mpg https://samples.ffmpeg.org/benchmark/testsuite1/ 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] avformat/utils.c: allows av_read_frame to return after a timeout period.
From: Gonzalo Garramuño
Moved the check inside if (pktl) as per Michael Niedermayer's suggestion.
This patch is based on one from bsenftner at earthlink.net.
---
libavformat/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..1f5754d7d3 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1795,6 +1795,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
AVPacketList *pktl = s->internal->packet_buffer;
if (pktl) {
+if (ff_check_interrupt(&s->interrupt_callback)) {
+av_log(s, AV_LOG_DEBUG, "interrupted\n");
+return AVERROR_EXIT;
+}
+
AVPacket *next_pkt = &pktl->pkt;
if (next_pkt->dts != AV_NOPTS_VALUE) {
--
2.17.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 1/3] lavf/vividas: check avformat_new_stream() return
On Thu, Nov 28, 2019 at 10:37 PM Andreas Rheinhardt
wrote:
>
> Jun Zhao:
> > From: Jun Zhao
> >
> > check avformat_new_stream() return.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/vividas.c |4
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/libavformat/vividas.c b/libavformat/vividas.c
> > index f20af3d..16642c0 100644
> > --- a/libavformat/vividas.c
> > +++ b/libavformat/vividas.c
> > @@ -319,6 +319,8 @@ static int track_header(VividasDemuxContext *viv,
> > AVFormatContext *s, uint8_t *
> >
> > for (i = 0; i < num_video; i++) {
> > AVStream *st = avformat_new_stream(s, NULL);
> > +if (!st)
> > +return AVERROR(ENOMEM);
> >
> > st->id = i;
> >
> > @@ -352,6 +354,8 @@ static int track_header(VividasDemuxContext *viv,
> > AVFormatContext *s, uint8_t *
> > for(i=0;inum_audio;i++) {
> > int q;
> > AVStream *st = avformat_new_stream(s, NULL);
> > +if (!st)
> > +return AVERROR(ENOMEM);
> >
> > st->id = num_video + i;
> >
> >
> Actually, the AVIOContext pb leaks when these errors happen. But don't
> bother updating your patch, because pb should actually not be
> allocated at all: I'll send a patch using ffio_init_context soon.
>
I think you comments the other patch :), and Michael have applied your patch
___
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 1/3] lavf/vividas: check avformat_new_stream() return
On Fri, Nov 29, 2019 at 6:59 AM Michael Niedermayer wrote: > > On Thu, Nov 28, 2019 at 09:40:58PM +0800, Jun Zhao wrote: > > From: Jun Zhao > > > > check avformat_new_stream() return. > > > > Signed-off-by: Jun Zhao > > --- > > libavformat/vividas.c |4 > > 1 files changed, 4 insertions(+), 0 deletions(-) > > LGTM > > thx > Applied, thx ___ 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/cbs_h264: add support for the Content light level information SEI message
Defined in ITU-T H.264 (06/2019)
Signed-off-by: James Almer
---
This is basically a copy paste of the H.265 implementation, both here and in
the spec.
libavcodec/cbs_h264.h | 6 ++
libavcodec/cbs_h2645.c| 1 +
libavcodec/cbs_h264_syntax_template.c | 17 +
libavcodec/h264_sei.h | 1 +
4 files changed, 25 insertions(+)
diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index 9f7c2a0d30..f8e5b743be 100644
--- a/libavcodec/cbs_h264.h
+++ b/libavcodec/cbs_h264.h
@@ -314,6 +314,11 @@ typedef struct H264RawSEIMasteringDisplayColourVolume {
uint32_t min_display_mastering_luminance;
} H264RawSEIMasteringDisplayColourVolume;
+typedef struct H264RawSEIContentLightLevelInfo {
+uint16_t max_content_light_level;
+uint16_t max_pic_average_light_level;
+} H264RawSEIContentLightLevelInfo;
+
typedef struct H264RawSEIAlternativeTransferCharacteristics {
uint8_t preferred_transfer_characteristics;
} H264RawSEIAlternativeTransferCharacteristics;
@@ -331,6 +336,7 @@ typedef struct H264RawSEIPayload {
H264RawSEIRecoveryPoint recovery_point;
H264RawSEIDisplayOrientation display_orientation;
H264RawSEIMasteringDisplayColourVolume mastering_display_colour_volume;
+H264RawSEIContentLightLevelInfo content_light_level;
H264RawSEIAlternativeTransferCharacteristics
alternative_transfer_characteristics;
struct {
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 88fa0029cd..0944585fa8 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -458,6 +458,7 @@ static void cbs_h264_free_sei_payload(H264RawSEIPayload
*payload)
case H264_SEI_TYPE_PAN_SCAN_RECT:
case H264_SEI_TYPE_RECOVERY_POINT:
case H264_SEI_TYPE_DISPLAY_ORIENTATION:
+case H264_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
case H264_SEI_TYPE_ALTERNATIVE_TRANSFER:
break;
diff --git a/libavcodec/cbs_h264_syntax_template.c
b/libavcodec/cbs_h264_syntax_template.c
index 1671a15d33..62b40dfb42 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -819,6 +819,19 @@ static int
FUNC(sei_mastering_display_colour_volume)(CodedBitstreamContext *ctx,
return 0;
}
+static int FUNC(sei_content_light_level)(CodedBitstreamContext *ctx, RWContext
*rw,
+ H264RawSEIContentLightLevelInfo
*current)
+{
+int err;
+
+HEADER("Content Light Level");
+
+ub(16, max_content_light_level);
+ub(16, max_pic_average_light_level);
+
+return 0;
+}
+
static int
FUNC(sei_alternative_transfer_characteristics)(CodedBitstreamContext *ctx,
RWContext *rw,
H264RawSEIAlternativeTransferCharacteristics *current)
@@ -883,6 +896,10 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx,
RWContext *rw,
CHECK(FUNC(sei_mastering_display_colour_volume)
(ctx, rw, ¤t->payload.mastering_display_colour_volume));
break;
+case H264_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
+CHECK(FUNC(sei_content_light_level)
+ (ctx, rw, ¤t->payload.content_light_level));
+break;
case H264_SEI_TYPE_ALTERNATIVE_TRANSFER:
CHECK(FUNC(sei_alternative_transfer_characteristics)
(ctx, rw,
¤t->payload.alternative_transfer_characteristics));
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index a75c3aa175..ffd3948c5b 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -36,6 +36,7 @@ typedef enum {
H264_SEI_TYPE_DISPLAY_ORIENTATION= 47, ///< display orientation
H264_SEI_TYPE_GREEN_METADATA = 56, ///< GreenMPEG information
H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME = 137, ///< mastering
display properties
+H264_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO = 144, ///< content light level
information
H264_SEI_TYPE_ALTERNATIVE_TRANSFER = 147, ///< alternative transfer
} H264_SEI_Type;
--
2.24.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: remove duplicate code block
> -Original Message- > From: ffmpeg-devel On Behalf Of Liu > Steven > Sent: Friday, November 29, 2019 7:42 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Cc: Liu Steven > Subject: Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: remove duplicate > code block > > > > > 在 2019年11月29日，上午2:48，Michael Niedermayer > 写道： > > > > On Thu, Nov 28, 2019 at 11:26:24AM +0800, Steven Liu wrote: > >> > >> > >>> 在 2019年11月28日，04:06，Michael Niedermayer > 写道： > >>> > >>> mm-short.mpg > >> Hi Michael, > >> > >>Where should i download the file mm-short.mpg? > > > > you can make it yourself, it is just: > > > > dd if=matrixbench_mpeg2.mpg of=mm-short.mpg count=4000 > > StevenLiu:dash StevenLiu$ find fate-suite -name matrixbench_mpeg2.mpg > StevenLiu:dash StevenLiu$ > There have no file named matrixbench_mpeg2.mpg, > I ask for the mpg file for: i want to know what contents of the mpg file, just > video stream? audio stream? or other stream? https://samples.ffmpeg.org/benchmark/testsuite1/ > > > Whatever, i will resubmit a new version patch, try to fix this problem. > > > > > db7c44ab3d2b75d6e61fe61b1a595b31 mm-short.mpg > > > > Thanks > Steven > > > > ___ > 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/hlsenc: remove duplicate code block
> 在 2019年11月29日，07:55，Carl Eugen Hoyos 写道： > > Am Fr., 29. Nov. 2019 um 00:43 Uhr schrieb Liu Steven : >> >> >> >>> 在 2019年11月29日，上午2:48，Michael Niedermayer 写道： >>> >>> On Thu, Nov 28, 2019 at 11:26:24AM +0800, Steven Liu wrote: > 在 2019年11月28日，04:06，Michael Niedermayer 写道： > > mm-short.mpg Hi Michael, Where should i download the file mm-short.mpg? >>> >>> you can make it yourself, it is just: >>> >>> dd if=matrixbench_mpeg2.mpg of=mm-short.mpg count=4000 >> >> StevenLiu:dash StevenLiu$ find fate-suite -name matrixbench_mpeg2.mpg > > https://samples.ffmpeg.org/benchmark/testsuite1/ Thanks Carl :D > > 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". Thanks Steven ___ 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 v2] avformat/hlsenc: remove duplicate code block
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 043438368e..34ffab49a0 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2486,8 +2486,12 @@ static void hls_free_variant_streams(struct HLSContext
*hls)
if (vtt_oc) {
av_freep(&vs->vtt_basename);
av_freep(&vs->vtt_m3u8_name);
+avformat_free_context(vtt_oc);
}
+if (vs->avf)
+avformat_free_context(vs->avf);
+
hls_free_segments(vs->segments);
hls_free_segments(vs->old_segments);
av_freep(&vs->m3u8_name);
@@ -2619,7 +2623,6 @@ failed:
av_write_trailer(vtt_oc);
vs->size = avio_tell(vs->vtt_avf->pb) - vs->start_pos;
ff_format_io_close(s, &vtt_oc->pb);
-avformat_free_context(vtt_oc);
}
ret = hls_window(s, 1, vs);
if (ret < 0) {
@@ -2628,7 +2631,6 @@ failed:
hls_window(s, 1, vs);
}
ffio_free_dyn_buf(&oc->pb);
-avformat_free_context(oc);
vs->avf = NULL;
av_free(old_filename);
@@ -2956,31 +2958,14 @@ static int hls_init(AVFormatContext *s)
fail:
if (ret < 0) {
-av_freep(&hls->key_basename);
-for (i = 0; i < hls->nb_varstreams && hls->var_streams; i++) {
-vs = &hls->var_streams[i];
-av_freep(&vs->basename);
-av_freep(&vs->vtt_basename);
-av_freep(&vs->fmp4_init_filename);
-av_freep(&vs->m3u8_name);
-av_freep(&vs->vtt_m3u8_name);
-av_freep(&vs->streams);
-av_freep(&vs->language);
-av_freep(&vs->agroup);
-av_freep(&vs->ccgroup);
-av_freep(&vs->baseurl);
-av_freep(&vs->varname);
-if (vs->avf)
-avformat_free_context(vs->avf);
-if (vs->vtt_avf)
-avformat_free_context(vs->vtt_avf);
-}
+hls_free_variant_streams(hls);
for (i = 0; i < hls->nb_ccstreams; i++) {
ClosedCaptionsStream *ccs = &hls->cc_streams[i];
av_freep(&ccs->ccgroup);
av_freep(&ccs->instreamid);
av_freep(&ccs->language);
}
+av_freep(&hls->key_basename);
av_freep(&hls->var_streams);
av_freep(&hls->cc_streams);
av_freep(&hls->master_m3u8_url);
--
2.15.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 v2] avformat/hlsenc: remove duplicate code block
On Fri, Nov 29, 2019 at 12:46 PM Steven Liu wrote:
>
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 27 ++-
> 1 file changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 043438368e..34ffab49a0 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2486,8 +2486,12 @@ static void hls_free_variant_streams(struct HLSContext
> *hls)
> if (vtt_oc) {
> av_freep(&vs->vtt_basename);
> av_freep(&vs->vtt_m3u8_name);
> +avformat_free_context(vtt_oc);
> }
>
> +if (vs->avf)
> +avformat_free_context(vs->avf);
avformat_free_context can handle the NULL case, so don't need to check
the NULL before this call
> +
> hls_free_segments(vs->segments);
> hls_free_segments(vs->old_segments);
> av_freep(&vs->m3u8_name);
> @@ -2619,7 +2623,6 @@ failed:
> av_write_trailer(vtt_oc);
> vs->size = avio_tell(vs->vtt_avf->pb) - vs->start_pos;
> ff_format_io_close(s, &vtt_oc->pb);
> -avformat_free_context(vtt_oc);
> }
> ret = hls_window(s, 1, vs);
> if (ret < 0) {
> @@ -2628,7 +2631,6 @@ failed:
> hls_window(s, 1, vs);
> }
> ffio_free_dyn_buf(&oc->pb);
> -avformat_free_context(oc);
>
> vs->avf = NULL;
> av_free(old_filename);
> @@ -2956,31 +2958,14 @@ static int hls_init(AVFormatContext *s)
>
> fail:
> if (ret < 0) {
> -av_freep(&hls->key_basename);
> -for (i = 0; i < hls->nb_varstreams && hls->var_streams; i++) {
> -vs = &hls->var_streams[i];
> -av_freep(&vs->basename);
> -av_freep(&vs->vtt_basename);
> -av_freep(&vs->fmp4_init_filename);
> -av_freep(&vs->m3u8_name);
> -av_freep(&vs->vtt_m3u8_name);
> -av_freep(&vs->streams);
> -av_freep(&vs->language);
> -av_freep(&vs->agroup);
> -av_freep(&vs->ccgroup);
> -av_freep(&vs->baseurl);
> -av_freep(&vs->varname);
> -if (vs->avf)
> -avformat_free_context(vs->avf);
> -if (vs->vtt_avf)
> -avformat_free_context(vs->vtt_avf);
> -}
> +hls_free_variant_streams(hls);
> for (i = 0; i < hls->nb_ccstreams; i++) {
> ClosedCaptionsStream *ccs = &hls->cc_streams[i];
> av_freep(&ccs->ccgroup);
> av_freep(&ccs->instreamid);
> av_freep(&ccs->language);
> }
> +av_freep(&hls->key_basename);
> av_freep(&hls->var_streams);
> av_freep(&hls->cc_streams);
> av_freep(&hls->master_m3u8_url);
> --
> 2.15.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] lavc/qsvenc: add Tiles encode support for HEVC
On Tue, Nov 26, 2019 at 12:04 PM Linjie Fu wrote:
>
> Add -tile_rows and -tile_cols option to specify the number of tile rows
> and columns for ICL+ (gen 11) platform.
>
> A tile must wholly contain all the slices within it. Slices cannot cross
> tile boundaries. So the slice number would be implicitly resized to the
> max(nSlice, nTile).
>
> Example:
> ffmpeg -v verbose -hwaccel qsv -init_hw_device qsv=hw
> -filter_hw_device hw -f rawvideo -s:v 1920x1080 -i ./input.nv12 -vf
> format=nv12,hwupload=extra_hw_frames=64 -c:v hevc_qsv -tile_rows 2
> -tile_cols 2 -slices 4 -y output.h265
>
> Also dump the actual quantity of encoded tiled rows and columns in run
> time.
>
> Fix the enhancement #8400.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/qsvenc.c | 32 +++-
> libavcodec/qsvenc.h | 7 +++
> libavcodec/qsvenc_hevc.c | 3 +++
> 3 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index e176d57..64814fc 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -139,6 +139,9 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> #if QSV_HAVE_CO3
> mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
> #endif
> +#if QSV_HAVE_EXT_HEVC_TILES
> +mfxExtHEVCTiles *exthevctiles = (mfxExtHEVCTiles *)coding_opts[3 +
> QSV_HAVE_CO_VPS];
> +#endif
>
> av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> print_profile(info->CodecProfile), info->CodecLevel);
> @@ -204,6 +207,12 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
> print_threestate(co->RateDistortionOpt));
>
> +#if QSV_HAVE_EXT_HEVC_TILES
> +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> +av_log(avctx, AV_LOG_VERBOSE, "NumTileColumns: %"PRIu16";
> NumTileRows: %"PRIu16"\n",
> + exthevctiles->NumTileColumns, exthevctiles->NumTileRows);
> +#endif
> +
> #if QSV_HAVE_CO2
> av_log(avctx, AV_LOG_VERBOSE,
> "RecoveryPointSEI: %s IntRefType: %"PRIu16"; IntRefCycleSize:
> %"PRIu16"; IntRefQPDelta: %"PRId16"\n",
> @@ -771,6 +780,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
> }
> #endif
>
> +#if QSV_HAVE_EXT_HEVC_TILES
> +if (avctx->codec_id == AV_CODEC_ID_HEVC) {
> +q->exthevctiles.Header.BufferId = MFX_EXTBUFF_HEVC_TILES;
> +q->exthevctiles.Header.BufferSz = sizeof(q->exthevctiles);
> +q->exthevctiles.NumTileColumns = q->tile_cols;
> +q->exthevctiles.NumTileRows = q->tile_rows;
Is it have any other limition for the number of tile columns/rows ?
> +q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
> *)&q->exthevctiles;
> +}
> +#endif
> +
> if (!check_enc_param(avctx,q)) {
> av_log(avctx, AV_LOG_ERROR,
> "some encoding parameters are not supported by the QSV "
> @@ -887,7 +906,14 @@ static int qsv_retrieve_enc_params(AVCodecContext
> *avctx, QSVEncContext *q)
> };
> #endif
>
> -mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS];
> +#if QSV_HAVE_EXT_HEVC_TILES
> +mfxExtHEVCTiles hevc_tile_buf = {
> + .Header.BufferId = MFX_EXTBUFF_HEVC_TILES,
> + .Header.BufferSz = sizeof(hevc_tile_buf),
> +};
> +#endif
> +
> +mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS + QSV_HAVE_EXT_HEVC_TILES];
>
> int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
> int ret, ext_buf_num = 0, extradata_offset = 0;
> @@ -905,6 +931,10 @@ static int qsv_retrieve_enc_params(AVCodecContext
> *avctx, QSVEncContext *q)
> if (q->hevc_vps)
> ext_buffers[ext_buf_num++] = (mfxExtBuffer*)&extradata_vps;
> #endif
> +#if QSV_HAVE_EXT_HEVC_TILES
> +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> +ext_buffers[ext_buf_num++] = (mfxExtBuffer*)&hevc_tile_buf;
> +#endif
>
> q->param.ExtParam= ext_buffers;
> q->param.NumExtParam = ext_buf_num;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index ee35582..6609171 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -38,6 +38,7 @@
> #define QSV_HAVE_CO3 QSV_VERSION_ATLEAST(1, 11)
> #define QSV_HAVE_CO_VPS QSV_VERSION_ATLEAST(1, 17)
>
> +#define QSV_HAVE_EXT_HEVC_TILES QSV_VERSION_ATLEAST(1, 13)
> #define QSV_HAVE_EXT_VP9_PARAM QSV_VERSION_ATLEAST(1, 26)
>
> #define QSV_HAVE_TRELLIS QSV_VERSION_ATLEAST(1, 8)
> @@ -124,6 +125,9 @@ typedef struct QSVEncContext {
> mfxExtMultiFrameParam extmfp;
> mfxExtMultiFrameControl extmfc;
> #endif
> +#if QSV_HAVE_EXT_HEVC_TILES
> +mfxExtHEVCTiles exthevctiles;
> +#endif
> #if QSV_HAVE_EXT_VP9_PARAM
> mfxExtVP9Param extvp9param;
> #endif
> @@ -161,6 +165,9 @@ typedef struct QSVEncContext {
> int max_frame_size;
> int max_slice_size;
>
> +int tile_cols;
> +int tile_rows;
[FFmpeg-devel] [PATCH v3] avformat/hlsenc: remove duplicate code block
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 043438368e..f90016901a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2486,8 +2486,11 @@ static void hls_free_variant_streams(struct HLSContext
*hls)
if (vtt_oc) {
av_freep(&vs->vtt_basename);
av_freep(&vs->vtt_m3u8_name);
+avformat_free_context(vtt_oc);
}
+avformat_free_context(vs->avf);
+
hls_free_segments(vs->segments);
hls_free_segments(vs->old_segments);
av_freep(&vs->m3u8_name);
@@ -2619,7 +2622,6 @@ failed:
av_write_trailer(vtt_oc);
vs->size = avio_tell(vs->vtt_avf->pb) - vs->start_pos;
ff_format_io_close(s, &vtt_oc->pb);
-avformat_free_context(vtt_oc);
}
ret = hls_window(s, 1, vs);
if (ret < 0) {
@@ -2628,7 +2630,6 @@ failed:
hls_window(s, 1, vs);
}
ffio_free_dyn_buf(&oc->pb);
-avformat_free_context(oc);
vs->avf = NULL;
av_free(old_filename);
@@ -2956,31 +2957,14 @@ static int hls_init(AVFormatContext *s)
fail:
if (ret < 0) {
-av_freep(&hls->key_basename);
-for (i = 0; i < hls->nb_varstreams && hls->var_streams; i++) {
-vs = &hls->var_streams[i];
-av_freep(&vs->basename);
-av_freep(&vs->vtt_basename);
-av_freep(&vs->fmp4_init_filename);
-av_freep(&vs->m3u8_name);
-av_freep(&vs->vtt_m3u8_name);
-av_freep(&vs->streams);
-av_freep(&vs->language);
-av_freep(&vs->agroup);
-av_freep(&vs->ccgroup);
-av_freep(&vs->baseurl);
-av_freep(&vs->varname);
-if (vs->avf)
-avformat_free_context(vs->avf);
-if (vs->vtt_avf)
-avformat_free_context(vs->vtt_avf);
-}
+hls_free_variant_streams(hls);
for (i = 0; i < hls->nb_ccstreams; i++) {
ClosedCaptionsStream *ccs = &hls->cc_streams[i];
av_freep(&ccs->ccgroup);
av_freep(&ccs->instreamid);
av_freep(&ccs->language);
}
+av_freep(&hls->key_basename);
av_freep(&hls->var_streams);
av_freep(&hls->cc_streams);
av_freep(&hls->master_m3u8_url);
--
2.15.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 v2] avformat/hlsenc: remove duplicate code block
> 在 2019年11月29日，12:56，myp...@gmail.com 写道：
>
> On Fri, Nov 29, 2019 at 12:46 PM Steven Liu wrote:
>>
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/hlsenc.c | 27 ++-
>> 1 file changed, 6 insertions(+), 21 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 043438368e..34ffab49a0 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -2486,8 +2486,12 @@ static void hls_free_variant_streams(struct
>> HLSContext *hls)
>> if (vtt_oc) {
>> av_freep(&vs->vtt_basename);
>> av_freep(&vs->vtt_m3u8_name);
>> +avformat_free_context(vtt_oc);
>> }
>>
>> +if (vs->avf)
>> +avformat_free_context(vs->avf);
> avformat_free_context can handle the NULL case, so don't need to check
> the NULL before this call
New version submited
>> +
>> hls_free_segments(vs->segments);
>> hls_free_segments(vs->old_segments);
>> av_freep(&vs->m3u8_name);
>> @@ -2619,7 +2623,6 @@ failed:
>> av_write_trailer(vtt_oc);
>> vs->size = avio_tell(vs->vtt_avf->pb) - vs->start_pos;
>> ff_format_io_close(s, &vtt_oc->pb);
>> -avformat_free_context(vtt_oc);
>> }
>> ret = hls_window(s, 1, vs);
>> if (ret < 0) {
>> @@ -2628,7 +2631,6 @@ failed:
>> hls_window(s, 1, vs);
>> }
>> ffio_free_dyn_buf(&oc->pb);
>> -avformat_free_context(oc);
>>
>> vs->avf = NULL;
>> av_free(old_filename);
>> @@ -2956,31 +2958,14 @@ static int hls_init(AVFormatContext *s)
>>
>> fail:
>> if (ret < 0) {
>> -av_freep(&hls->key_basename);
>> -for (i = 0; i < hls->nb_varstreams && hls->var_streams; i++) {
>> -vs = &hls->var_streams[i];
>> -av_freep(&vs->basename);
>> -av_freep(&vs->vtt_basename);
>> -av_freep(&vs->fmp4_init_filename);
>> -av_freep(&vs->m3u8_name);
>> -av_freep(&vs->vtt_m3u8_name);
>> -av_freep(&vs->streams);
>> -av_freep(&vs->language);
>> -av_freep(&vs->agroup);
>> -av_freep(&vs->ccgroup);
>> -av_freep(&vs->baseurl);
>> -av_freep(&vs->varname);
>> -if (vs->avf)
>> -avformat_free_context(vs->avf);
>> -if (vs->vtt_avf)
>> -avformat_free_context(vs->vtt_avf);
>> -}
>> +hls_free_variant_streams(hls);
>> for (i = 0; i < hls->nb_ccstreams; i++) {
>> ClosedCaptionsStream *ccs = &hls->cc_streams[i];
>> av_freep(&ccs->ccgroup);
>> av_freep(&ccs->instreamid);
>> av_freep(&ccs->language);
>> }
>> +av_freep(&hls->key_basename);
>> av_freep(&hls->var_streams);
>> av_freep(&hls->cc_streams);
>> av_freep(&hls->master_m3u8_url);
>> --
>> 2.15.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".
Thanks
Steven
___
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/4] avformat/dashenc: remove unused check of avformat_free_context
Signed-off-by: Steven Liu --- libavformat/dashenc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c index a462876c13..8c28fb6b6e 100644 --- a/libavformat/dashenc.c +++ b/libavformat/dashenc.c @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s) avio_close(os->ctx->pb); } ff_format_io_close(s, &os->out); -if (os->ctx) -avformat_free_context(os->ctx); +avformat_free_context(os->ctx); for (j = 0; j < os->nb_segments; j++) av_free(os->segments[j]); av_free(os->segments); -- 2.15.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 4/4] avformat/smoothstreamingenc: removed unused check of avformat_free_context
Signed-off-by: Steven Liu --- libavformat/smoothstreamingenc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavformat/smoothstreamingenc.c b/libavformat/smoothstreamingenc.c index 1ed19ebb2f..2faf1e7897 100644 --- a/libavformat/smoothstreamingenc.c +++ b/libavformat/smoothstreamingenc.c @@ -183,8 +183,7 @@ static void ism_free(AVFormatContext *s) av_write_trailer(os->ctx); if (os->ctx && os->ctx->pb) avio_context_free(&os->ctx->pb); -if (os->ctx) -avformat_free_context(os->ctx); +avformat_free_context(os->ctx); av_freep(&os->private_str); for (j = 0; j < os->nb_fragments; j++) av_freep(&os->fragments[j]); -- 2.15.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 2/4] avformat/hdsenc: removed unused check of avformat_free_context
Signed-off-by: Steven Liu --- libavformat/hdsenc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavformat/hdsenc.c b/libavformat/hdsenc.c index 026530ac36..46f0026bce 100644 --- a/libavformat/hdsenc.c +++ b/libavformat/hdsenc.c @@ -146,8 +146,7 @@ static void hds_free(AVFormatContext *s) av_write_trailer(os->ctx); if (os->ctx) avio_context_free(&os->ctx->pb); -if (os->ctx) -avformat_free_context(os->ctx); +avformat_free_context(os->ctx); av_freep(&os->metadata); for (j = 0; j < os->nb_extra_packets; j++) av_freep(&os->extra_packets[j]); -- 2.15.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/4] avformat/rtpenc_mpegts: removed unused check of avformat_free_context
Signed-off-by: Steven Liu --- libavformat/rtpenc_mpegts.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c index 45ba6fffe5..7d7377db7a 100644 --- a/libavformat/rtpenc_mpegts.c +++ b/libavformat/rtpenc_mpegts.c @@ -106,8 +106,7 @@ fail: av_dict_free(&mpegts_ctx->metadata); avformat_free_context(mpegts_ctx); } -if (rtp_ctx) -avformat_free_context(rtp_ctx); +avformat_free_context(rtp_ctx); rtp_mpegts_write_close(s); return ret; } -- 2.15.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] lavc/qsvenc: add Tiles encode support for HEVC
Linjie Fu 于2019年11月26日周二 下午12:04写道：
>
> Add -tile_rows and -tile_cols option to specify the number of tile rows
> and columns for ICL+ (gen 11) platform.
>
> A tile must wholly contain all the slices within it. Slices cannot cross
> tile boundaries. So the slice number would be implicitly resized to the
> max(nSlice, nTile).
I would like to the check in the code too, instead of just commit message.
> Example:
> ffmpeg -v verbose -hwaccel qsv -init_hw_device qsv=hw
> -filter_hw_device hw -f rawvideo -s:v 1920x1080 -i ./input.nv12 -vf
> format=nv12,hwupload=extra_hw_frames=64 -c:v hevc_qsv -tile_rows 2
> -tile_cols 2 -slices 4 -y output.h265
>
> Also dump the actual quantity of encoded tiled rows and columns in run
> time.
>
> Fix the enhancement #8400.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/qsvenc.c | 32 +++-
> libavcodec/qsvenc.h | 7 +++
> libavcodec/qsvenc_hevc.c | 3 +++
> 3 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index e176d57..64814fc 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -139,6 +139,9 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> #if QSV_HAVE_CO3
> mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
> #endif
> +#if QSV_HAVE_EXT_HEVC_TILES
> +mfxExtHEVCTiles *exthevctiles = (mfxExtHEVCTiles *)coding_opts[3 +
> QSV_HAVE_CO_VPS];
Should change QSV_HAVE_CO_VPS to QSV_HAVE_EXT_HEVC_TILES?
> +#endif
>
> av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> print_profile(info->CodecProfile), info->CodecLevel);
> @@ -204,6 +207,12 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
> print_threestate(co->RateDistortionOpt));
>
> +#if QSV_HAVE_EXT_HEVC_TILES
> +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> +av_log(avctx, AV_LOG_VERBOSE, "NumTileColumns: %"PRIu16";
> NumTileRows: %"PRIu16"\n",
> + exthevctiles->NumTileColumns, exthevctiles->NumTileRows);
> +#endif
> +
> #if QSV_HAVE_CO2
> av_log(avctx, AV_LOG_VERBOSE,
> "RecoveryPointSEI: %s IntRefType: %"PRIu16"; IntRefCycleSize:
> %"PRIu16"; IntRefQPDelta: %"PRId16"\n",
> @@ -771,6 +780,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
> }
> #endif
>
> +#if QSV_HAVE_EXT_HEVC_TILES
> +if (avctx->codec_id == AV_CODEC_ID_HEVC) {
> +q->exthevctiles.Header.BufferId = MFX_EXTBUFF_HEVC_TILES;
> +q->exthevctiles.Header.BufferSz = sizeof(q->exthevctiles);
> +q->exthevctiles.NumTileColumns = q->tile_cols;
> +q->exthevctiles.NumTileRows = q->tile_rows;
> +q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
> *)&q->exthevctiles;
> +}
> +#endif
> +
> if (!check_enc_param(avctx,q)) {
> av_log(avctx, AV_LOG_ERROR,
> "some encoding parameters are not supported by the QSV "
> @@ -887,7 +906,14 @@ static int qsv_retrieve_enc_params(AVCodecContext
> *avctx, QSVEncContext *q)
> };
> #endif
>
> -mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS];
> +#if QSV_HAVE_EXT_HEVC_TILES
> +mfxExtHEVCTiles hevc_tile_buf = {
> + .Header.BufferId = MFX_EXTBUFF_HEVC_TILES,
> + .Header.BufferSz = sizeof(hevc_tile_buf),
> +};
> +#endif
> +
> +mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS + QSV_HAVE_EXT_HEVC_TILES];
>
> int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
> int ret, ext_buf_num = 0, extradata_offset = 0;
> @@ -905,6 +931,10 @@ static int qsv_retrieve_enc_params(AVCodecContext
> *avctx, QSVEncContext *q)
> if (q->hevc_vps)
> ext_buffers[ext_buf_num++] = (mfxExtBuffer*)&extradata_vps;
> #endif
> +#if QSV_HAVE_EXT_HEVC_TILES
> +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> +ext_buffers[ext_buf_num++] = (mfxExtBuffer*)&hevc_tile_buf;
> +#endif
>
> q->param.ExtParam= ext_buffers;
> q->param.NumExtParam = ext_buf_num;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index ee35582..6609171 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -38,6 +38,7 @@
> #define QSV_HAVE_CO3 QSV_VERSION_ATLEAST(1, 11)
> #define QSV_HAVE_CO_VPS QSV_VERSION_ATLEAST(1, 17)
>
> +#define QSV_HAVE_EXT_HEVC_TILES QSV_VERSION_ATLEAST(1, 13)
> #define QSV_HAVE_EXT_VP9_PARAM QSV_VERSION_ATLEAST(1, 26)
>
> #define QSV_HAVE_TRELLIS QSV_VERSION_ATLEAST(1, 8)
> @@ -124,6 +125,9 @@ typedef struct QSVEncContext {
> mfxExtMultiFrameParam extmfp;
> mfxExtMultiFrameControl extmfc;
> #endif
> +#if QSV_HAVE_EXT_HEVC_TILES
> +mfxExtHEVCTiles exthevctiles;
> +#endif
> #if QSV_HAVE_EXT_VP9_PARAM
> mfxExtVP9Param extvp9param;
> #endif
> @@ -161,6 +165,9 @@ typedef struct QSVEncContext {
> int max_frame_size;
> int max_sli
Re: [FFmpeg-devel] [PATCH v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
On Fri, Nov 29, 2019 at 1:16 PM Steven Liu wrote: > > Signed-off-by: Steven Liu > --- > libavformat/dashenc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c > index a462876c13..8c28fb6b6e 100644 > --- a/libavformat/dashenc.c > +++ b/libavformat/dashenc.c > @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s) > avio_close(os->ctx->pb); > } > ff_format_io_close(s, &os->out); > -if (os->ctx) > -avformat_free_context(os->ctx); > +avformat_free_context(os->ctx); > for (j = 0; j < os->nb_segments; j++) > av_free(os->segments[j]); > av_free(os->segments); > -- > 2.15.1 > Patchset LGTM ___ 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 v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
On 11/29/19 10:45 AM, Steven Liu wrote: > Signed-off-by: Steven Liu > --- > libavformat/dashenc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c > index a462876c13..8c28fb6b6e 100644 > --- a/libavformat/dashenc.c > +++ b/libavformat/dashenc.c > @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s) > avio_close(os->ctx->pb); > } > ff_format_io_close(s, &os->out); > -if (os->ctx) > -avformat_free_context(os->ctx); > +avformat_free_context(os->ctx); This 'if' condition is a safety net against double frees caused due to any corner case and/or wrong usage. Unless this is absolutely required for some reason, this 'if' condition should not be removed. > for (j = 0; j < os->nb_segments; j++) > av_free(os->segments[j]); > av_free(os->segments); ___ 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 v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
> 在 2019年11月29日，13:35，Jeyapal, Karthick 写道：
>
>
> On 11/29/19 10:45 AM, Steven Liu wrote:
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/dashenc.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index a462876c13..8c28fb6b6e 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s)
>> avio_close(os->ctx->pb);
>> }
>> ff_format_io_close(s, &os->out);
>> -if (os->ctx)
>> -avformat_free_context(os->ctx);
>> +avformat_free_context(os->ctx);
> This 'if' condition is a safety net against double frees caused due to any
> corner case and/or wrong usage.
> Unless this is absolutely required for some reason, this 'if' condition
> should not be removed.
4433 void avformat_free_context(AVFormatContext *s)
4434 {
4435 int i;
4436
4437 if (!s)
4438 return;
This check is in the function of avformat_free_context.
>> for (j = 0; j < os->nb_segments; j++)
>> av_free(os->segments[j]);
>> av_free(os->segments);
>
Thanks
Steven
___
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 v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
On 11/29/19 11:08 AM, Steven Liu wrote:
>
>
>> 在 2019年11月29日，13:35，Jeyapal, Karthick 写道：
>>
>>
>> On 11/29/19 10:45 AM, Steven Liu wrote:
>>> Signed-off-by: Steven Liu
>>> ---
>>> libavformat/dashenc.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>>> index a462876c13..8c28fb6b6e 100644
>>> --- a/libavformat/dashenc.c
>>> +++ b/libavformat/dashenc.c
>>> @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s)
>>> avio_close(os->ctx->pb);
>>> }
>>> ff_format_io_close(s, &os->out);
>>> -if (os->ctx)
>>> -avformat_free_context(os->ctx);
>>> +avformat_free_context(os->ctx);
>> This 'if' condition is a safety net against double frees caused due to any
>> corner case and/or wrong usage.
>> Unless this is absolutely required for some reason, this 'if' condition
>> should not be removed.
>
>
> 4433 void avformat_free_context(AVFormatContext *s)
> 4434 {
> 4435 int i;
> 4436
> 4437 if (!s)
> 4438 return;
>
> This check is in the function of avformat_free_context.
Great! Then it is fine. You can remove it.
>
>>> for (j = 0; j < os->nb_segments; j++)
>>> av_free(os->segments[j]);
>>> av_free(os->segments);
>>
>
> Thanks
> Steven
>
>
>
>
>
___
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 v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
> 在 2019年11月29日，13:39，Jeyapal, Karthick 写道：
>
>
> On 11/29/19 11:08 AM, Steven Liu wrote:
>>
>>
>>> 在 2019年11月29日，13:35，Jeyapal, Karthick 写道：
>>>
>>>
>>> On 11/29/19 10:45 AM, Steven Liu wrote:
Signed-off-by: Steven Liu
---
libavformat/dashenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index a462876c13..8c28fb6b6e 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s)
avio_close(os->ctx->pb);
}
ff_format_io_close(s, &os->out);
-if (os->ctx)
-avformat_free_context(os->ctx);
+avformat_free_context(os->ctx);
>>> This 'if' condition is a safety net against double frees caused due to any
>>> corner case and/or wrong usage.
>>> Unless this is absolutely required for some reason, this 'if' condition
>>> should not be removed.
>>
>>
>> 4433 void avformat_free_context(AVFormatContext *s)
>> 4434 {
>> 4435 int i;
>> 4436
>> 4437 if (!s)
>> 4438 return;
>>
>> This check is in the function of avformat_free_context.
> Great! Then it is fine. You can remove it.
Thanks Jeyapal :)
>>
for (j = 0; j < os->nb_segments; j++)
av_free(os->segments[j]);
av_free(os->segments);
>>>
>>
>> Thanks
>> Steven
Thanks
Steven
___
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] lavc/qsvenc: add Tiles encode support for HEVC
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> myp...@gmail.com
> Sent: Friday, November 29, 2019 13:03
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: add Tiles encode support
> for HEVC
>
> On Tue, Nov 26, 2019 at 12:04 PM Linjie Fu wrote:
> >
> > Add -tile_rows and -tile_cols option to specify the number of tile rows
> > and columns for ICL+ (gen 11) platform.
> >
> > A tile must wholly contain all the slices within it. Slices cannot cross
> > tile boundaries. So the slice number would be implicitly resized to the
> > max(nSlice, nTile).
> >
> > Example:
> > ffmpeg -v verbose -hwaccel qsv -init_hw_device qsv=hw
> > -filter_hw_device hw -f rawvideo -s:v 1920x1080 -i ./input.nv12 -vf
> > format=nv12,hwupload=extra_hw_frames=64 -c:v hevc_qsv -tile_rows 2
> > -tile_cols 2 -slices 4 -y output.h265
> >
> > Also dump the actual quantity of encoded tiled rows and columns in run
> > time.
> >
> > Fix the enhancement #8400.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavcodec/qsvenc.c | 32 +++-
> > libavcodec/qsvenc.h | 7 +++
> > libavcodec/qsvenc_hevc.c | 3 +++
> > 3 files changed, 41 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> > index e176d57..64814fc 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -139,6 +139,9 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
> > #if QSV_HAVE_CO3
> > mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
> > #endif
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +mfxExtHEVCTiles *exthevctiles = (mfxExtHEVCTiles *)coding_opts[3 +
> QSV_HAVE_CO_VPS];
> > +#endif
> >
> > av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> > print_profile(info->CodecProfile), info->CodecLevel);
> > @@ -204,6 +207,12 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
> > av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
> > print_threestate(co->RateDistortionOpt));
> >
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> > +av_log(avctx, AV_LOG_VERBOSE, "NumTileColumns: %"PRIu16";
> NumTileRows: %"PRIu16"\n",
> > + exthevctiles->NumTileColumns, exthevctiles->NumTileRows);
> > +#endif
> > +
> > #if QSV_HAVE_CO2
> > av_log(avctx, AV_LOG_VERBOSE,
> > "RecoveryPointSEI: %s IntRefType: %"PRIu16";
> IntRefCycleSize: %"PRIu16"; IntRefQPDelta: %"PRId16"\n",
> > @@ -771,6 +780,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > }
> > #endif
> >
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +if (avctx->codec_id == AV_CODEC_ID_HEVC) {
> > +q->exthevctiles.Header.BufferId = MFX_EXTBUFF_HEVC_TILES;
> > +q->exthevctiles.Header.BufferSz = sizeof(q->exthevctiles);
> > +q->exthevctiles.NumTileColumns = q->tile_cols;
> > +q->exthevctiles.NumTileRows = q->tile_rows;
> Is it have any other limition for the number of tile columns/rows ?
It depends on the total number of row/column blocks and the work mode of
encoder(VDEnc or VMEPAK).
The limitation varies:
https://github.com/Intel-Media-SDK/MediaSDK/blob/5a84af5fa61823a84f32e4b26d864730a927f48c/_studio/mfx_lib/encode_hw/h265/src/mfx_h265_encode_hw_par.cpp#L524
Hence I dumped the returned MFX_EXTBUFF_HEVC_TILES buffer to see the truly
supported numbers
of Columns and Rows.
If the setting of row or col is out of range, this would help to inform user.
Thanks,
- linjie
___
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 v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
Jeyapal, Karthick: > > On 11/29/19 10:45 AM, Steven Liu wrote: >> Signed-off-by: Steven Liu >> --- >> libavformat/dashenc.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c >> index a462876c13..8c28fb6b6e 100644 >> --- a/libavformat/dashenc.c >> +++ b/libavformat/dashenc.c >> @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s) >> avio_close(os->ctx->pb); >> } >> ff_format_io_close(s, &os->out); >> -if (os->ctx) >> -avformat_free_context(os->ctx); >> +avformat_free_context(os->ctx); > This 'if' condition is a safety net against double frees caused due to any > corner case and/or wrong usage. > Unless this is absolutely required for some reason, this 'if' condition > should not be removed. This 'if' doesn't help against double-frees at all: avformat_free_context() itself checks against its argument being NULL and returns immediately if it is. (But double frees are still possible given that avformat_free_context can't reset the pointer to NULL due to its signature. Resetting is something the callers have to do for themselves.) - Andreas ___ 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 v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
> 在 2019年11月29日，13:40，Andreas Rheinhardt 写道： > > Jeyapal, Karthick: >> >> On 11/29/19 10:45 AM, Steven Liu wrote: >>> Signed-off-by: Steven Liu >>> --- >>> libavformat/dashenc.c | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c >>> index a462876c13..8c28fb6b6e 100644 >>> --- a/libavformat/dashenc.c >>> +++ b/libavformat/dashenc.c >>> @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s) >>> avio_close(os->ctx->pb); >>> } >>> ff_format_io_close(s, &os->out); >>> -if (os->ctx) >>> -avformat_free_context(os->ctx); >>> +avformat_free_context(os->ctx); >> This 'if' condition is a safety net against double frees caused due to any >> corner case and/or wrong usage. >> Unless this is absolutely required for some reason, this 'if' condition >> should not be removed. > > This 'if' doesn't help against double-frees at all: > avformat_free_context() itself checks against its argument being NULL > and returns immediately if it is. (But double frees are still possible > given that avformat_free_context can't reset the pointer to NULL due > to its signature. Resetting is something the callers have to do for > themselves.) What about add reset pointer to NULL into the avformat_free_context? > > - Andreas > ___ > 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". Thanks Steven ___ 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/utils: set the AVFormatContext to NULL before return from avformat_free_context
Signed-off-by: Steven Liu --- libavformat/utils.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/utils.c b/libavformat/utils.c index 8196442dd1..0461aa83ec 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -4469,6 +4469,7 @@ void avformat_free_context(AVFormatContext *s) av_freep(&s->internal); av_freep(&s->url); av_free(s); +s = NULL; } void avformat_close_input(AVFormatContext **ps) -- 2.15.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] avformat/utils: set the AVFormatContext to NULL before return from avformat_free_context
Steven Liu: > Signed-off-by: Steven Liu > --- > libavformat/utils.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/utils.c b/libavformat/utils.c > index 8196442dd1..0461aa83ec 100644 > --- a/libavformat/utils.c > +++ b/libavformat/utils.c > @@ -4469,6 +4469,7 @@ void avformat_free_context(AVFormatContext *s) > av_freep(&s->internal); > av_freep(&s->url); > av_free(s); > +s = NULL; > } > > void avformat_close_input(AVFormatContext **ps) > Absolutely pointless as I have just explained in another mail: This resets the function's copy of s, a local variable whose lifetime ends with this function anyway. - Andreas ___ 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 v1] avcodec/vaapi: set more flags for VASurfaceAttrib
> -Original Message-
> From: ffmpeg-devel On Behalf Of Fu,
> Linjie
> Sent: Thursday, November 28, 2019 5:42 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>; myp...@gmail.com
> Subject: Re: [FFmpeg-devel] [PATCH v1] avcodec/vaapi: set more flags for
> VASurfaceAttrib
>
> Hi,
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Wang, Fei W
> > Sent: Wednesday, November 20, 2019 10:40
> > To: myp...@gmail.com; FFmpeg development discussions and patches
> >
> > Subject: Re: [FFmpeg-devel] [PATCH v1] avcodec/vaapi: set more flags
> > for VASurfaceAttrib
> >
> >
> > > On Tue, Nov 19, 2019 at 4:24 PM Wangfei wrote:
> > > >
> > > > flags and value.type is needed when pass VASurfaceAttrib to driver.
> > > > Otherwise the attribute will be considered invalid in driver.
> > > >
> > > > Signed-off-by: Wangfei
> > > > ---
> > > > libavcodec/vaapi_decode.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > > > index 69512e1d45..a93aba5a5d 100644
> > > > --- a/libavcodec/vaapi_decode.c
> > > > +++ b/libavcodec/vaapi_decode.c
> > > > @@ -350,6 +350,8 @@ static int
> > > > vaapi_decode_find_best_format(AVCodecContext *avctx,
> > > >
> > > > ctx->pixel_format_attribute = (VASurfaceAttrib) {
> > > > .type = VASurfaceAttribPixelFormat,
> > > > +.flags = VA_SURFACE_ATTRIB_SETTABLE,
> > > > +.value.type= VAGenericValueTypeInteger,
> > > I can't found any description in libva about this part, do you have
> > > any other docs?
> > I checked the logic of vaCreateSurfaces implementation in
> > media-driver, it will check flags and value.type in VASurfaceAttrib
> > when using it. If leaks of the info, it will consider the attribute is
> > invalid or assert(in this case, flags checked first, so no assert
> > occurred.):
> > https://github.com/intel/media-
> >
> driver/blob/8a8b8ae263a04cb5dd384d4625215cf296d2cc59/media_driver/li
> n
> > ux/common/ddi/media_libva.cpp#L2149
> >
> > On the other hand, there is another place in ffmpeg-vaapi that sets
> > VASurfaceAttrib, and it filled flags and value.type:
> >
> https://github.com/FFmpeg/FFmpeg/blob/d73f06270600c37c74beeceac37f5
> > 93838ced383/libavutil/hwcontext_vaapi.c#L527
> > So I believe here we need do the same thing.
> >
> > > > .value.value.i = best_fourcc,
> > > > };
>
> Setting flags and type allows driver to assign the
> expected_fourcc/media_format of surface according to the best FourCC,
> instead of determining by the VA_RT_FORMAT_ defined in
> vaapi_format_map[].
>
> With this patch, decoder still works well even if a wrong VA_RT_FORMAT_
> was assigned.
> (For example, VA_RT_FORMAT_YUV444 assigned to VA_FOURCC_NV12,
> when decoding
> NV12 clips)
Thanks Linjie for your comments. When decoding NV12 clips(here I guess you mean
8bit depth clips), we shouldn't set VA_RT_FORMAT_YUV444 RT format but should
be VA_RT_FORMAT_YUV420 when create surface. If it happens, I believe it should
be a bug in ffmpeg.
>
> Patch LGTM since it seems to be more robust.(but also may hide some
> mistakes on the other hand)
>
> Thanks,
>
> - linjie
>
>
> ___
> 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 v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
Steven Liu: > > >> 在 2019年11月29日，13:40，Andreas Rheinhardt 写道： >> >> Jeyapal, Karthick: >>> >>> On 11/29/19 10:45 AM, Steven Liu wrote: Signed-off-by: Steven Liu --- libavformat/dashenc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c index a462876c13..8c28fb6b6e 100644 --- a/libavformat/dashenc.c +++ b/libavformat/dashenc.c @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s) avio_close(os->ctx->pb); } ff_format_io_close(s, &os->out); -if (os->ctx) -avformat_free_context(os->ctx); +avformat_free_context(os->ctx); >>> This 'if' condition is a safety net against double frees caused due to any >>> corner case and/or wrong usage. >>> Unless this is absolutely required for some reason, this 'if' condition >>> should not be removed. >> >> This 'if' doesn't help against double-frees at all: >> avformat_free_context() itself checks against its argument being NULL >> and returns immediately if it is. (But double frees are still possible >> given that avformat_free_context can't reset the pointer to NULL due >> to its signature. Resetting is something the callers have to do for >> themselves.) > What about add reset pointer to NULL into the avformat_free_context? This is pointless, because it will just reset the functions copy of the pointer to NULL, not the callers pointer to the AVFormatContext. In order to reset the latter, the parameter would have to be of type AVFormatContext ** (and the call here would be avformat_free_context(&os->ctx)). - Andreas ___ 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 v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
> 在 2019年11月29日，13:57，Andreas Rheinhardt 写道： > > Steven Liu: >> >> >>> 在 2019年11月29日，13:40，Andreas Rheinhardt 写道： >>> >>> Jeyapal, Karthick: On 11/29/19 10:45 AM, Steven Liu wrote: > Signed-off-by: Steven Liu > --- > libavformat/dashenc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c > index a462876c13..8c28fb6b6e 100644 > --- a/libavformat/dashenc.c > +++ b/libavformat/dashenc.c > @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s) >avio_close(os->ctx->pb); >} >ff_format_io_close(s, &os->out); > -if (os->ctx) > -avformat_free_context(os->ctx); > +avformat_free_context(os->ctx); This 'if' condition is a safety net against double frees caused due to any corner case and/or wrong usage. Unless this is absolutely required for some reason, this 'if' condition should not be removed. >>> >>> This 'if' doesn't help against double-frees at all: >>> avformat_free_context() itself checks against its argument being NULL >>> and returns immediately if it is. (But double frees are still possible >>> given that avformat_free_context can't reset the pointer to NULL due >>> to its signature. Resetting is something the callers have to do for >>> themselves.) >> What about add reset pointer to NULL into the avformat_free_context? > > This is pointless, because it will just reset the functions copy of > the pointer to NULL, not the callers pointer to the AVFormatContext. > In order to reset the latter, the parameter would have to be of type > AVFormatContext ** (and the call here would be > avformat_free_context(&os->ctx)). AVFormatContext **? Isn’t that too complex for user of the API caller? > > - Andreas > > ___ > 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". Thanks Steven ___ 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 v1 1/4] avformat/dashenc: remove unused check of avformat_free_context
Steven Liu: > > >> 在 2019年11月29日，13:57，Andreas Rheinhardt 写道： >> >> Steven Liu: >>> >>> 在 2019年11月29日，13:40，Andreas Rheinhardt 写道： Jeyapal, Karthick: > > On 11/29/19 10:45 AM, Steven Liu wrote: >> Signed-off-by: Steven Liu >> --- >> libavformat/dashenc.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c >> index a462876c13..8c28fb6b6e 100644 >> --- a/libavformat/dashenc.c >> +++ b/libavformat/dashenc.c >> @@ -588,8 +588,7 @@ static void dash_free(AVFormatContext *s) >>avio_close(os->ctx->pb); >>} >>ff_format_io_close(s, &os->out); >> -if (os->ctx) >> -avformat_free_context(os->ctx); >> +avformat_free_context(os->ctx); > This 'if' condition is a safety net against double frees caused due to > any corner case and/or wrong usage. > Unless this is absolutely required for some reason, this 'if' condition > should not be removed. This 'if' doesn't help against double-frees at all: avformat_free_context() itself checks against its argument being NULL and returns immediately if it is. (But double frees are still possible given that avformat_free_context can't reset the pointer to NULL due to its signature. Resetting is something the callers have to do for themselves.) >>> What about add reset pointer to NULL into the avformat_free_context? >> >> This is pointless, because it will just reset the functions copy of >> the pointer to NULL, not the callers pointer to the AVFormatContext. >> In order to reset the latter, the parameter would have to be of type >> AVFormatContext ** (and the call here would be >> avformat_free_context(&os->ctx)). > AVFormatContext **? Isn’t that too complex for user of the API caller? I don't see anything complex in such a parameter. And this is actually a quite common scenario (just think of av_freep() or avio_context_free() which both need **-arguments to do their job). - Andreas ___ 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] lavc/qsvenc: add Tiles encode support for HEVC
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Zhong Li
> Sent: Friday, November 29, 2019 13:13
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: add Tiles encode support
> for HEVC
>
> Linjie Fu 于2019年11月26日周二 下午12:04写道：
> >
> > Add -tile_rows and -tile_cols option to specify the number of tile rows
> > and columns for ICL+ (gen 11) platform.
> >
> > A tile must wholly contain all the slices within it. Slices cannot cross
> > tile boundaries. So the slice number would be implicitly resized to the
> > max(nSlice, nTile).
>
> I would like to the check in the code too, instead of just commit message.
Thanks, code link in MSDK should have been attached too:
https://github.com/Intel-Media-SDK/MediaSDK/blob/5a84af5fa61823a84f32e4b26d864730a927f48c/_studio/mfx_lib/encode_hw/h265/src/mfx_h265_encode_hw_par.cpp#L503
This is merged in：
https://github.com/Intel-Media-SDK/MediaSDK/commit/f8ba11a5b7d61422b117bec2b5b88e4a22bbd294
>
> > Example:
> > ffmpeg -v verbose -hwaccel qsv -init_hw_device qsv=hw
> > -filter_hw_device hw -f rawvideo -s:v 1920x1080 -i ./input.nv12 -vf
> > format=nv12,hwupload=extra_hw_frames=64 -c:v hevc_qsv -tile_rows 2
> > -tile_cols 2 -slices 4 -y output.h265
> >
> > Also dump the actual quantity of encoded tiled rows and columns in run
> > time.
> >
> > Fix the enhancement #8400.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavcodec/qsvenc.c | 32 +++-
> > libavcodec/qsvenc.h | 7 +++
> > libavcodec/qsvenc_hevc.c | 3 +++
> > 3 files changed, 41 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> > index e176d57..64814fc 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -139,6 +139,9 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
> > #if QSV_HAVE_CO3
> > mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
> > #endif
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +mfxExtHEVCTiles *exthevctiles = (mfxExtHEVCTiles *)coding_opts[3 +
> QSV_HAVE_CO_VPS];
>
> Should change QSV_HAVE_CO_VPS to QSV_HAVE_EXT_HEVC_TILES?
There is possibility(MSDK version between 1.13 and 1.17) that MSDK has
MFX_EXTBUFF_HEVC_TILES buffer but has no MFX_EXT_BUFF_CODING_OPTION_VPS
buffer.
ext_buffers[]:
BUF_CO | BUF_CO2 | BUF_CO3 | BUF_VPS | BUF_TILE |...
Hence I'd like to check QSV_HAVE_CO_VPS to get the exact address of BUF_TILE
to dump the truly set values.
>
> > +#endif
> >
> > av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> > print_profile(info->CodecProfile), info->CodecLevel);
> > @@ -204,6 +207,12 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
> > av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
> > print_threestate(co->RateDistortionOpt));
> >
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> > +av_log(avctx, AV_LOG_VERBOSE, "NumTileColumns: %"PRIu16";
> NumTileRows: %"PRIu16"\n",
> > + exthevctiles->NumTileColumns, exthevctiles->NumTileRows);
> > +#endif
> > +
> > #if QSV_HAVE_CO2
> > av_log(avctx, AV_LOG_VERBOSE,
> > "RecoveryPointSEI: %s IntRefType: %"PRIu16";
> IntRefCycleSize: %"PRIu16"; IntRefQPDelta: %"PRId16"\n",
> > @@ -771,6 +780,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > }
> > #endif
> >
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +if (avctx->codec_id == AV_CODEC_ID_HEVC) {
> > +q->exthevctiles.Header.BufferId = MFX_EXTBUFF_HEVC_TILES;
> > +q->exthevctiles.Header.BufferSz = sizeof(q->exthevctiles);
> > +q->exthevctiles.NumTileColumns = q->tile_cols;
> > +q->exthevctiles.NumTileRows = q->tile_rows;
> > +q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
> *)&q->exthevctiles;
> > +}
> > +#endif
> > +
> > if (!check_enc_param(avctx,q)) {
> > av_log(avctx, AV_LOG_ERROR,
> > "some encoding parameters are not supported by the QSV "
> > @@ -887,7 +906,14 @@ static int
> qsv_retrieve_enc_params(AVCodecContext *avctx, QSVEncContext *q)
> > };
> > #endif
> >
> > -mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS];
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +mfxExtHEVCTiles hevc_tile_buf = {
> > + .Header.BufferId = MFX_EXTBUFF_HEVC_TILES,
> > + .Header.BufferSz = sizeof(hevc_tile_buf),
> > +};
> > +#endif
> > +
> > +mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS + QSV_HAVE_EXT_HEVC_TILES];
> >
> > int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
> > int ret, ext_buf_num = 0, extradata_offset = 0;
> > @@ -905,6 +931,10 @@ static int
> qsv_retrieve_enc_params(AVCodecContext *avctx, QSVEncContext *q)
> > if (q->hevc_vps)
> > ext_buffers[ext_buf_num++] = (mfxExtBuffer*)&extrada
[FFmpeg-devel] [PATCH v1 2/2] avformat/version: bump version and add avformat_free_context modify info
Signed-off-by: Steven Liu --- doc/APIchanges| 3 +++ libavformat/version.h | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index 2798bec400..02641aee61 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,9 @@ libavutil: 2017-10-21 API changes, most recent first: +2019-11-29 - xx - lavf 58.37.100 - avformat/avformat.h + Modify avformat_free_context argument from AVFormatContext * to AVFormatContext ** + 2019-11-26 - xx - lavf 58.36.100 - avio.h Add avio_protocol_get_class(). diff --git a/libavformat/version.h b/libavformat/version.h index f72fb9478a..15fdb73e3e 100644 --- a/libavformat/version.h +++ b/libavformat/version.h @@ -32,7 +32,7 @@ // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium) // Also please add any ticket numbers that you believe might be affected here #define LIBAVFORMAT_VERSION_MAJOR 58 -#define LIBAVFORMAT_VERSION_MINOR 36 +#define LIBAVFORMAT_VERSION_MINOR 37 #define LIBAVFORMAT_VERSION_MICRO 100 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \ -- 2.15.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/2] avformat/utils: make avformat_free_context safety
set the AVformatContext to NULL use av_freep before
avformat_free_context return
Suggested-by: Andreas Rheinhardt
Signed-off-by: Steven Liu
---
doc/examples/muxing.c| 2 +-
doc/examples/remuxing.c | 2 +-
doc/examples/transcode_aac.c | 4 ++--
doc/examples/transcoding.c | 2 +-
fftools/ffmpeg.c | 2 +-
libavdevice/avdevice.c | 2 +-
libavdevice/utils.c | 2 +-
libavformat/avformat.h | 2 +-
libavformat/dashdec.c| 4 ++--
libavformat/dashenc.c| 2 +-
libavformat/fifo.c | 2 +-
libavformat/hdsenc.c | 2 +-
libavformat/hls.c| 4 ++--
libavformat/hlsenc.c | 4 ++--
libavformat/img2enc.c| 6 +++---
libavformat/mov.c| 2 +-
libavformat/movenchint.c | 2 +-
libavformat/mpegtsenc.c | 2 +-
libavformat/mux.c| 2 +-
libavformat/rtpenc_chain.c | 4 ++--
libavformat/rtpenc_mpegts.c | 8
libavformat/rtsp.c | 2 +-
libavformat/sapenc.c | 2 +-
libavformat/segment.c| 6 +++---
libavformat/smoothstreamingenc.c | 2 +-
libavformat/tee.c| 2 +-
libavformat/tests/fifo_muxer.c | 2 +-
libavformat/tests/movenc.c | 2 +-
libavformat/utils.c | 10 +-
libavformat/webm_chunk.c | 2 +-
tools/target_dem_fuzzer.c| 2 +-
tools/uncoded_frame.c| 2 +-
32 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
index 9af9aae483..a151f9cd67 100644
--- a/doc/examples/muxing.c
+++ b/doc/examples/muxing.c
@@ -661,7 +661,7 @@ int main(int argc, char **argv)
avio_closep(&oc->pb);
/* free the stream */
-avformat_free_context(oc);
+avformat_free_context(&oc);
return 0;
}
diff --git a/doc/examples/remuxing.c b/doc/examples/remuxing.c
index 9e4d1031b4..fce66c3d80 100644
--- a/doc/examples/remuxing.c
+++ b/doc/examples/remuxing.c
@@ -178,7 +178,7 @@ end:
/* close output */
if (ofmt_ctx && !(ofmt->flags & AVFMT_NOFILE))
avio_closep(&ofmt_ctx->pb);
-avformat_free_context(ofmt_ctx);
+avformat_free_context(&ofmt_ctx);
av_freep(&stream_mapping);
diff --git a/doc/examples/transcode_aac.c b/doc/examples/transcode_aac.c
index e0c76f5b35..82c3610e39 100644
--- a/doc/examples/transcode_aac.c
+++ b/doc/examples/transcode_aac.c
@@ -238,7 +238,7 @@ static int open_output_file(const char *filename,
cleanup:
avcodec_free_context(&avctx);
avio_closep(&(*output_format_context)->pb);
-avformat_free_context(*output_format_context);
+avformat_free_context(output_format_context);
*output_format_context = NULL;
return error < 0 ? error : AVERROR_EXIT;
}
@@ -874,7 +874,7 @@ cleanup:
avcodec_free_context(&output_codec_context);
if (output_format_context) {
avio_closep(&output_format_context->pb);
-avformat_free_context(output_format_context);
+avformat_free_context(&output_format_context);
}
if (input_codec_context)
avcodec_free_context(&input_codec_context);
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index e48837cbd2..662dc7e02a 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -611,7 +611,7 @@ end:
avformat_close_input(&ifmt_ctx);
if (ofmt_ctx && !(ofmt_ctx->oformat->flags & AVFMT_NOFILE))
avio_closep(&ofmt_ctx->pb);
-avformat_free_context(ofmt_ctx);
+avformat_free_context(&ofmt_ctx);
if (ret < 0)
av_log(NULL, AV_LOG_ERROR, "Error occurred: %s\n", av_err2str(ret));
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 27f68933f8..c7fa6ccf44 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -539,7 +539,7 @@ static void ffmpeg_cleanup(int ret)
s = of->ctx;
if (s && s->oformat && !(s->oformat->flags & AVFMT_NOFILE))
avio_closep(&s->pb);
-avformat_free_context(s);
+avformat_free_context(&s);
av_dict_free(&of->opts);
av_freep(&output_files[i]);
diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
index 72e1b67887..46a9e85c1d 100644
--- a/libavdevice/avdevice.c
+++ b/libavdevice/avdevice.c
@@ -221,7 +221,7 @@ static int list_devices_for_context(AVFormatContext *s,
AVDictionary *options,
ret = avdevice_list_devices(s, device_list);
fail:
av_dict_free(&tmp);
-avformat_free_context(s);
+avformat_free_context(&s);
return ret;
}
diff --git a/libavdevice/utils.c b/libavdevice/utils.c
index ccd7318012..1b06387fd3 100644
--- a/libavdevice/utils.c
+++ b/libavdevice/utils.c
@@ -54,6 +54,6 @@ int ff_alloc_input_device_context(AVFormatContext **avctx,
AVInputFormat *iforma
*avctx = s;
return 0;
error:
-avformat_free_context(s);
+avformat_free_context(&s);
return ret;
}
diff -
Re: [FFmpeg-devel] [PATCH v1 1/2] avformat/utils: make avformat_free_context safety
> 在 2019年11月29日，15:21，Steven Liu 写道：
>
> set the AVformatContext to NULL use av_freep before
> avformat_free_context return
>
> Suggested-by: Andreas Rheinhardt
> Signed-off-by: Steven Liu
> ---
> doc/examples/muxing.c| 2 +-
> doc/examples/remuxing.c | 2 +-
> doc/examples/transcode_aac.c | 4 ++--
> doc/examples/transcoding.c | 2 +-
> fftools/ffmpeg.c | 2 +-
> libavdevice/avdevice.c | 2 +-
> libavdevice/utils.c | 2 +-
> libavformat/avformat.h | 2 +-
> libavformat/dashdec.c| 4 ++--
> libavformat/dashenc.c| 2 +-
> libavformat/fifo.c | 2 +-
> libavformat/hdsenc.c | 2 +-
> libavformat/hls.c| 4 ++--
> libavformat/hlsenc.c | 4 ++--
> libavformat/img2enc.c| 6 +++---
> libavformat/mov.c| 2 +-
> libavformat/movenchint.c | 2 +-
> libavformat/mpegtsenc.c | 2 +-
> libavformat/mux.c| 2 +-
> libavformat/rtpenc_chain.c | 4 ++--
> libavformat/rtpenc_mpegts.c | 8
> libavformat/rtsp.c | 2 +-
> libavformat/sapenc.c | 2 +-
> libavformat/segment.c| 6 +++---
> libavformat/smoothstreamingenc.c | 2 +-
> libavformat/tee.c| 2 +-
> libavformat/tests/fifo_muxer.c | 2 +-
> libavformat/tests/movenc.c | 2 +-
> libavformat/utils.c | 10 +-
> libavformat/webm_chunk.c | 2 +-
> tools/target_dem_fuzzer.c| 2 +-
> tools/uncoded_frame.c| 2 +-
> 32 files changed, 48 insertions(+), 48 deletions(-)
>
> diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
> index 9af9aae483..a151f9cd67 100644
> --- a/doc/examples/muxing.c
> +++ b/doc/examples/muxing.c
> @@ -661,7 +661,7 @@ int main(int argc, char **argv)
> avio_closep(&oc->pb);
>
> /* free the stream */
> -avformat_free_context(oc);
> +avformat_free_context(&oc);
>
> return 0;
> }
> diff --git a/doc/examples/remuxing.c b/doc/examples/remuxing.c
> index 9e4d1031b4..fce66c3d80 100644
> --- a/doc/examples/remuxing.c
> +++ b/doc/examples/remuxing.c
> @@ -178,7 +178,7 @@ end:
> /* close output */
> if (ofmt_ctx && !(ofmt->flags & AVFMT_NOFILE))
> avio_closep(&ofmt_ctx->pb);
> -avformat_free_context(ofmt_ctx);
> +avformat_free_context(&ofmt_ctx);
>
> av_freep(&stream_mapping);
>
> diff --git a/doc/examples/transcode_aac.c b/doc/examples/transcode_aac.c
> index e0c76f5b35..82c3610e39 100644
> --- a/doc/examples/transcode_aac.c
> +++ b/doc/examples/transcode_aac.c
> @@ -238,7 +238,7 @@ static int open_output_file(const char *filename,
> cleanup:
> avcodec_free_context(&avctx);
> avio_closep(&(*output_format_context)->pb);
> -avformat_free_context(*output_format_context);
> +avformat_free_context(output_format_context);
> *output_format_context = NULL;
> return error < 0 ? error : AVERROR_EXIT;
> }
> @@ -874,7 +874,7 @@ cleanup:
> avcodec_free_context(&output_codec_context);
> if (output_format_context) {
> avio_closep(&output_format_context->pb);
> -avformat_free_context(output_format_context);
> +avformat_free_context(&output_format_context);
> }
> if (input_codec_context)
> avcodec_free_context(&input_codec_context);
> diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
> index e48837cbd2..662dc7e02a 100644
> --- a/doc/examples/transcoding.c
> +++ b/doc/examples/transcoding.c
> @@ -611,7 +611,7 @@ end:
> avformat_close_input(&ifmt_ctx);
> if (ofmt_ctx && !(ofmt_ctx->oformat->flags & AVFMT_NOFILE))
> avio_closep(&ofmt_ctx->pb);
> -avformat_free_context(ofmt_ctx);
> +avformat_free_context(&ofmt_ctx);
>
> if (ret < 0)
> av_log(NULL, AV_LOG_ERROR, "Error occurred: %s\n", av_err2str(ret));
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 27f68933f8..c7fa6ccf44 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -539,7 +539,7 @@ static void ffmpeg_cleanup(int ret)
> s = of->ctx;
> if (s && s->oformat && !(s->oformat->flags & AVFMT_NOFILE))
> avio_closep(&s->pb);
> -avformat_free_context(s);
> +avformat_free_context(&s);
> av_dict_free(&of->opts);
>
> av_freep(&output_files[i]);
> diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
> index 72e1b67887..46a9e85c1d 100644
> --- a/libavdevice/avdevice.c
> +++ b/libavdevice/avdevice.c
> @@ -221,7 +221,7 @@ static int list_devices_for_context(AVFormatContext *s,
> AVDictionary *options,
> ret = avdevice_list_devices(s, device_list);
> fail:
> av_dict_free(&tmp);
> -avformat_free_context(s);
> +avformat_free_context(&s);
> return ret;
> }
>
> diff --git a/libavdevice/utils.c b/libavdevice/utils.c
> index ccd7318012..1b06387fd3 100644
> --- a/libavdevice/utils.c
> +++ b/libavdevice/utils.c
Re: [FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration
Of course I did，and I can give you the bad case videos for your analysis if you need. How can I give them to you？ At 2019-11-28 14:38:34, "Carl Eugen Hoyos" wrote: > > >> Am 28.11.2019 um 03:34 schrieb manuelyuan : >> >> In this case, the input video is of dynamic frame rate and we don't want to >> duplicate or drop frames, but the output video duration calculated by DTS is >> incorrect, I solved it by using PTS. >> There are many UGC videos with dynamic frame rates, which are represented by >> PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output >> video duration becomes longer.By reading the code of x264/encoder/encoder.c, >> I found that in order to predict the B frame, x264 needs to ensure that there >> are enough reference frames when DTS = 0, so the DTS of these reference >> frames >> will subtract the cache time. However, the cache time includes the part of >> PTS >> jumps, which results in the abnormal small DTS. > >Do you have access to a stream analyser to verify the output file with your >patch? > >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 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 v5 2/4] lavc/libxavs2: optimize data access
ping the remaining three patches.
Thanks,
Huiwen Ren
At 2019-10-14 21:22:43, "hwren" wrote:
>Optimize data access from multiplication to iteration.
>
>Signed-off-by: hwren
>---
> libavcodec/libxavs2.c | 45 +
> 1 file changed, 29 insertions(+), 16 deletions(-)
>
>diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
>index 0179a1e..b5c07ec 100644
>--- a/libavcodec/libxavs2.c
>+++ b/libavcodec/libxavs2.c
>@@ -132,29 +132,42 @@ static av_cold int xavs2_init(AVCodecContext *avctx)
>
> static void xavs2_copy_frame_with_shift(xavs2_picture_t *pic, const AVFrame
> *frame, const int shift_in)
> {
>-int j, k;
>-for (k = 0; k < 3; k++) {
>-int i_stride = pic->img.i_stride[k];
>-for (j = 0; j < pic->img.i_lines[k]; j++) {
>-uint16_t *p_plane = (uint16_t *)&pic->img.img_planes[k][j *
>i_stride];
>-int i;
>-uint8_t *p_buffer = frame->data[k] + frame->linesize[k] * j;
>-memset(p_plane, 0, i_stride);
>-for (i = 0; i < pic->img.i_width[k]; i++) {
>-p_plane[i] = p_buffer[i] << shift_in;
>+uint16_t *p_plane;
>+uint8_t *p_buffer;
>+int wIdx;
>+int hIdx;
>+int plane;
>+
>+for (plane = 0; plane < 3; ++plane) {
>+p_plane = (uint16_t *)pic->img.img_planes[plane];
>+p_buffer = frame->data[plane];
>+for (hIdx = 0; hIdx < pic->img.i_lines[plane]; ++hIdx) {
>+memset(p_plane, 0, pic->img.i_stride[plane]);
>+for (wIdx = 0; wIdx < pic->img.i_width[plane]; ++wIdx) {
>+p_plane[wIdx] = p_buffer[wIdx] << shift_in;
> }
>+p_plane += pic->img.i_stride[plane];
>+p_buffer += frame->linesize[plane];
> }
> }
> }
>
> static void xavs2_copy_frame(xavs2_picture_t *pic, const AVFrame *frame)
> {
>-int j, k;
>-for (k = 0; k < 3; k++) {
>-for (j = 0; j < pic->img.i_lines[k]; j++) {
>-memcpy( pic->img.img_planes[k] + pic->img.i_stride[k] * j,
>-frame->data[k]+frame->linesize[k] * j,
>-pic->img.i_width[k] * pic->img.in_sample_size);
>+uint8_t *p_plane;
>+uint8_t *p_buffer;
>+int hIdx;
>+int plane;
>+int stride;
>+
>+for (plane = 0; plane < 3; ++plane) {
>+p_plane = pic->img.img_planes[plane];
>+p_buffer = frame->data[plane];
>+stride = pic->img.i_width[plane] * pic->img.in_sample_size;
>+for (hIdx = 0; hIdx < pic->img.i_lines[plane]; ++hIdx) {
>+memcpy(p_plane, p_buffer, stride);
>+p_plane += pic->img.i_stride[plane];
>+p_buffer += frame->linesize[plane];
> }
> }
> }
>--
>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".
___
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: Add tonemap vaapi filter for H2S
> -Original Message-
> From: ffmpeg-devel On Behalf Of Song,
> Ruiling
> Sent: Thursday, November 28, 2019 5:39 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for
> H2S
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Carl
> > Eugen Hoyos
> > Sent: Thursday, November 28, 2019 5:16 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi
> > filter for H2S
> >
> > Am Do., 28. Nov. 2019 um 07:56 Uhr schrieb Song, Ruiling
> > :
> >
> > > > > Am 28.11.2019 um 06:37 schrieb Sun, Xinpeng
> > :
> > > > >
> > > > >>>
> > > > >>> +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> > > > >>> +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as
> > > > >>> + input
> > for
> > > > vaapi tone-mapping\n");
> > > > >>> +return AVERROR(EINVAL);
> > > > >>
> > > > >> Shouldn't this also accept unknown trc?
> > > > >> (With a warning)
> > > > >
> > > > > Sorry if I misunderstand "unknown trc". Did you mean the trc
> > undefined by
> > > > ffmpeg or the trc unsupported by the driver?
> > > >
> > > > My question is:
> > > > If input_frame->color_trc is AVCOL_TRC_UNSPECIFIED, will the above fail?
> > > > But shouldn’t the user be able to use the filter in this case?
> > >
> > > I am not sure if assuming the input is using SMPTE2084 sounds more
> > acceptable
> > > in case of unspecified? If yes, I think we can change as you suggested.
> >
> > (Me neither.)
> > A warning could be shown instead of failing.
Prompt the user that the input could only be HDR10 with a warning instead of
failing, which sounds good and makes sense.
I will fix it in the next version.
Thanks,
Xinpeng
> Adding a warning sound good idea. But in order to proceed the tone-mapping, a
> default input transfer-function need to be chosen, which I think we can use
> SMPTE2084 here.
Without any other comments on it, I will use SMPTE2084 as default input
transfer-function if input_frame->color_trc is AVCOL_TRC_UNSPECIFIED.
>
> Ruiling
> >
> > 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 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 v1 1/2] avformat/utils: make avformat_free_context safety
On Fri, Nov 29, 2019 at 8:21 AM Steven Liu wrote: > > set the AVformatContext to NULL use av_freep before > avformat_free_context return > > Suggested-by: Andreas Rheinhardt > Signed-off-by: Steven Liu This is an API and ABI change. You cannot do this. We would usually introduce a new function with the new signature and deprecate the old one, but I don't think its really worth it here. - Hendrik ___ 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 v1 1/2] avformat/utils: make avformat_free_context safety
Steven Liu:
> set the AVformatContext to NULL use av_freep before
> avformat_free_context return
>
> Suggested-by: Andreas Rheinhardt
> Signed-off-by: Steven Liu
> ---
> doc/examples/muxing.c| 2 +-
> doc/examples/remuxing.c | 2 +-
> doc/examples/transcode_aac.c | 4 ++--
> doc/examples/transcoding.c | 2 +-
> fftools/ffmpeg.c | 2 +-
> libavdevice/avdevice.c | 2 +-
> libavdevice/utils.c | 2 +-
> libavformat/avformat.h | 2 +-
> libavformat/dashdec.c| 4 ++--
> libavformat/dashenc.c| 2 +-
> libavformat/fifo.c | 2 +-
> libavformat/hdsenc.c | 2 +-
> libavformat/hls.c| 4 ++--
> libavformat/hlsenc.c | 4 ++--
> libavformat/img2enc.c| 6 +++---
> libavformat/mov.c| 2 +-
> libavformat/movenchint.c | 2 +-
> libavformat/mpegtsenc.c | 2 +-
> libavformat/mux.c| 2 +-
> libavformat/rtpenc_chain.c | 4 ++--
> libavformat/rtpenc_mpegts.c | 8
> libavformat/rtsp.c | 2 +-
> libavformat/sapenc.c | 2 +-
> libavformat/segment.c| 6 +++---
> libavformat/smoothstreamingenc.c | 2 +-
> libavformat/tee.c| 2 +-
> libavformat/tests/fifo_muxer.c | 2 +-
> libavformat/tests/movenc.c | 2 +-
> libavformat/utils.c | 10 +-
> libavformat/webm_chunk.c | 2 +-
> tools/target_dem_fuzzer.c| 2 +-
> tools/uncoded_frame.c| 2 +-
> 32 files changed, 48 insertions(+), 48 deletions(-)
>
> diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
> index 9af9aae483..a151f9cd67 100644
> --- a/doc/examples/muxing.c
> +++ b/doc/examples/muxing.c
> @@ -661,7 +661,7 @@ int main(int argc, char **argv)
> avio_closep(&oc->pb);
>
> /* free the stream */
> -avformat_free_context(oc);
> +avformat_free_context(&oc);
>
> return 0;
> }
> diff --git a/doc/examples/remuxing.c b/doc/examples/remuxing.c
> index 9e4d1031b4..fce66c3d80 100644
> --- a/doc/examples/remuxing.c
> +++ b/doc/examples/remuxing.c
> @@ -178,7 +178,7 @@ end:
> /* close output */
> if (ofmt_ctx && !(ofmt->flags & AVFMT_NOFILE))
> avio_closep(&ofmt_ctx->pb);
> -avformat_free_context(ofmt_ctx);
> +avformat_free_context(&ofmt_ctx);
>
> av_freep(&stream_mapping);
>
> diff --git a/doc/examples/transcode_aac.c b/doc/examples/transcode_aac.c
> index e0c76f5b35..82c3610e39 100644
> --- a/doc/examples/transcode_aac.c
> +++ b/doc/examples/transcode_aac.c
> @@ -238,7 +238,7 @@ static int open_output_file(const char *filename,
> cleanup:
> avcodec_free_context(&avctx);
> avio_closep(&(*output_format_context)->pb);
> -avformat_free_context(*output_format_context);
> +avformat_free_context(output_format_context);
> *output_format_context = NULL;
> return error < 0 ? error : AVERROR_EXIT;
> }
> @@ -874,7 +874,7 @@ cleanup:
> avcodec_free_context(&output_codec_context);
> if (output_format_context) {
> avio_closep(&output_format_context->pb);
> -avformat_free_context(output_format_context);
> +avformat_free_context(&output_format_context);
> }
> if (input_codec_context)
> avcodec_free_context(&input_codec_context);
> diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
> index e48837cbd2..662dc7e02a 100644
> --- a/doc/examples/transcoding.c
> +++ b/doc/examples/transcoding.c
> @@ -611,7 +611,7 @@ end:
> avformat_close_input(&ifmt_ctx);
> if (ofmt_ctx && !(ofmt_ctx->oformat->flags & AVFMT_NOFILE))
> avio_closep(&ofmt_ctx->pb);
> -avformat_free_context(ofmt_ctx);
> +avformat_free_context(&ofmt_ctx);
>
> if (ret < 0)
> av_log(NULL, AV_LOG_ERROR, "Error occurred: %s\n", av_err2str(ret));
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 27f68933f8..c7fa6ccf44 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -539,7 +539,7 @@ static void ffmpeg_cleanup(int ret)
> s = of->ctx;
> if (s && s->oformat && !(s->oformat->flags & AVFMT_NOFILE))
> avio_closep(&s->pb);
> -avformat_free_context(s);
> +avformat_free_context(&s);
> av_dict_free(&of->opts);
>
> av_freep(&output_files[i]);
> diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
> index 72e1b67887..46a9e85c1d 100644
> --- a/libavdevice/avdevice.c
> +++ b/libavdevice/avdevice.c
> @@ -221,7 +221,7 @@ static int list_devices_for_context(AVFormatContext *s,
> AVDictionary *options,
> ret = avdevice_list_devices(s, device_list);
>fail:
> av_dict_free(&tmp);
> -avformat_free_context(s);
> +avformat_free_context(&s);
> return ret;
> }
>
> diff --git a/libavdevice/utils.c b/libavdevice/utils.c
> index ccd7318012..1b06387fd3 100644
> --- a/lib
