Re: [FFmpeg-devel] [PATCH v4 06/17] avcodec/libvpxenc: switch to get_supported_config()
On Wed, Sep 4, 2024 at 4:10 AM Niklas Haas wrote: > > From: Niklas Haas > > --- > libavcodec/libvpxenc.c | 26 +++--- > 1 file changed, 19 insertions(+), 7 deletions(-) > 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 03/10] MAINTAINERS: Add W field based on the linux kernel MAINTAINERs
On Wed, Aug 28, 2024 at 10:13 AM Michael Niedermayer wrote: > > Text was stolen from the linux kernel > This is thus identical to the kernel just a different more compact format. > I am very happy also to switch the file entirely to the format of the linux > kernel maintainer list > if people prefer > > This allows specifying a webpage for an area > > Signed-off-by: Michael Niedermayer > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8917b3be0f5..91075840d79 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -16,6 +16,7 @@ A (CC ) after the name means that the maintainer > prefers to be CC-ed on > patches and related discussions. > > (L ) *Mailing list* that is relevant to this area > +(W ) *Web-page* with status/info > address. ___ 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 6/9] avcodec/libvpxenc: Cleanup on error
On Sun, Jun 16, 2024 at 4:09 PM Michael Niedermayer wrote: > > This or fifo needs to be freed on errors explicitly > I have not verified that its always safe to call vpx_free() this needs to be > checked before applying this > It should be safe to call into libvpx whether the encoder init succeeded or not; av_freep() is most of the rest of the code. > Fixes: memleak > Fixes: > 68937/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVPX_VP8_fuzzer-4830831016214528 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/libvpxenc.c | 2 ++ > 1 file changed, 2 insertions(+) > 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 v12 0/8] [WIP] webp: add support for animated WebP decoding
On Tue, May 21, 2024 at 9:50 AM Thilo Borgmann via ffmpeg-devel wrote: > > Hi, > > [...] > >>> Tests mostly work for me. There are a few images (that I reported > >>> earlier) that give: > >> > >> thanks for testing! > >> > >> > >>> Canvas change detected. The output will be damaged. Use -threads 1 > >>> to try decoding with best effort. > >>> They don't animate without that option and with it render incorrectly. > >> > >> That issue yields from the canvas frame being the synchronization object > >> (ThreadFrame) - doing so prevents the canvas size changed mid-stream. > >> _Maybe_ this can be fixed switching the whole frame multithreading away > >> from ThreadFrame to sth else, not sure though and no experience with the > >> alternatives (AVExecutor?). Maybe Andreas can predict if it's > >> worth/valid to change that whole part of it? I'm not against putting > >> more effort into it to get it right. > > I could fix 488x488.webp and have an almost identical output to libwebp. > > 488x488.webp features an ARGB canvas and has both, ARGB & YUVA420P > p-frames. > > Do you have more files with other variations of canvas & p-frames? If > they at all exist... e.g. canvas YUV and p-frames RGB? > Sent a few created with `gif2webp -mixed` off list. A more exhaustive set can be created using cwebp and webpmux to assemble them. > Pinged Meta as well for real-world samples. Will take some more days > until I get feedback. Will then post the next iteration... > > Thanks, > Thilo ___ 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/libvpxenc: Fix parsing of ts_layering_mode parameter
Hi, On Wed, May 15, 2024 at 11:11 PM Aaron Thompson via ffmpeg-devel wrote: > > The value was being parsed as base 4, so the value "4" was invalid and > would result in ts_layering_mode being set to 0. > > Signed-off-by: Aaron Thompson > --- > libavcodec/libvpxenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > lgtm. Good catch. I applied this with a micro version bump. ___ 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 v12 0/8] [WIP] webp: add support for animated WebP decoding
On Thu, Apr 18, 2024 at 11:21 AM Thilo Borgmann via ffmpeg-devel wrote: > > Hi, > > On 17.04.24 00:52, James Zern via ffmpeg-devel wrote: > > On Wed, Apr 17, 2024 at 12:20 PM Thilo Borgmann via ffmpeg-devel > > wrote: > >> > >> From: Thilo Borgmann > >> > >> Marked WIP because we'd want to introduce private bsf's first; review > >> welcome before that though > >> VP8 decoder decoupled again > >> The whole animated sequence goes into one packet > >> The (currently public) bitstream filter splits animations up into > >> non-conformant packets > >> Now with XMP metadata support (as string, like MOV) > >> > > > > Tests mostly work for me. There are a few images (that I reported > > earlier) that give: > > thanks for testing! > > > >Canvas change detected. The output will be damaged. Use -threads 1 > > to try decoding with best effort. > > They don't animate without that option and with it render incorrectly. > > That issue yields from the canvas frame being the synchronization object > (ThreadFrame) - doing so prevents the canvas size changed mid-stream. > _Maybe_ this can be fixed switching the whole frame multithreading away > from ThreadFrame to sth else, not sure though and no experience with the > alternatives (AVExecutor?). Maybe Andreas can predict if it's > worth/valid to change that whole part of it? I'm not against putting > more effort into it to get it right. > > > > A few other notes: > > - should ffprobe report anything with files containing xmp? > > It does, it is put into the frame metadata as a blob. > ./ffprobe -show_frames > will reveal it. > Thanks. I didn't try that option. > > > - 0 duration behaves differently than web browsers, which use the gif > > behavior and set it to 10; as long as it's consistent in ffmpeg > > between the two either is fine to me. > > We are consistent to GIF in ffmpeg. Both do assume 100ms default delay. > Notice the defaults in their defines (ms for webp, fps for gif) in the > demuxers: > > #define WEBP_DEFAULT_DELAY 100 > #define GIF_DEFAULT_DELAY 10 > It doesn't seem the default delay is getting applied to this file: http://littlesvr.ca/apng/images/SteamEngine.webp Or at least the rendering is off in ffplay. The duration of all frames are 0 in that file. > > > > - The files in https://crbug.com/690848 don't exit cleanly from > > ffplay, other corrupt files do; ffmpeg exits, so maybe it's a > > non-issue. > > ffplay always crashes after any file on osx for me. If ffmpeg terminates > fine, it's a non-issue for that patchset. I'll however look into it once > I can, I hear people saying their ffplay not always crashes... > > Thanks! > -Thilo > ___ > 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 v12 0/8] [WIP] webp: add support for animated WebP decoding
On Wed, Apr 17, 2024 at 12:20 PM Thilo Borgmann via ffmpeg-devel wrote: > > From: Thilo Borgmann > > Marked WIP because we'd want to introduce private bsf's first; review > welcome before that though > VP8 decoder decoupled again > The whole animated sequence goes into one packet > The (currently public) bitstream filter splits animations up into > non-conformant packets > Now with XMP metadata support (as string, like MOV) > Tests mostly work for me. There are a few images (that I reported earlier) that give: Canvas change detected. The output will be damaged. Use -threads 1 to try decoding with best effort. They don't animate without that option and with it render incorrectly. A few other notes: - should ffprobe report anything with files containing xmp? - 0 duration behaves differently than web browsers, which use the gif behavior and set it to 10; as long as it's consistent in ffmpeg between the two either is fine to me. - The files in https://crbug.com/690848 don't exit cleanly from ffplay, other corrupt files do; ffmpeg exits, so maybe it's a non-issue. > > Patch 5/8 is still there for making changes in lavc/webp reviewable but shall > be stashed when pushing. > > -Thilo > > Josef Zlomek (2): > libavcodec/webp: add support for animated WebP > libavformat/webp: add WebP demuxer > > Thilo Borgmann via ffmpeg-devel (6): > avcodec/webp: remove unused definitions > avcodec/webp: separate VP8 decoding > avcodec/bsf: Add awebp2webp bitstream filter > avcodec/webp: make init_canvas_frame static > fate: add test for animated WebP > avcodec/webp: export XMP metadata > > Changelog | 2 + > configure | 1 + > doc/demuxers.texi | 28 + > libavcodec/bitstream_filters.c| 1 + > libavcodec/bsf/Makefile | 1 + > libavcodec/bsf/awebp2webp.c | 350 > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h | 2 +- > libavcodec/webp.c | 796 -- > libavformat/Makefile | 1 + > libavformat/allformats.c | 1 + > libavformat/version.h | 2 +- > libavformat/webpdec.c | 383 + > tests/fate/image.mak | 3 + > tests/ref/fate/exif-image-webp| 4 +- > tests/ref/fate/webp-anim | 22 + > tests/ref/fate/webp-rgb-lena-lossless | 2 +- > tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- > tests/ref/fate/webp-rgb-lossless | 2 +- > .../fate/webp-rgb-lossless-palette-predictor | 2 +- > tests/ref/fate/webp-rgb-lossy-q80 | 2 +- > tests/ref/fate/webp-rgba-lossless | 2 +- > tests/ref/fate/webp-rgba-lossy-q80| 2 +- > 23 files changed, 1530 insertions(+), 84 deletions(-) > create mode 100644 libavcodec/bsf/awebp2webp.c > create mode 100644 libavformat/webpdec.c > create mode 100644 tests/ref/fate/webp-anim > > -- > 2.43.0 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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 v11 4/8] libavcodec/webp: add support for animated WebP
On Thu, Mar 28, 2024 at 7:10 AM Thilo Borgmann via ffmpeg-devel wrote: > > From: Josef Zlomek > > Fixes: 4907 > > Adds support for decoding of animated WebP. > > The WebP decoder adds the animation related features according to the specs: > https://developers.google.com/speed/webp/docs/riff_container#animation > The frames of the animation may be smaller than the image canvas. > Therefore, the frame is decoded to a temporary frame, > then it is blended into the canvas, the canvas is copied to the output frame, > and finally the frame is disposed from the canvas. > > The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported. > The background color is specified only as BGRA in the WebP file > so it is converted to YUVA if YUV formats are output. > > Signed-off-by: Josef Zlomek > --- > Changelog | 1 + > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h| 2 +- > libavcodec/webp.c | 710 > 4 files changed, 653 insertions(+), 63 deletions(-) > I'm late trying to test these. I think these need to be rebased. version.h is easy enough to skip. I didn't look at the conflict in webp.c. error: patch failed: libavcodec/version.h:30 error: libavcodec/version.h: patch does not apply error: patch failed: libavcodec/webp.c:35 error: libavcodec/webp.c: patch does not apply Patch failed at 0004 libavcodec/webp: add support for animated WebP ___ 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 01/10] avcodec/libvpxenc: Avoid unused-variable warning if VP9 enc is disabled
On Mon, Apr 1, 2024 at 11:29 AM Andreas Rheinhardt
wrote:
>
> James Zern via ffmpeg-devel:
> > On Sat, Mar 30, 2024 at 10:30 PM Andreas Rheinhardt
> > wrote:
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavcodec/libvpxenc.c | 7 ---
> >> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> >> index 635cdf7a0e..bcbdc4981e 100644
> >> --- a/libavcodec/libvpxenc.c
> >> +++ b/libavcodec/libvpxenc.c
> >> @@ -49,6 +49,9 @@
> >> #include "libavutil/opt.h"
> >> #include "libavutil/pixdesc.h"
> >>
> >> +#define IS_VP9(avctx) (CONFIG_LIBVPX_VP9_ENCODER && avctx->codec_id ==
> >> AV_CODEC_ID_VP9)
> >> +#define IS_VP8(avctx) (CONFIG_LIBVPX_VP8_ENCODER && avctx->codec_id ==
> >> AV_CODEC_ID_VP8)
> >> +
> >> /**
> >> * Portion of struct vpx_codec_cx_pkt from vpx_encoder.h.
> >> * One encoded frame returned from the library.
> >> @@ -359,8 +362,7 @@ static int frame_data_submit(AVCodecContext *avctx,
> >> AVFifo *fifo,
> >> FrameData fd = { .pts = frame->pts };
> >> int ret;
> >>
> >> -#if CONFIG_LIBVPX_VP9_ENCODER
> >> -if (avctx->codec_id == AV_CODEC_ID_VP9 &&
> >> +if (IS_VP9(avctx) &&
> >
> > This works and I think the style is largely prevalent in other code.
> > Given the current structure you could move the enccfg declaration to
> > this block as an alternative.
>
> The latter would entail either opening a new block for the #if part or
> hoping (due to -Wdeclaration-after-statement) that this #if block stays
> at the start of this function. I prefer my approach above to either of
> these alternatives (a third alternative would be to avoid the enccfg
> variable altogether and to check ctx->encoder.config.enc->g_bit_depth
> instead; another alternative is av_unused). Just tell me which
> alternative you prefer.
>
I only made the comment because I didn't think it would need a new
block as it is, but you're right, code moves around. This is fine and
simpler than having a debate about the warning given the adoption of
other C99/C11 features.
___
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 01/10] avcodec/libvpxenc: Avoid unused-variable warning if VP9 enc is disabled
On Sat, Mar 30, 2024 at 10:30 PM Andreas Rheinhardt
wrote:
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libvpxenc.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 635cdf7a0e..bcbdc4981e 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -49,6 +49,9 @@
> #include "libavutil/opt.h"
> #include "libavutil/pixdesc.h"
>
> +#define IS_VP9(avctx) (CONFIG_LIBVPX_VP9_ENCODER && avctx->codec_id ==
> AV_CODEC_ID_VP9)
> +#define IS_VP8(avctx) (CONFIG_LIBVPX_VP8_ENCODER && avctx->codec_id ==
> AV_CODEC_ID_VP8)
> +
> /**
> * Portion of struct vpx_codec_cx_pkt from vpx_encoder.h.
> * One encoded frame returned from the library.
> @@ -359,8 +362,7 @@ static int frame_data_submit(AVCodecContext *avctx,
> AVFifo *fifo,
> FrameData fd = { .pts = frame->pts };
> int ret;
>
> -#if CONFIG_LIBVPX_VP9_ENCODER
> -if (avctx->codec_id == AV_CODEC_ID_VP9 &&
> +if (IS_VP9(avctx) &&
This works and I think the style is largely prevalent in other code.
Given the current structure you could move the enccfg declaration to
this block as an alternative.
> // Keep HDR10+ if it has bit depth higher than 8 and
> // it has PQ trc (SMPTE2084).
> enccfg->g_bit_depth > 8 && avctx->color_trc == AVCOL_TRC_SMPTE2084) {
> @@ -372,7 +374,6 @@ static int frame_data_submit(AVCodecContext *avctx,
> AVFifo *fifo,
> return AVERROR(ENOMEM);
> }
> }
> -#endif
>
> fd.duration = frame->duration;
> fd.frame_opaque = frame->opaque;
> --
> 2.40.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/6] avcodec/libvpxenc: Remove obsolete av_unused
On Tue, Mar 26, 2024 at 6:38 PM Andreas Rheinhardt wrote: > > Forgotten in 753074721bd414874d18c372c491bdc6323fa3bf. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/libvpxenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 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 1/6] avcodec/libvpxenc: Only search for side data when intending to use it
On Tue, Mar 26, 2024 at 6:36 PM Andreas Rheinhardt
wrote:
>
> Also rewrite the code so that a variable that is only used
> depending upon CONFIG_LIBVPX_VP9_ENCODER is not declared
> outside of the #if block.
> (The variable was declared with av_uninit, but it should have been
> av_unused, as the former does not work for all compilers.)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libvpxenc.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
lgtm.
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 4b89e47e83..ee903a4e5c 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -357,19 +357,20 @@ static int frame_data_submit(AVCodecContext *avctx,
> AVFifo *fifo,
> const struct vpx_codec_enc_cfg *enccfg = ctx->encoder.config.enc;
>
> FrameData fd = { .pts = frame->pts };
> -
> -AVFrameSideData *av_uninit(sd);
> int ret;
>
> #if CONFIG_LIBVPX_VP9_ENCODER
> -// Keep HDR10+ if it has bit depth higher than 8 and
> -// it has PQ trc (SMPTE2084).
> -sd = av_frame_get_side_data(frame, AV_FRAME_DATA_DYNAMIC_HDR_PLUS);
> -if (avctx->codec_id == AV_CODEC_ID_VP9 && sd &&
> +if (avctx->codec_id == AV_CODEC_ID_VP9 &&
> +// Keep HDR10+ if it has bit depth higher than 8 and
> +// it has PQ trc (SMPTE2084).
> enccfg->g_bit_depth > 8 && avctx->color_trc == AVCOL_TRC_SMPTE2084) {
> -fd.hdr10_plus = av_buffer_ref(sd->buf);
> -if (!fd.hdr10_plus)
> -return AVERROR(ENOMEM);
> +const AVFrameSideData *sd = av_frame_get_side_data(frame,
> AV_FRAME_DATA_DYNAMIC_HDR_PLUS);
> +
> +if (sd) {
> +fd.hdr10_plus = av_buffer_ref(sd->buf);
> +if (!fd.hdr10_plus)
> +return AVERROR(ENOMEM);
> +}
> }
> #endif
>
> --
> 2.40.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 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] lavc/libvpxenc: add screen-content-mode option
On Tue, Feb 13, 2024 at 7:26 PM James Zern wrote: > > On Mon, Feb 12, 2024 at 10:34 PM Dariusz Marcinkiewicz via > ffmpeg-devel wrote: > > > > This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx. > > > > Co-authored-by: Erik Språng > > Signed-off-by: Dariusz Marcinkiewicz > > --- > > doc/encoders.texi | 6 ++ > > libavcodec/libvpxenc.c | 13 + > > libavcodec/version.h | 2 +- > > 3 files changed, 20 insertions(+), 1 deletion(-) > > > > lgtm. I'll submit this soon if there are no other comments. > Applied. Thanks for the 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 v5] lavc/libvpxenc: add screen-content-mode option
On Mon, Feb 12, 2024 at 10:34 PM Dariusz Marcinkiewicz via ffmpeg-devel wrote: > > This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx. > > Co-authored-by: Erik Språng > Signed-off-by: Dariusz Marcinkiewicz > --- > doc/encoders.texi | 6 ++ > libavcodec/libvpxenc.c | 13 + > libavcodec/version.h | 2 +- > 3 files changed, 20 insertions(+), 1 deletion(-) > lgtm. I'll submit this soon if there are no other comments. > diff --git a/doc/encoders.texi b/doc/encoders.texi > index c9fe6d6143..13a7084512 100644 > --- a/doc/encoders.texi > +++ b/doc/encoders.texi > @@ -2237,6 +2237,12 @@ the two temporal layer 2 frames within the temporal > period. > @end table > @end table > > +@item VP8-specific options > +@table @option > +@item screen-content-mode > +Screen content mode, one of: (0) off, (1) screen, (2) screen with more > aggressive rate control. I swapped the ()s: 0 (off) ... ___ 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 v4] lavc/libvpxenc: add screen-content-mode option
On Sat, Feb 10, 2024 at 12:22 AM Dariusz Marcinkiewicz via
ffmpeg-devel wrote:
>
> This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
>
> Co-authored-by: Erik Språng
> Signed-off-by: Dariusz Marcinkiewicz
> ---
> doc/encoders.texi | 3 +++
> libavcodec/libvpxenc.c | 11 +++
> libavcodec/version.h | 2 +-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index c9fe6d6143..0868aa66db 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2150,6 +2150,9 @@ of quality.
> Set a change threshold on blocks below which they will be skipped by the
> encoder.
>
> +@item screen-content-mode
> +Screen content mode, one of: off (0), screen (1), screen with more
> aggressive rate control (2).
> +
Move this above 'VP9-specific options' and add a section for VP8. Also
reword this to '...one of: 0 (off), 1 (screen), ...'. The parameter is
an integer so should list that first, similar to aq-mode.
> @item slices (@emph{token-parts})
> Note that FFmpeg's @option{slices} option gives the total number of
> partitions,
> while @command{vpxenc}'s @option{token-parts} is given as
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 80988a2608..0d507beaae 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -102,6 +102,7 @@ typedef struct VPxEncoderContext {
> #define VP8F_AUTO_ALT_REF0x0002 ///< Enable automatic alternate
> reference frame generation
>
> int auto_alt_ref;
> +int screen_content_mode;
>
Move this above '// VP9-only' and add '// VP8-only'.
> [...]
> @@ -1946,6 +1956,7 @@ static const AVOption vp8_options[] = {
> { "auto-alt-ref","Enable use of alternate reference "
> "frames (2-pass only)",
> OFFSET(auto_alt_ref),AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE},
> { "cpu-used","Quality/Speed ratio modifier",
> OFFSET(cpu_used),AV_OPT_TYPE_INT, {.i64 = 1}, -16, 16, VE},
> +{ "screen-content-mode", "Encoder screen content mode",
> OFFSET(screen_content_mode), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE,
> "screen_content_mode"},
Remove the last item, "screen_content_mode". This no longer describes
a group of options.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavc/libvpxenc: add screen-content-mode option
On Thu, Feb 8, 2024 at 1:58 PM Dariusz Marcinkiewicz via ffmpeg-devel
wrote:
>
> This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx and makes
> us retry encode if screen_content_mode == 2 and no output was produced
> by encoder.
>
> Co-authored-by: Erik Språng
> Signed-off-by: Dariusz Marcinkiewicz
> ---
> doc/encoders.texi | 3 +++
> libavcodec/libvpxenc.c | 57 ++
> libavcodec/version.h | 2 +-
> 3 files changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index c9fe6d6143..0868aa66db 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2150,6 +2150,9 @@ of quality.
> Set a change threshold on blocks below which they will be skipped by the
> encoder.
>
> +@item screen-content-mode
> +Screen content mode, one of: off (0), screen (1), screen with more
> aggressive rate control (2).
> +
> @item slices (@emph{token-parts})
> Note that FFmpeg's @option{slices} option gives the total number of
> partitions,
> while @command{vpxenc}'s @option{token-parts} is given as
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 80988a2608..7571a8577a 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -114,6 +114,7 @@ typedef struct VPxEncoderContext {
> int crf;
> int static_thresh;
> int max_intra_rate;
> +int screen_content_mode;
Move this to a VP8-only section similar to VP9.
> int rc_undershoot_pct;
> int rc_overshoot_pct;
>
> @@ -164,6 +165,7 @@ static const char *const ctlidstr[] = {
> [VP8E_SET_MAX_INTRA_BITRATE_PCT] = "VP8E_SET_MAX_INTRA_BITRATE_PCT",
> [VP8E_SET_SHARPNESS] = "VP8E_SET_SHARPNESS",
> [VP8E_SET_TEMPORAL_LAYER_ID] = "VP8E_SET_TEMPORAL_LAYER_ID",
> +[VP8E_SET_SCREEN_CONTENT_MODE] = "VP8E_SET_SCREEN_CONTENT_MODE",
> #if CONFIG_LIBVPX_VP9_ENCODER
> [VP9E_SET_LOSSLESS]= "VP9E_SET_LOSSLESS",
> [VP9E_SET_TILE_COLUMNS]= "VP9E_SET_TILE_COLUMNS",
> @@ -1262,6 +1264,16 @@ static av_cold int vpx_init(AVCodecContext *avctx,
> #endif
> }
> #endif
> +#ifdef VPX_CTRL_VP8E_SET_SCREEN_CONTENT_MODE
This control was available in libvpx 1.4.0, the minimum version
supported. You can remove this check.
> +if (avctx->codec_id == AV_CODEC_ID_VP8 && ctx->screen_content_mode >= 0)
> {
> + if (ctx->screen_content_mode == 2 && ctx->is_alpha) {
Indent is 4 spaces here and throughout the patch.
> [...]
>
> -coded_size = queue_frames(avctx, &ctx->encoder, &ctx->coded_frame_list,
> pkt);
> +coded_size = queue_frames(avctx, &ctx->encoder, &ctx->coded_frame_list,
> + pkt, ctx->is_alpha, &frame_enc);
> +if (avctx->codec_id == AV_CODEC_ID_VP8 && frame_enc == 0 &&
> +ctx->screen_content_mode == 2 && frame) {
> +// VP8 tuned for screen content with aggresive rate control -
> returned
aggressive.
> +// OK status code but produced no output, this indicates frame was
> +// rolled back due to bitrate overshoot - try to encode it again.
This is a little weird given there's no adjustment to the encoder. I
think this should be a separate patch at least. If the encoder decided
to drop the frame in this mode it seems like the right decision given
the setting description. If it works as part of the drop frames
threshold then maybe the recode should be in the library based on some
threshold.
> [...]
> @@ -1946,6 +1987,12 @@ static const AVOption vp8_options[] = {
> { "auto-alt-ref","Enable use of alternate reference "
> "frames (2-pass only)",
> OFFSET(auto_alt_ref),AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE},
> { "cpu-used","Quality/Speed ratio modifier",
> OFFSET(cpu_used),AV_OPT_TYPE_INT, {.i64 = 1}, -16, 16, VE},
> +#ifdef VPX_CTRL_VP8E_SET_SCREEN_CONTENT_MODE
> +{ "screen-content-mode", "Encoder screen content mode",
> OFFSET(screen_content_mode), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE,
> "screen_content_mode"},
> +{ "off", "Screen content mode off",0,
>AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 0, VE,
> "screen_content_mode"},
> +{ "on", "Screen content mode on", 0,
>AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 0, VE,
> "screen_content_mode"},
> +{ "on-agressive-rate-control", "Screen content mode on with aggressive
> rate control", 0,AV_OPT_TYPE_CONST, {.i64 = 2}, 0, 0, VE,
> "screen_content_mode"},
aggressive.
There's no string equivalent in vpxenc though, so this should probably
just be ints.
> +#endif
> LEGACY_OPTIONS
> { NULL }
> };
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 0fae3d06d3..4b618d740f 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -30,7 +30,7 @@
> #include "v
Re: [FFmpeg-devel] [PATCH v2] libavcodec: add tune_content option also for VP8.
Hi, On Wed, Feb 7, 2024 at 8:04 AM Dariusz Marcinkiewicz via ffmpeg-devel wrote: > > This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx. > For the subject use '(libavcodec|avcodec|lavc)/libvpxenc: ...' to better document what is being changed. See the history of the file for examples. > Changes since v1: > - Put the new param initialzation in the right place, > - Account for cases when the encoder's output is queued up. > This is better left as a comment in the thread. It will lose its meaning when committed. > Co-authored-by: Erik Språng > Signed-off-by: Dariusz Marcinkiewicz > --- > doc/encoders.texi | 7 -- > libavcodec/libvpxenc.c | 56 ++ Please bump LIBAVCODEC_VERSION_MICRO in libavcodec/version.h. > 2 files changed, 56 insertions(+), 7 deletions(-) > > diff --git a/doc/encoders.texi b/doc/encoders.texi > index c9fe6d6143..2a9b38f62a 100644 > --- a/doc/encoders.texi > +++ b/doc/encoders.texi > @@ -2186,6 +2186,11 @@ Enable error resiliency features. > Increase sharpness at the expense of lower PSNR. > The valid range is [0, 7]. > > +@item tune-content Please match the vpxenc command line. They're separate, vp8 has --screen-content-mode. ___ 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] avcodec/libvpxdec: Remove redundant unreferencing of AVFrame
On Mon, Sep 18, 2023 at 5:40 AM Andreas Rheinhardt
wrote:
>
> The AVFrame of a decoder with the ordinary decode callback
> is generically unreferenced on error.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libvpxdec.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
lgtm.
> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> index 72ef5fa9a7..c6187fd5a1 100644
> --- a/libavcodec/libvpxdec.c
> +++ b/libavcodec/libvpxdec.c
> @@ -317,10 +317,8 @@ static int vpx_decode(AVCodecContext *avctx, AVFrame
> *picture,
> return AVERROR(ENOMEM);
> if (ctx->has_alpha_channel) {
> picture->buf[1] = av_buffer_ref(img_alpha->fb_priv);
> -if (!picture->buf[1]) {
> -av_frame_unref(picture);
> +if (!picture->buf[1])
> return AVERROR(ENOMEM);
> -}
> }
> for (int i = 0; i < 4; i++) {
> picture->data[i] = planes[i];
> --
> 2.34.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 v4 0/7] webp: add support for animated WebP decoding
On Thu, Jul 27, 2023 at 4:29 AM Thilo Borgmann wrote: > > Am 25.07.23 um 22:14 schrieb James Zern: > > On Tue, Jul 25, 2023 at 1:58 AM Thilo Borgmann > > wrote: > >> > >> Still images fixed from v2. Now includes a fate test for animated webp. > >> > >> Patch 5/7 is still there for making changes in lavc/webp reviewable but > >> shall be stashed when pushing. > >> > >> -Thilo > >> > >> > >> Josef Zlomek (2): > >>libavcodec/webp: add support for animated WebP decoding > >>libavformat/webp: add WebP demuxer > >> > >> Thilo Borgmann (5): > >>avcodec/webp: move definitions into header > >>avcodec/webp: remove unused definitions > >>avcodec/webp_parser: parse each frame into one packet > >>avcodec/webp: make init_canvas_frame static > >>fate: add test for animated WebP > >> > >> Changelog | 2 + > >> doc/demuxers.texi | 28 + > >> libavcodec/codec_desc.c | 3 +- > >> libavcodec/version.h| 2 +- > >> libavcodec/webp.c | 715 +-- > >> libavcodec/webp.h | 38 + > >> libavcodec/webp_parser.c| 130 ++-- > >> libavformat/Makefile| 1 + > >> libavformat/allformats.c| 1 + > >> libavformat/version.h | 2 +- > >> libavformat/webpdec.c | 733 > >> tests/fate/image.mak| 3 + > >> tests/ref/fate/exif-image-webp | 12 +- > >> tests/ref/fate/webp-anim| 22 + > >> tests/ref/fate/webp-rgb-lena-lossless | 2 +- > >> tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- > >> tests/ref/fate/webp-rgb-lossless| 2 +- > >> tests/ref/fate/webp-rgb-lossy-q80 | 2 +- > >> tests/ref/fate/webp-rgba-lossless | 2 +- > >> tests/ref/fate/webp-rgba-lossy-q80 | 2 +- > >> 20 files changed, 1589 insertions(+), 115 deletions(-) > >> create mode 100644 libavcodec/webp.h > >> create mode 100644 libavformat/webpdec.c > >> create mode 100644 tests/ref/fate/webp-anim > >> > > > > This series is lgtm. There are still a few edge cases where > > > 1) the > > 'Canvas change detected' warning will be triggered with valid files, > > As long as the canvas in frame threading is bound to a ThreadFrame, we can't > reallocate for changes. > Wouldn't want to touch that until the new threading is all done. > > > > 2) corrupt / truncated files will produce output where they would fail > > with libwebp and > > We might bail out as well though AFAICT we usually try to decode whatever > might be possible. > > > > 3) I see quite a few "[webp @ 0x7f5530008c00] > > Multiple ff_thread_finish_setup() calls", not sure if that's expected. > > Which sample you're looking at? > > If I can reproduce this, I'll look at it. The other things I'd keep as they > are. > I see this with: https://www.gstatic.com/webp/gallery3/1_webp_a.webp Using an animation it seems to be output once per frame. ___ 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 v4 3/7] avcodec/webp_parser: parse each frame into one packet
On Wed, Jul 26, 2023 at 2:36 PM Tomas Härdin wrote: > > tis 2023-07-25 klockan 16:18 +0200 skrev Thilo Borgmann: > > Am 25.07.23 um 14:24 schrieb Tomas Härdin: > > > > +// Extremely simplified key frame detection: > > > > +// - the first frame (containing headers) is marked as a key > > > > frame > > > > +// - other frames are marked as non-key frames > > > > > > Is there a more proper way of doing this? > > > > All frames (except the ANMF chunks) are INTRA, and all of them have a > > WEBP tag. > > Whereas all ANMF chunks are in the same WEBP chunk as their reference > > frame. > > So it should really be as simple as it is to mark all WEBP frames as > > key frames as the code does. > > What more dedicated do you have in mind? > > Nah mostly just curious. It just feels so weird when VP8 intra already > exists. Maybe I'm missing something. Browsers already support VP8 after > all. > We wanted something lighter weight (memory, cpu) for an image format rather than going full blown video. Lossless also factored into this. > > The logic as-is works with all samples I have, animated and not. > > Seems to also align well with their example file layouts. > > You have a more weird one? > > Nope ___ 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 v4 0/7] webp: add support for animated WebP decoding
On Tue, Jul 25, 2023 at 1:58 AM Thilo Borgmann wrote: > > Still images fixed from v2. Now includes a fate test for animated webp. > > Patch 5/7 is still there for making changes in lavc/webp reviewable but > shall be stashed when pushing. > > -Thilo > > > Josef Zlomek (2): > libavcodec/webp: add support for animated WebP decoding > libavformat/webp: add WebP demuxer > > Thilo Borgmann (5): > avcodec/webp: move definitions into header > avcodec/webp: remove unused definitions > avcodec/webp_parser: parse each frame into one packet > avcodec/webp: make init_canvas_frame static > fate: add test for animated WebP > > Changelog | 2 + > doc/demuxers.texi | 28 + > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h| 2 +- > libavcodec/webp.c | 715 +-- > libavcodec/webp.h | 38 + > libavcodec/webp_parser.c| 130 ++-- > libavformat/Makefile| 1 + > libavformat/allformats.c| 1 + > libavformat/version.h | 2 +- > libavformat/webpdec.c | 733 > tests/fate/image.mak| 3 + > tests/ref/fate/exif-image-webp | 12 +- > tests/ref/fate/webp-anim| 22 + > tests/ref/fate/webp-rgb-lena-lossless | 2 +- > tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- > tests/ref/fate/webp-rgb-lossless| 2 +- > tests/ref/fate/webp-rgb-lossy-q80 | 2 +- > tests/ref/fate/webp-rgba-lossless | 2 +- > tests/ref/fate/webp-rgba-lossy-q80 | 2 +- > 20 files changed, 1589 insertions(+), 115 deletions(-) > create mode 100644 libavcodec/webp.h > create mode 100644 libavformat/webpdec.c > create mode 100644 tests/ref/fate/webp-anim > This series is lgtm. There are still a few edge cases where 1) the 'Canvas change detected' warning will be triggered with valid files, 2) corrupt / truncated files will produce output where they would fail with libwebp and 3) I see quite a few "[webp @ 0x7f5530008c00] Multiple ff_thread_finish_setup() calls", not sure if that's expected. ___ 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 v4 3/7] avcodec/webp_parser: parse each frame into one packet
On Tue, Jul 25, 2023 at 7:18 AM Thilo Borgmann wrote: > > Am 25.07.23 um 14:24 schrieb Tomas Härdin: > >> +// Extremely simplified key frame detection: > >> +// - the first frame (containing headers) is marked as a key > >> frame > >> +// - other frames are marked as non-key frames > > > > Is there a more proper way of doing this? > > All frames (except the ANMF chunks) are INTRA, and all of them have a WEBP > tag. > Whereas all ANMF chunks are in the same WEBP chunk as their reference frame. > So it should really be as simple as it is to mark all WEBP frames as key > frames as the code does. > What more dedicated do you have in mind? > > The logic as-is works with all samples I have, animated and not. > Seems to also align well with their example file layouts. > You have a more weird one? > > > > Looking briefly at the spec > > one wonders why they didn't just use regular VP* inter frames.. > > I assume the whole canvas idea could be more beneficial than vp8 inter - but > otoh I don't know about vp8 compositing capabilities, if any.. > This was more in alignment with gif and allowed for a simpler reference structure. WebP also supports lossless and mixing lossy/lossless so this method makes the behavior consistent between VP8 and VP8L. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 0/6] webp: add support for animated WebP decoding
On Thu, Jul 20, 2023 at 4:08 PM Thilo Borgmann wrote: > > All issues of v2 fixed. Makes tsan happy now as well. > > Patch 5/6 is still there for making changes in lavc/webp reviewable but > shall be stashed when pushing. > This looks to fail fate: https://patchwork.ffmpeg.org/check/83180/ It seems to regress on still images: https://www.gstatic.com/webp/gallery3/1_webp_a.webp [webp @ 0x555880fd3040] [IMGUTILS @ 0x7f34f04a8ce0] Picture size 0x0 is invalid > -Thilo > > Josef Zlomek (2): > libavcodec/webp: add support for animated WebP decoding > libavformat/webp: add WebP demuxer > > Thilo Borgmann (4): > avcodec/webp: move definitions into header > avcodec/webp: remove unused definitions > avcodec/webp_parser: parse each frame into one packet > avcodec/webp: make init_canvas_frame static > > Changelog | 2 + > doc/demuxers.texi | 28 + > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h| 2 +- > libavcodec/webp.c | 714 +-- > libavcodec/webp.h | 38 + > libavcodec/webp_parser.c| 130 ++-- > libavformat/Makefile| 1 + > libavformat/allformats.c| 1 + > libavformat/version.h | 2 +- > libavformat/webpdec.c | 733 > tests/ref/fate/exif-image-webp | 12 +- > tests/ref/fate/webp-rgb-lena-lossless | 2 +- > tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- > tests/ref/fate/webp-rgb-lossless| 2 +- > tests/ref/fate/webp-rgb-lossy-q80 | 2 +- > tests/ref/fate/webp-rgba-lossless | 2 +- > tests/ref/fate/webp-rgba-lossy-q80 | 2 +- > 18 files changed, 1563 insertions(+), 115 deletions(-) > create mode 100644 libavcodec/webp.h > create mode 100644 libavformat/webpdec.c > > -- > 2.37.1 (Apple Git-137.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 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] Build failure un Debian Testing
On Fri, Jul 14, 2023 at 10:47 AM James Almer wrote:
>
> On 7/14/2023 1:49 PM, James Zern wrote:
> > On Fri, Jul 14, 2023 at 5:37 AM James Almer wrote:
> >>
> >> On 7/14/2023 7:12 AM, Nicolas George wrote:
> >>> James Almer (12023-07-13):
> >>>> Curious that they pull git snapshots of this package for Debian testing.
> >>>> For
> >>>> others they seem to stick to tagged releases.
> >>>
> >>> I do not understand what you mean. *I* pulled my work tree to the head
> >>> to fix a bug in the OpenGL device, it was the first time since Testing
> >>> was unfrozen, and I noticed it fails to build.
> >>
> >> I mean that for pretty much every other package, Debian Unstable/Testing
> >> sticks to tagged releases. But for this one they pull git snapshots
> >> every other day.
> >> If they did what the do for every other package, they'd have waited
> >> until binutils 2.41 was tagged.
> >>
> >>>
> >>>> This definitely sounds like a regression in binutils, so other than
> >>>> reporting it upstream, i don't see much more we can do.
> >>>
> >>> It could also be a case where we have been using a slightly invalid and
> >>> unsupported construct. My knowledge of assembly stopped at the 386, so I
> >>> cannot tell which one it is, but I think the likeliness are balanced.
> >>> Somebody more skilled will look at it, hopefully.
> >>
> >> I'm not an expert, but i learned a bit of inline asm when i was porting
> >> some of it to nasm syntax.
> >>
> >> > static inline uint32_t NEG_USR32(uint32_t a, int8_t s){
> >> > __asm__ ("shrl %1, %0\n\t"
> >>
> >> Nothing to say here, it's just shr.
> >>
> >> > : "+r" (a)
> >>
> >> r means the first operand, %0, needs to be a register. The + means it's
> >> both input and output, meaning the value at the time of entering this
> >> block is not to be ignored/discarded, and the value at the time of
> >> leaving the block needs to be in a.
> >>
> >> > : "ic" ((uint8_t)(-s))
> >>
> >> i means this operand can be an immediate value, and c means it can also
> >> be the rcx/ecx/cx/cl register.
> >>
> >> According to https://www.felixcloutier.com/x86/sal:sar:shl:shr this is
> >> indeed correct.
> >>
> >
> > I think it wants I/J to constrain the size of the immediate.
> > https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html
>
> Are these arguments something added recently to GCC? Assuming this is
> the case, it would mean we're passing this function out of range values.
> But even then, binutil's as suddenly rejecting them when until now it
> seemingly just clipped or truncated them is a considerable breakage.
I/J have been around for a while:
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC180
I guess binutils got pickier after 2.40.
___
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/libvpxenc: prevent fifo from filling up
On Thu, Jul 13, 2023 at 12:38 PM James Zern wrote: > > On Fri, Jul 7, 2023 at 2:31 PM David Lemler wrote: > > > > Prevent the fifo used in encoding VPx videos from filling up and > > stopping encode when it reaches 21845 items, which happens when the > > video has more than that number of frames. > > > > Incorporated suggestion from James Zern to prevent calling > > frame_data_submit() at all when performing the first pass of a 2-pass > > encode so the fifo is not filled at all; replaces original patch which > > drained the fifo after filling to prevent it from becoming full. > > > > Fixes the regression originally introduced in > > 5bda4ec6c3cb6f286bb40dee4457c3c26e0f78cb > > > > Co-authored-by: James Zern > > Signed-off-by: David Lemler > > --- > > libavcodec/libvpxenc.c | 8 +--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > lgtm. I'll submit this soon if there aren't any further comments. > Note the patch is corrupt, but easily fixed. In the future try to use > git send-email or attach the output of git format-patch. Applied. Thanks for the 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] Build failure un Debian Testing
On Fri, Jul 14, 2023 at 5:37 AM James Almer wrote:
>
> On 7/14/2023 7:12 AM, Nicolas George wrote:
> > James Almer (12023-07-13):
> >> Curious that they pull git snapshots of this package for Debian testing.
> >> For
> >> others they seem to stick to tagged releases.
> >
> > I do not understand what you mean. *I* pulled my work tree to the head
> > to fix a bug in the OpenGL device, it was the first time since Testing
> > was unfrozen, and I noticed it fails to build.
>
> I mean that for pretty much every other package, Debian Unstable/Testing
> sticks to tagged releases. But for this one they pull git snapshots
> every other day.
> If they did what the do for every other package, they'd have waited
> until binutils 2.41 was tagged.
>
> >
> >> This definitely sounds like a regression in binutils, so other than
> >> reporting it upstream, i don't see much more we can do.
> >
> > It could also be a case where we have been using a slightly invalid and
> > unsupported construct. My knowledge of assembly stopped at the 386, so I
> > cannot tell which one it is, but I think the likeliness are balanced.
> > Somebody more skilled will look at it, hopefully.
>
> I'm not an expert, but i learned a bit of inline asm when i was porting
> some of it to nasm syntax.
>
> > static inline uint32_t NEG_USR32(uint32_t a, int8_t s){
> > __asm__ ("shrl %1, %0\n\t"
>
> Nothing to say here, it's just shr.
>
> > : "+r" (a)
>
> r means the first operand, %0, needs to be a register. The + means it's
> both input and output, meaning the value at the time of entering this
> block is not to be ignored/discarded, and the value at the time of
> leaving the block needs to be in a.
>
> > : "ic" ((uint8_t)(-s))
>
> i means this operand can be an immediate value, and c means it can also
> be the rcx/ecx/cx/cl register.
>
> According to https://www.felixcloutier.com/x86/sal:sar:shl:shr this is
> indeed correct.
>
I think it wants I/J to constrain the size of the immediate.
https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html
> > );
> > return a;
> > }
>
> This is most likely a bug in the assembler. The "Error: operand type
> mismatch for 'shr'" error message makes me think it may be trying to use
> a register other than CL for the second operand.
>
> That said, i don't know if this asm block is needed at all, seeing how
> the generic C implementation is
>
> define NEG_USR32(a,s) (((uint32_t)(a))>>(32-(s)))
>
> Which the compiler can surely convert into whatever is most optimized
> for the target. The BMI2 instruction set added shrx, which accepts any
> register as second operand, for example.
___
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/libvpxenc: prevent fifo from filling up
On Fri, Jul 7, 2023 at 2:31 PM David Lemler wrote: > > Prevent the fifo used in encoding VPx videos from filling up and > stopping encode when it reaches 21845 items, which happens when the > video has more than that number of frames. > > Incorporated suggestion from James Zern to prevent calling > frame_data_submit() at all when performing the first pass of a 2-pass > encode so the fifo is not filled at all; replaces original patch which > drained the fifo after filling to prevent it from becoming full. > > Fixes the regression originally introduced in > 5bda4ec6c3cb6f286bb40dee4457c3c26e0f78cb > > Co-authored-by: James Zern > Signed-off-by: David Lemler > --- > libavcodec/libvpxenc.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > lgtm. I'll submit this soon if there aren't any further comments. Note the patch is corrupt, but easily fixed. In the future try to use git send-email or attach the output of git format-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 v2 5/5] libavformat/webp: add WebP demuxer
On Thu, Jul 6, 2023 at 4:28 AM Thilo Borgmann wrote:
>
> From: Josef Zlomek
>
> Adds the demuxer of animated WebP files.
> It supports non-animated, animated, truncated, and concatenated files.
> Reading from a pipe (and other non-seekable inputs) is also supported.
>
> The WebP demuxer splits the input stream into packets containing one frame.
> It also marks the key frames properly.
> The loop count is ignored by default (same behaviour as animated PNG and GIF),
> it may be enabled by the option '-ignore_loop 0'.
>
> The frame rate is set according to the frame delay in the ANMF chunk.
> If the delay is too low, or the image is not animated, the default frame rate
> is set to 10 fps, similarly to other WebP libraries and browsers.
> The fate suite was updated accordingly.
>
> Signed-off-by: Josef Zlomek
> ---
> Changelog | 1 +
> doc/demuxers.texi | 28 +
> libavformat/Makefile| 1 +
> libavformat/allformats.c| 1 +
> libavformat/version.h | 2 +-
> libavformat/webpdec.c | 733
> tests/ref/fate/webp-rgb-lena-lossless | 2 +-
> tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +-
> tests/ref/fate/webp-rgb-lossless| 2 +-
> tests/ref/fate/webp-rgb-lossy-q80 | 2 +-
> tests/ref/fate/webp-rgba-lossless | 2 +-
> tests/ref/fate/webp-rgba-lossy-q80 | 2 +-
> 12 files changed, 771 insertions(+), 7 deletions(-)
> create mode 100644 libavformat/webpdec.c
>
> [...]
> +switch (chunk_type) {
> +case MKTAG('R', 'I', 'F', 'F'):
> +if (avio_tell(pb) != wdc->file_start + 8) {
> +// premature RIFF found, shorten the file size
> +WebPHeaders *tmp =
> webp_headers_lower_or_equal(wdc->webp_headers,
> +
> wdc->num_webp_headers,
> +
> avio_tell(pb));
> +tmp->webp_size -= wdc->remaining_size;
> +wdc->remaining_size = 0;
[...]
> +
> +if (wdc->remaining_size > 0 && avio_feof(pb)) {
> +// premature EOF, shorten the file size
I'm not sure about this. If the file is truncated shouldn't this be
treated as an error?
___
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 4/5] avcodec/webp: make init_canvas_frame static
On Thu, Jul 6, 2023 at 4:28 AM Thilo Borgmann wrote: > > --- > libavcodec/webp.c | 143 +++--- > 1 file changed, 71 insertions(+), 72 deletions(-) > 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 v2 3/5] libavcodec/webp: add support for animated WebP decoding
On Thu, Jul 6, 2023 at 4:28 AM Thilo Borgmann wrote:
>
> From: Josef Zlomek
>
> Fixes: 4907
>
> Adds support for decoding of animated WebP.
>
> The WebP decoder adds the animation related features according to the specs:
> https://developers.google.com/speed/webp/docs/riff_container#animation
> The frames of the animation may be smaller than the image canvas.
> Therefore, the frame is decoded to a temporary frame,
> then it is blended into the canvas, the canvas is copied to the output frame,
> and finally the frame is disposed from the canvas.
>
> The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
> The background color is specified only as BGRA in the WebP file
> so it is converted to YUVA if YUV formats are output.
>
> Signed-off-by: Josef Zlomek
> ---
> Changelog | 1 +
> libavcodec/codec_desc.c | 3 +-
> libavcodec/version.h| 2 +-
> libavcodec/webp.c | 714
> 4 files changed, 658 insertions(+), 62 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index 3876082844..271926ed8f 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -25,6 +25,7 @@ version :
> - Raw VVC bitstream parser, muxer and demuxer
> - Bitstream filter for editing metadata in VVC streams
> - Bitstream filter for converting VVC from MP4 to Annex B
> +- animated WebP parser/decoder
>
> version 6.0:
> - Radiance HDR image support
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 4406dd8318..47a38a4036 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1259,8 +1259,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .type = AVMEDIA_TYPE_VIDEO,
> .name = "webp",
> .long_name = NULL_IF_CONFIG_SMALL("WebP"),
> -.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
> - AV_CODEC_PROP_LOSSLESS,
> +.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
The frames are all intra, though with animation they may be smaller
than the canvas and combined with the previous frame.
> .mime_types= MT("image/webp"),
> },
> {
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 9411511e04..9f55381cf1 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -30,7 +30,7 @@
> #include "version_major.h"
>
> #define LIBAVCODEC_VERSION_MINOR 22
> -#define LIBAVCODEC_VERSION_MICRO 100
> +#define LIBAVCODEC_VERSION_MICRO 101
>
> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> LIBAVCODEC_VERSION_MINOR, \
> diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> index 15152ec8fb..bee43fcf19 100644
> --- a/libavcodec/webp.c
> +++ b/libavcodec/webp.c
> @@ -35,12 +35,16 @@
> * Exif metadata
> * ICC profile
> *
> + * @author Josef Zlomek, Pexeso Inc.
> + * Animation
> + *
> * Unimplemented:
> - * - Animation
> * - XMP metadata
> */
>
> +#include "libavcodec/packet.h"
> #include "libavutil/imgutils.h"
> +#include "libavutil/colorspace.h"
>
> #define BITSTREAM_READER_LE
> #include "avcodec.h"
> @@ -178,6 +182,8 @@ typedef struct ImageContext {
> typedef struct WebPContext {
> VP8Context v; /* VP8 Context used for lossy
> decoding */
> GetBitContext gb; /* bitstream reader for main image
> chunk */
> +ThreadFrame canvas_frame; /* ThreadFrame for canvas */
> +AVFrame *frame; /* AVFrame for decoded frame */
> AVFrame *alpha_frame; /* AVFrame for alpha data
> decompressed from VP8L */
> AVPacket *pkt; /* AVPacket to be passed to the
> underlying VP8 decoder */
> AVCodecContext *avctx; /* parent AVCodecContext */
> @@ -189,9 +195,24 @@ typedef struct WebPContext {
> int alpha_data_size;/* alpha chunk data size */
> int has_exif; /* set after an EXIF chunk has been
> processed */
> int has_iccp; /* set after an ICCP chunk has been
> processed */
> -int width; /* image width */
> -int height; /* image height */
> -int lossless; /* indicates lossless or lossy */
> +int vp8x_flags; /* global flags from VP8X chunk */
> +int canvas_width; /* canvas width */
> +int canvas_height; /* canvas height */
> +int anmf_flags; /* frame flags from ANMF chunk */
> +int width; /* frame width */
> +int height; /* frame height */
> +int pos_x; /* frame position X */
> +int pos_y; /* frame position Y */
> +int prev_anmf_flags;/* previous frame flags from ANMF
> chunk */
> +int pr
Re: [FFmpeg-devel] [PATCH v2 2/5] avcodec/webp_parser: parse each frame into one packet
On Thu, Jul 6, 2023 at 4:28 AM Thilo Borgmann wrote:
>
> ---
> libavcodec/webp_parser.c | 132 ++-
> 1 file changed, 90 insertions(+), 42 deletions(-)
>
> [...]
> +} else {
> +/* read the next tag */
> +ctx->remaining_file_size--;
> +if (ctx->remaining_file_size == 0) {
> ctx->pc.frame_start_found = 0;
> continue;
> }
> ctx->pc.frame_start_found++;
> -ctx->remaining_size = ctx->fsize + i - 15;
> -if (ctx->pc.index + i > 15) {
> -next = i - 15;
> -state = 0;
> -break;
> -} else {
> -ctx->pc.state64 = 0;
> -goto restart;
> +if (ctx->pc.frame_start_found < 8)
> +continue;
> +
> +switch (state >> 32) {
> +case MKBETAG('A', 'N', 'M', 'F'):
> +case MKBETAG('V', 'P', '8', ' '):
> +case MKBETAG('V', 'P', '8', 'L'):
No indent on the case statements.
> +if (ctx->frame) {
> +ctx->frame = 0;
> +next = i - 8;
> +state = 0;
> +ctx->pc.frame_start_found = 0;
> +goto flush;
> +}
> +ctx->frame = 1;
> +break;
> +default:
> +break;
> }
> -} else if (ctx->pc.frame_start_found)
> -ctx->pc.frame_start_found++;
> -}
> -ctx->pc.state64 = state;
> -} else {
> -if (ctx->remaining_size) {
> -i = FFMIN(ctx->remaining_size, buf_size);
> -ctx->remaining_size -= i;
> -if (ctx->remaining_size)
> -goto flush;
>
> -ctx->pc.frame_start_found = 0;
> -goto restart;
> +ctx->remaining_tag_size = av_bswap32(state);
> +ctx->remaining_tag_size += ctx->remaining_tag_size & 1;
> +if (ctx->remaining_tag_size > ctx->remaining_file_size) {
> +/* this is probably trash at the end of file */
This would instead mean the file was truncated if remaining_tag_size
fits within the RIFF chunk size. Parsing also looks like it can
continue past the end of the RIFF chunk.
___
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/5] avcodec/webp: move definitions into header
On Thu, Jul 6, 2023 at 4:27 AM Thilo Borgmann wrote: > > --- > libavcodec/webp.c | 17 +-- > libavcodec/webp.h | 55 +++ > 2 files changed, 56 insertions(+), 16 deletions(-) > create mode 100644 libavcodec/webp.h > > [...] > +#define MAX_PALETTE_SIZE256 > +#define MAX_CACHE_BITS 11 > +#define NUM_CODE_LENGTH_CODES 19 > +#define HUFFMAN_CODES_PER_META_CODE 5 > +#define NUM_LITERAL_CODES 256 > +#define NUM_LENGTH_CODES24 > +#define NUM_DISTANCE_CODES 40 > +#define NUM_SHORT_DISTANCES 120 > +#define MAX_HUFFMAN_CODE_LENGTH 15 > + These are specific to lossless decoding and a few don't look used at all. I think they can stay within webp.c for now. ___ 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/libvpxenc: prevent fifo from filling up
On Wed, Jul 5, 2023 at 7:22 PM David Lemler wrote: > > > On 07/05/2023 2:16 PM CDT James Zern wrote: > > > > > > On Wed, Jul 5, 2023 at 12:15 PM James Zern wrote: > > > > > > Hi, > > > > > > > +ffmpeg-dev. I took the wrong email off the reply. > > > > > On Mon, Jul 3, 2023 at 10:08 PM David Lemler wrote: > > > > > > > > Prevent the fifo used in encoding VPx videos from filling up and > > > > stopping > > > > encode when it reaches 21845 items, which happens when the video has > > > > more > > > > than > > > > that number of frames. > > > > > > > > > > What failure do you see, a memory allocation error? 21845 sounds > > > somewhat arbitrary, maybe specific to your machine, so I'd leave it > > > off the comment and commit message. > > > > > When running a command like the following to perform the first pass of a > 2-pass VP9 encode: > > ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 0 -crf 31 -pass 1 -an \ > -deadline best -threads 8 -row-mt 1 -f null /dev/null > > ffmpeg exited with the error: > Error submitting video frame to the encoder > Conversion failed! > > and the ffmpeg2pass-0.log file existed but was empty. > > I've tested and reproduced the issue on Intel x86-64 on Windows > (10 22H2, gyan.dev build) and Linux (Debian 12, own compiled build), and on > AMD EPYC x86-64 on Linux (Debian 12, own compiled build). I believe the > number of frames is (1024 * 1024) / sizeof(FrameData); see lavc/libvpxenc.c > the call to av_fifo_alloc2 around line 999 and lavutil/fifo.c the assignment > of f->auto_grow_limit around line 72. I'm not sure if that calculation > would change on different systems/architectures. > Thanks for the explanation, I didn't look closely enough before making my comment. ___ 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/libvpxenc: prevent fifo from filling up
On Thu, Jul 6, 2023 at 12:45 AM Anton Khirnov wrote: > > Quoting James Zern (2023-07-05 21:16:37) > > On Wed, Jul 5, 2023 at 12:15 PM James Zern wrote: > > > > > > Hi, > > > > > > > +ffmpeg-dev. I took the wrong email off the reply. > > > > > On Mon, Jul 3, 2023 at 10:08 PM David Lemler wrote: > > > > > > > > Prevent the fifo used in encoding VPx videos from filling up and > > > > stopping > > > > encode when it reaches 21845 items, which happens when the video has > > > > more > > > > than > > > > that number of frames. > > > > > > > > > > What failure do you see, a memory allocation error? 21845 sounds > > > somewhat arbitrary, maybe specific to your machine, so I'd leave it > > > off the comment and commit message. > > > > > > > This problem occurs when performing the first pass of a 2-pass encode, > > > > as > > > > otherwise, the fifo is properly drained, preventing it from overflowing. > > > > > > > > Problem is fixed by manually draining the fifo when performing the first > > > > pass > > > > of a 2-pass encode. > > > > > > > > Fixes the regression originally introduced in > > > > 5bda4ec6c3cb6f286bb40dee4457c3c26e0f78cb > > > > > > > > > > Anton, any comments here? > > Is it guaranteed by the libvpx API that no encoded packets are returned > for the first pass of 2pass encoding? If so, then it probably makes most > sense not to send anything to the fifo in the first place. > You'll only get stats packets in the first pass, no frames. David, you can check `!(avctx->flags & AV_CODEC_FLAG_PASS1)` before calling `frame_data_submit()`. ___ 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 5/5] libavformat/webp: add WebP demuxer
On Thu, Jul 6, 2023 at 4:28 AM Thilo Borgmann wrote: > > From: Josef Zlomek > > Adds the demuxer of animated WebP files. > It supports non-animated, animated, truncated, and concatenated files. > Reading from a pipe (and other non-seekable inputs) is also supported. > > The WebP demuxer splits the input stream into packets containing one frame. > It also marks the key frames properly. > The loop count is ignored by default (same behaviour as animated PNG and GIF), > it may be enabled by the option '-ignore_loop 0'. > > The frame rate is set according to the frame delay in the ANMF chunk. > If the delay is too low, or the image is not animated, the default frame rate > is set to 10 fps, similarly to other WebP libraries and browsers. > The fate suite was updated accordingly. > > Signed-off-by: Josef Zlomek > --- > Changelog | 1 + > doc/demuxers.texi | 28 + > libavformat/Makefile| 1 + > libavformat/allformats.c| 1 + > libavformat/version.h | 2 +- > libavformat/webpdec.c | 733 > tests/ref/fate/webp-rgb-lena-lossless | 2 +- > tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- > tests/ref/fate/webp-rgb-lossless| 2 +- > tests/ref/fate/webp-rgb-lossy-q80 | 2 +- > tests/ref/fate/webp-rgba-lossless | 2 +- > tests/ref/fate/webp-rgba-lossy-q80 | 2 +- > 12 files changed, 771 insertions(+), 7 deletions(-) > create mode 100644 libavformat/webpdec.c > Looks like fate is breaking on fate-exif-image-webp with this change. I also noticed a few corrupt files could hang this. I'll send some examples. > [...] > +// fallback if VP8X chunk was not present > +if (!canvas_width && width > 0) > +canvas_width = width; > +if (!canvas_height && height > 0) > +canvas_height = height; > +} > + > +// WebP format operates with time in "milliseconds", therefore timebase > is 1/100 1/1000 ___ 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/libvpxenc: prevent fifo from filling up
On Wed, Jul 5, 2023 at 12:15 PM James Zern wrote:
>
> Hi,
>
+ffmpeg-dev. I took the wrong email off the reply.
> On Mon, Jul 3, 2023 at 10:08 PM David Lemler wrote:
> >
> > Prevent the fifo used in encoding VPx videos from filling up and stopping
> > encode when it reaches 21845 items, which happens when the video has more
> > than
> > that number of frames.
> >
>
> What failure do you see, a memory allocation error? 21845 sounds
> somewhat arbitrary, maybe specific to your machine, so I'd leave it
> off the comment and commit message.
>
> > This problem occurs when performing the first pass of a 2-pass encode, as
> > otherwise, the fifo is properly drained, preventing it from overflowing.
> >
> > Problem is fixed by manually draining the fifo when performing the first
> > pass
> > of a 2-pass encode.
> >
> > Fixes the regression originally introduced in
> > 5bda4ec6c3cb6f286bb40dee4457c3c26e0f78cb
> >
>
> Anton, any comments here?
>
> > Signed-off-by: David Lemler
> > ---
> > libavcodec/libvpxenc.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> > index 8833df2d68..e4ab13e6ab 100644
> > --- a/libavcodec/libvpxenc.c
> > +++ b/libavcodec/libvpxenc.c
> > @@ -1452,6 +1452,12 @@ static int queue_frames(AVCodecContext *avctx, struct
> > vpx_codec_ctx *encoder,
> > memcpy((uint8_t*)stats->buf + stats->sz,
> > pkt->data.twopass_stats.buf,
> > pkt->data.twopass_stats.sz);
> > stats->sz += pkt->data.twopass_stats.sz;
> > +/* Drain the fifo if it has any items in it to prevent it from
> > + filling up when performing the first pass of a 2-pass encode
> > if
> > + the video has more than 21845 frames. */
> > +if (av_fifo_can_read(ctx->fifo) > 0) {
>
> Another option would be to avoid calling frame_data_submit() in the first
> pass.
>
> > +av_fifo_drain2(ctx->fifo, 1);
> > +}
> > break;
> > }
> > case VPX_CODEC_PSNR_PKT:
> > --
> > 2.41.0.windows.1
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 2/2] lavc/libvpxenc: support creating full range output
On Sat, Jun 17, 2023 at 1:11 AM Thilo Borgmann wrote:
>
> suggested-by: ffm...@meta.com
> ---
> libavcodec/libvpxenc.c | 12
> 1 file changed, 12 insertions(+)
>
Looks like there's some discussion on the parent patch about the
correctness of adding this. This wrapper does set the color range to
full with AVCOL_RANGE_JPEG.
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 8833df2d68..6e8a0d07c3 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -799,21 +799,25 @@ static int set_pix_fmt(AVCodecContext *avctx,
> vpx_codec_caps_t codec_caps,
> enccfg->g_bit_depth = enccfg->g_input_bit_depth = desc->comp[0].depth;
> switch (avctx->pix_fmt) {
> case AV_PIX_FMT_YUV420P:
> +case AV_PIX_FMT_YUVJ420P:
> case AV_PIX_FMT_YUVA420P:
> enccfg->g_profile = 0;
> *img_fmt = VPX_IMG_FMT_I420;
> return 0;
> case AV_PIX_FMT_YUV422P:
> +case AV_PIX_FMT_YUVJ422P:
> enccfg->g_profile = 1;
> *img_fmt = VPX_IMG_FMT_I422;
> return 0;
> case AV_PIX_FMT_YUV440P:
> +case AV_PIX_FMT_YUVJ440P:
> enccfg->g_profile = 1;
> *img_fmt = VPX_IMG_FMT_I440;
> return 0;
> case AV_PIX_FMT_GBRP:
> ctx->vpx_cs = VPX_CS_SRGB;
> case AV_PIX_FMT_YUV444P:
> +case AV_PIX_FMT_YUVJ444P:
> enccfg->g_profile = 1;
> *img_fmt = VPX_IMG_FMT_I444;
> return 0;
> @@ -2054,20 +2058,28 @@ static av_cold int vp9_init(AVCodecContext *avctx)
>
> static const enum AVPixelFormat vp9_pix_fmts_highcol[] = {
> AV_PIX_FMT_YUV420P,
> +AV_PIX_FMT_YUVJ420P,
> AV_PIX_FMT_YUVA420P,
> AV_PIX_FMT_YUV422P,
> +AV_PIX_FMT_YUVJ422P,
> AV_PIX_FMT_YUV440P,
> +AV_PIX_FMT_YUVJ440P,
> AV_PIX_FMT_YUV444P,
> +AV_PIX_FMT_YUVJ444P,
> AV_PIX_FMT_GBRP,
> AV_PIX_FMT_NONE
> };
>
> static const enum AVPixelFormat vp9_pix_fmts_highbd[] = {
> AV_PIX_FMT_YUV420P,
> +AV_PIX_FMT_YUVJ420P,
> AV_PIX_FMT_YUVA420P,
> AV_PIX_FMT_YUV422P,
> +AV_PIX_FMT_YUVJ422P,
> AV_PIX_FMT_YUV440P,
> +AV_PIX_FMT_YUVJ440P,
> AV_PIX_FMT_YUV444P,
> +AV_PIX_FMT_YUVJ444P,
> AV_PIX_FMT_YUV420P10,
> AV_PIX_FMT_YUV422P10,
> AV_PIX_FMT_YUV440P10,
> --
> 2.37.1 (Apple Git-137.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 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 4/4] avcodec/webp: make init_canvas_frame static
On Thu, Jun 8, 2023 at 7:21 AM Thilo Borgmann wrote: > > --- > libavcodec/webp.c | 143 +++--- > 1 file changed, 71 insertions(+), 72 deletions(-) > 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 3/4] libavcodec/webp: add support for animated WebP decoding
On Thu, Jun 8, 2023 at 7:21 AM Thilo Borgmann wrote: > > From: Josef Zlomek > > Fixes: 4907 > > Adds support for decoding of animated WebP. > > The WebP decoder adds the animation related features according to the specs: > https://developers.google.com/speed/webp/docs/riff_container#animation > The frames of the animation may be smaller than the image canvas. > Therefore, the frame is decoded to a temporary frame, > then it is blended into the canvas, the canvas is copied to the output frame, > and finally the frame is disposed from the canvas. > > The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported. > The background color is specified only as BGRA in the WebP file > so it is converted to YUVA if YUV formats are output. > > Signed-off-by: Josef Zlomek > --- > Changelog | 1 + > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h| 2 +- > libavcodec/webp.c | 714 > 4 files changed, 658 insertions(+), 62 deletions(-) > > [...] > + > +bytestream2_skip(&gb, 2); // loop count is ignored TODO? APNG and GIF support looping and have -ignore_loop to control it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 0/4] webp: add support for animated WebP decoding
On Thu, Jun 8, 2023 at 7:20 AM Thilo Borgmann wrote: > > Follow-up to [1], the decoder only. > > In [1] we found a hanging sample. In frame-threading, this led to an > infinite wait, damaged frames otherwise. So warn acordingly and do > best-effort in single-thread mode. > > Also split into more patches to make reviewing easier. > > [1] http://ffmpeg.org/pipermail/ffmpeg-devel/2023-April/308965.html > > Josef Zlomek (1): > libavcodec/webp: add support for animated WebP decoding > > Thilo Borgmann (3): > avcodec/webp: move definitions into header > avcodec/webp_parser: parse each frame into one packet > avcodec/webp: make init_canvas_frame static > > Changelog| 1 + > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h | 2 +- > libavcodec/webp.c| 724 +++ > libavcodec/webp.h| 55 +++ > libavcodec/webp_parser.c | 132 --- > 6 files changed, 800 insertions(+), 117 deletions(-) > create mode 100644 libavcodec/webp.h > This has a few rendering / framerate issues. I'll send you some samples. ___ 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] avcodec/webp: move definitions into header
On Thu, Jun 8, 2023 at 7:20 AM Thilo Borgmann wrote: > > --- > libavcodec/webp.c | 17 +-- > libavcodec/webp.h | 55 +++ > 2 files changed, 56 insertions(+), 16 deletions(-) > create mode 100644 libavcodec/webp.h > 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 v2 5/5] aarch64: Add Windows runtime detection of the dotprod instructions
On Tue, May 30, 2023 at 5:31 AM Martin Storsjö wrote:
>
> For Windows, there's no publicly defined constant for checking for
> the i8mm extension yet.
> ---
> libavutil/aarch64/cpu.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
> index ffb00f6dd2..4b97530240 100644
> --- a/libavutil/aarch64/cpu.c
> +++ b/libavutil/aarch64/cpu.c
> @@ -94,6 +94,16 @@ static int detect_flags(void)
> return flags;
> }
>
> +#elif defined(_WIN32)
> +#include
> +
> +static int detect_flags(void)
> +{
> +int flags = 0;
> +if (IsProcessorFeaturePresent(PF_ARM_V82_DP_INSTRUCTIONS_AVAILABLE))
I think this requires a recent Windows SDK, is compatibility a concern?
lgtm otherwise.
___
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 11/13] lavc/libvpxenc: send frame durations to the encoder
On Tue, May 9, 2023 at 2:10 AM Anton Khirnov wrote:
>
> Adapt similar code from libaomenc - stop using ticks_per_frame except as
> a last resort.
> ---
> libavcodec/libvpxenc.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
lgtm.
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index a20e949842..f70cc87c41 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -1692,6 +1692,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
> *pkt,
> const struct vpx_codec_enc_cfg *enccfg = ctx->encoder.config.enc;
> vpx_svc_layer_id_t layer_id;
> int layer_id_valid = 0;
> +unsigned long duration = 0;
>
> if (avctx->qmax >= 0 && enccfg->rc_max_quantizer != avctx->qmax) {
> struct vpx_codec_enc_cfg cfg = *enccfg;
> @@ -1820,8 +1821,18 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
> *pkt,
> #endif
> }
>
> +if (frame && frame->duration > ULONG_MAX) {
> +av_log(avctx, AV_LOG_WARNING,
> + "Frame duration too large: %"PRId64"\n", frame->duration);
This could fall back to frame rate or ticks, but I imagine this case
would be unlikely in practice unless the timebase was quite large.
> +} else if (frame && frame->duration)
> +duration = frame->duration;
> +else if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
> +duration = av_rescale_q(1, av_inv_q(avctx->framerate),
> avctx->time_base);
> +else
> +duration = avctx->ticks_per_frame ? avctx->ticks_per_frame : 1;
> +
> res = vpx_codec_encode(&ctx->encoder, rawimg, timestamp,
> - avctx->ticks_per_frame, flags, ctx->deadline);
> + duration, flags, ctx->deadline);
> if (res != VPX_CODEC_OK) {
> log_encoder_error(avctx, "Error encoding frame");
> return AVERROR_INVALIDDATA;
> @@ -1829,7 +1840,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
> *pkt,
>
> if (ctx->is_alpha) {
> res = vpx_codec_encode(&ctx->encoder_alpha, rawimg_alpha, timestamp,
> - avctx->ticks_per_frame, flags, ctx->deadline);
> + duration, flags, ctx->deadline);
> if (res != VPX_CODEC_OK) {
> log_encoder_error(avctx, "Error encoding alpha frame");
> return AVERROR_INVALIDDATA;
> --
> 2.39.2
>
___
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] Add support for animated WebP
On Fri, May 5, 2023 at 10:47 AM Thilo Borgmann wrote: > > Am 27.04.23 um 20:08 schrieb Thilo Borgmann: > > Hi, > > > > support for animated WebP had been proposed twice in the past [1][2]. > > This did stall when Lynne called for some review on the demuxer in [1]. > > > > So these are the rebased patches from [1], pinging especially for demuxer > > review. > > Retested decoding with all files given in #4907. > > Demuxer needs testing, I just rebased it. > > Ping. > https://googlefonts.github.io/noto-emoji-animation/ is another source of animations. They may provide some useful disposal rectangles and alpha. Unrelated to those I'll send you an image that hangs ffplay/ffmpeg. Did these patches need an update after you got rid of the conflict markers? > > > [1] > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-September/269584.html > > [2] > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2021-September/285204.html > > -Thilo > ___ 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 11/13] lavc/libvpxenc: send frame durations to the encoder
On Sun, May 7, 2023 at 6:34 AM Anton Khirnov wrote:
>
> Adapt similar code from libaomenc - stop using ticks_per_frame except as
> a last resort.
> ---
> libavcodec/libvpxenc.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index a20e949842..a89497665b 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -1692,6 +1692,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
> *pkt,
> const struct vpx_codec_enc_cfg *enccfg = ctx->encoder.config.enc;
> vpx_svc_layer_id_t layer_id;
> int layer_id_valid = 0;
> +unsigned long duration;
>
> if (avctx->qmax >= 0 && enccfg->rc_max_quantizer != avctx->qmax) {
> struct vpx_codec_enc_cfg cfg = *enccfg;
> @@ -1820,8 +1821,18 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
> *pkt,
> #endif
> }
>
> +if (frame && frame->duration > ULONG_MAX) {
> +av_log(avctx, AV_LOG_WARNING,
> + "Frame duration too large: %"PRId64"\n", frame->duration);
duration would be left undefined in this case.
> +} else if (frame && frame->duration)
> +duration = frame->duration;
> +else if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
> +duration = av_rescale_q(1, av_inv_q(avctx->framerate),
> avctx->time_base);
> +else
> +duration = avctx->ticks_per_frame ? avctx->ticks_per_frame : 1;
> +
> res = vpx_codec_encode(&ctx->encoder, rawimg, timestamp,
> - avctx->ticks_per_frame, flags, ctx->deadline);
> + duration, flags, ctx->deadline);
> if (res != VPX_CODEC_OK) {
> log_encoder_error(avctx, "Error encoding frame");
> return AVERROR_INVALIDDATA;
> @@ -1829,7 +1840,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
> *pkt,
>
> if (ctx->is_alpha) {
> res = vpx_codec_encode(&ctx->encoder_alpha, rawimg_alpha, timestamp,
> - avctx->ticks_per_frame, flags, ctx->deadline);
> + duration, flags, ctx->deadline);
> if (res != VPX_CODEC_OK) {
> log_encoder_error(avctx, "Error encoding alpha frame");
> return AVERROR_INVALIDDATA;
> --
> 2.39.2
>
___
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] avcodec/libvpxdec: Constify VP9-decoder
On Sun, Mar 12, 2023 at 11:18 AM Andreas Rheinhardt wrote: > > Possible since 8d226fb9786f34760e80e0d6b403bd63e9ac4ddd. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/allcodecs.c | 2 +- > libavcodec/libvpxdec.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > 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 1/2] avcodec/libvpxdec: remove unnecessary init_static_data function
On Tue, Feb 28, 2023 at 1:20 PM James Zern wrote:
>
> On Tue, Feb 28, 2023 at 12:49 PM James Almer wrote:
> >
> > On 2/28/2023 5:40 PM, James Zern wrote:
> > > On Tue, Feb 28, 2023 at 4:07 AM James Almer wrote:
> > >>
> > >> It's used only by the encoder.
> > >>
> > >
> > > It sets AVCodec.pix_fmts, but maybe the values reported aren't used
> > > meaningfully.
> >
> > Indeed, they aren't. AVCodec.pix_fmts is a list of formats an encoder
> > accepts as input. Decoders don't use that array.
> >
>
> lgtm. The documentation for that field maybe could use some
> clarification. A few other decoders look to set this, h263dec being
> one.
>
For what it's worth, prior to this patch -h decoder=libvpx-vp9 would
display the supported formats:
Supported pixel formats: yuv420p yuva420p yuv422p yuv440p yuv444p
yuv420p10le yuv422p10le yuv440p10le yuv444p10le yuv420p12le
yuv422p12le yuv440p12le yuv444p12le gbrp gbrp10le gbrp12le
We used this in libvpx tests as one signal that --enable-vp9-bitdepth
builds were integrated correctly with ffmpeg. libaom has a similar
check. This is easy to update, though. The main point of those tests
is to ensure the build doesn't break.
> > >
> > >> Signed-off-by: James Almer
> > >> ---
> > >> libavcodec/libvpxdec.c | 1 -
> > >> 1 file changed, 1 deletion(-)
> > >>
> > >> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> > >> index 0ae19c3f72..8e6291fe20 100644
> > >> --- a/libavcodec/libvpxdec.c
> > >> +++ b/libavcodec/libvpxdec.c
> > >> @@ -391,6 +391,5 @@ FFCodec ff_libvpx_vp9_decoder = {
> > >> FF_CODEC_DECODE_CB(vpx_decode),
> > >> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
> > >> FF_CODEC_CAP_AUTO_THREADS,
> > >> -.init_static_data = ff_vp9_init_static,
> > >> };
> > >> #endif /* CONFIG_LIBVPX_VP9_DECODER */
> > >> --
> > >> 2.39.2
> > >>
> > > ___
> > > 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 1/2] avcodec/libvpxdec: remove unnecessary init_static_data function
On Tue, Feb 28, 2023 at 12:49 PM James Almer wrote:
>
> On 2/28/2023 5:40 PM, James Zern wrote:
> > On Tue, Feb 28, 2023 at 4:07 AM James Almer wrote:
> >>
> >> It's used only by the encoder.
> >>
> >
> > It sets AVCodec.pix_fmts, but maybe the values reported aren't used
> > meaningfully.
>
> Indeed, they aren't. AVCodec.pix_fmts is a list of formats an encoder
> accepts as input. Decoders don't use that array.
>
lgtm. The documentation for that field maybe could use some
clarification. A few other decoders look to set this, h263dec being
one.
> >
> >> Signed-off-by: James Almer
> >> ---
> >> libavcodec/libvpxdec.c | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> >> index 0ae19c3f72..8e6291fe20 100644
> >> --- a/libavcodec/libvpxdec.c
> >> +++ b/libavcodec/libvpxdec.c
> >> @@ -391,6 +391,5 @@ FFCodec ff_libvpx_vp9_decoder = {
> >> FF_CODEC_DECODE_CB(vpx_decode),
> >> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
> >> FF_CODEC_CAP_AUTO_THREADS,
> >> -.init_static_data = ff_vp9_init_static,
> >> };
> >> #endif /* CONFIG_LIBVPX_VP9_DECODER */
> >> --
> >> 2.39.2
> >>
> > ___
> > 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 8/8] lavc/libvpxenc: drop FrameListData.duration
On Tue, Feb 28, 2023 at 4:02 AM Anton Khirnov wrote: > > It is write-only. > --- > libavcodec/libvpxenc.c | 3 --- > 1 file changed, 3 deletions(-) > libaomenc.c transfers this to AVPacket. You added this in: 7cf161abe5 lavc/libaomenc: pass through frame durations to encoded packets Should the same be done here? ___ 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 6/8] lavc/libvpxenc: drop a useless condition
On Tue, Feb 28, 2023 at 4:02 AM Anton Khirnov wrote:
>
> A non-NULL packet is always passed to frame_data_apply().
> ---
> libavcodec/libvpxenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
lgtm
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index af16e53deb..33f35bbaf4 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -401,7 +401,7 @@ static int frame_data_apply(AVCodecContext *avctx, AVFifo
> *fifo, AVPacket *pkt)
> {
> FrameData fd;
> uint8_t *data;
> -if (!pkt || av_fifo_peek(fifo, &fd, 1, 0) < 0)
> +if (av_fifo_peek(fifo, &fd, 1, 0) < 0)
> return 0;
> if (fd.pts != pkt->pts)
> return 0;
> --
> 2.39.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 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 5/8] lavc/libvpxenc: handle frame durations and AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE
On Tue, Feb 28, 2023 at 4:01 AM Anton Khirnov wrote:
>
> ---
> libavcodec/libvpxenc.c | 139 +
> libavcodec/version.h | 2 +-
> 2 files changed, 100 insertions(+), 41 deletions(-)
>
lgtm
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 77921badba..af16e53deb 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -68,6 +68,14 @@ struct FrameListData {
>
> typedef struct FrameData {
> int64_t pts;
> +int64_t duration;
> +
> +#if FF_API_REORDERED_OPAQUE
> +int64_t reordered_opaque;
> +#endif
> +void*frame_opaque;
> +AVBufferRef *frame_opaque_ref;
> +
> AVBufferRef *hdr10_plus;
> } FrameData;
>
> @@ -329,32 +337,101 @@ static av_cold void free_frame_list(struct
> FrameListData *list)
> }
> }
>
> +static void frame_data_uninit(FrameData *fd)
> +{
> +av_buffer_unref(&fd->frame_opaque_ref);
> +av_buffer_unref(&fd->hdr10_plus);
> +}
> +
> static av_cold void fifo_free(AVFifo **fifo)
> {
> FrameData fd;
> while (av_fifo_read(*fifo, &fd, 1) >= 0)
> -av_buffer_unref(&fd.hdr10_plus);
> +frame_data_uninit(&fd);
> av_fifo_freep2(fifo);
> }
>
> -static int frame_data_apply(AVFifo *fifo, AVPacket *pkt)
> +static int frame_data_submit(AVCodecContext *avctx, AVFifo *fifo,
> + const AVFrame *frame)
> +{
> +VPxContext *ctx = avctx->priv_data;
> +const struct vpx_codec_enc_cfg *enccfg = ctx->encoder.config.enc;
> +
> +FrameDatafd = { .pts = frame->pts };
> +
The alignment of this declaration looks strange.
> +AVFrameSideData *av_uninit(sd);
> +int ret;
> +
> +#if CONFIG_LIBVPX_VP9_ENCODER
> +// Keep HDR10+ if it has bit depth higher than 8 and
> +// it has PQ trc (SMPTE2084).
Out of curiosity are there any HDR10+ files in fate?
> [...]
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 06631ffa8c..789d9047c2 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -30,7 +30,7 @@
> #include "version_major.h"
>
> #define LIBAVCODEC_VERSION_MINOR 4
> -#define LIBAVCODEC_VERSION_MICRO 100
> +#define LIBAVCODEC_VERSION_MICRO 101
>
This needs a rebase to apply cleanly.
___
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/8] lavc/libvpxenc: rename hdr10_plus_fifo and related objects
On Tue, Feb 28, 2023 at 4:02 AM Anton Khirnov wrote: > > This AVFifo is used to propagate HDR metadata from input frames to > output packets, since libvpx does not allow passing through arbitrary > user data. > > It will be extended to pass through other kinds of data in future > commits, so give it a more generic name. > --- > libavcodec/libvpxenc.c | 51 +- > 1 file changed, 26 insertions(+), 25 deletions(-) > 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 3/8] lavc/libvpxenc: reindent
On Tue, Feb 28, 2023 at 4:01 AM Anton Khirnov wrote:
>
> ---
> libavcodec/libvpxenc.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
lgtm.
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index eaa4ad8f25..abaa8c3513 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -1284,11 +1284,11 @@ static int storeframe(AVCodecContext *avctx, struct
> FrameListData *cx_frame,
> AV_WB64(side_data, 1);
> memcpy(side_data + 8, alpha_cx_frame->buf, alpha_cx_frame->sz);
> }
> -if (ctx->hdr10_plus_fifo) {
> -int err = copy_hdr10_plus_to_pkt(ctx->hdr10_plus_fifo, pkt);
> -if (err < 0)
> -return err;
> -}
> +if (ctx->hdr10_plus_fifo) {
> +int err = copy_hdr10_plus_to_pkt(ctx->hdr10_plus_fifo, pkt);
> +if (err < 0)
> +return err;
> +}
>
> return pkt->size;
> }
> --
> 2.39.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 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/8] lavc/libvpxenc: drop frame_number
On Tue, Feb 28, 2023 at 4:02 AM Anton Khirnov wrote:
>
> It is not used, except to check whether the packet is valid before
> writing HDR metadata to the packet in storeframe(). However, that check
> serves no purpose, as the encoded packet is already treated as valid
> higher up in this function.
lgtm. I agree, since the HDR path is VP9 only, there's no possibility
of having a separate alt-ref packet. The libaom wrapper could probably
use a similar update.
> ---
> libavcodec/libvpxenc.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 339d4d8146..eaa4ad8f25 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -63,7 +63,6 @@ struct FrameListData {
> uint32_t flags; /**< flags for this frame */
> uint64_t sse[4];
> int have_sse;/**< true if we have pending sse[] */
> -uint64_t frame_number;
> struct FrameListData *next;
> };
>
> @@ -84,7 +83,6 @@ typedef struct VPxEncoderContext {
> int deadline; //i.e., RT/GOOD/BEST
> uint64_t sse[4];
> int have_sse; /**< true if we have pending sse[] */
> -uint64_t frame_number;
> struct FrameListData *coded_frame_list;
> struct FrameListData *alpha_coded_frame_list;
>
> @@ -1220,9 +1218,8 @@ static inline void cx_pktcpy(struct FrameListData *dst,
> dst->sz = src->data.frame.sz;
> dst->buf = src->data.frame.buf;
> dst->have_sse = 0;
> -/* For alt-ref frame, don't store PSNR or increment frame_number */
> +/* For alt-ref frame, don't store PSNR */
> if (!(dst->flags & VPX_FRAME_IS_INVISIBLE)) {
> -dst->frame_number = ++ctx->frame_number;
> dst->have_sse = ctx->have_sse;
> if (ctx->have_sse) {
> /* associate last-seen SSE to the frame. */
> @@ -1232,8 +1229,6 @@ static inline void cx_pktcpy(struct FrameListData *dst,
> memcpy(dst->sse, ctx->sse, sizeof(dst->sse));
> ctx->have_sse = 0;
> }
> -} else {
> -dst->frame_number = -1; /* sanity marker */
> }
> }
>
> @@ -1289,13 +1284,11 @@ static int storeframe(AVCodecContext *avctx, struct
> FrameListData *cx_frame,
> AV_WB64(side_data, 1);
> memcpy(side_data + 8, alpha_cx_frame->buf, alpha_cx_frame->sz);
> }
> -if (cx_frame->frame_number != -1) {
> if (ctx->hdr10_plus_fifo) {
> int err = copy_hdr10_plus_to_pkt(ctx->hdr10_plus_fifo, pkt);
> if (err < 0)
> return err;
> }
> -}
>
> return pkt->size;
> }
> --
> 2.39.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 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] avcodec/libvpxdec: remove unnecessary init_static_data function
On Tue, Feb 28, 2023 at 4:07 AM James Almer wrote:
>
> It's used only by the encoder.
>
It sets AVCodec.pix_fmts, but maybe the values reported aren't used
meaningfully.
> Signed-off-by: James Almer
> ---
> libavcodec/libvpxdec.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> index 0ae19c3f72..8e6291fe20 100644
> --- a/libavcodec/libvpxdec.c
> +++ b/libavcodec/libvpxdec.c
> @@ -391,6 +391,5 @@ FFCodec ff_libvpx_vp9_decoder = {
> FF_CODEC_DECODE_CB(vpx_decode),
> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
>FF_CODEC_CAP_AUTO_THREADS,
> -.init_static_data = ff_vp9_init_static,
> };
> #endif /* CONFIG_LIBVPX_VP9_DECODER */
> --
> 2.39.2
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavc/libvpx: remove thread limit
On Tue, Jan 10, 2023 at 5:23 PM James Zern wrote: > > On Tue, Jan 10, 2023 at 2:47 AM myp...@gmail.com wrote: > > > > On Thu, Jan 5, 2023 at 6:42 PM Dmitrii Ovchinnikov > > wrote: > > [...] > > > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c > > > index 9aa5510c28..0627e13973 100644 > > > --- a/libavcodec/libvpxenc.c > > > +++ b/libavcodec/libvpxenc.c > > > @@ -942,7 +942,7 @@ static av_cold int vpx_init(AVCodecContext *avctx, > > > enccfg.g_timebase.num = avctx->time_base.num; > > > enccfg.g_timebase.den = avctx->time_base.den; > > > enccfg.g_threads = > > > -FFMIN(avctx->thread_count ? avctx->thread_count : > > > av_cpu_count(), 16); > > > +avctx->thread_count ? avctx->thread_count : av_cpu_count(); > > > enccfg.g_lag_in_frames= ctx->lag_in_frames; > > > > > Do you check the change with the old version libvpx? as I know, older > > versions libvpx setting the number of threads higher than 16 will > > cause a crash, so I think at least a version check needs to be added > > > > Do you have a bug or version in mind? There were some performance > regressions [1] over the releases and some issues with changing the > number of tiles, but I don't remember a crash for a high thread count > (though there have been plenty of crashes related to threads in > general [2]). The range check predates 1.4.0, which is the minimum > required by ffmpeg. > I merged the changes without a check. If there is a problem with a specific version we can add a check. > [1] https://crbug.com/webm/1574 > [2] https://crbug.com/webm/851 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavc/libvpx: remove thread limit
On Tue, Jan 10, 2023 at 2:47 AM myp...@gmail.com wrote: > > On Thu, Jan 5, 2023 at 6:42 PM Dmitrii Ovchinnikov > wrote: > [...] > > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c > > index 9aa5510c28..0627e13973 100644 > > --- a/libavcodec/libvpxenc.c > > +++ b/libavcodec/libvpxenc.c > > @@ -942,7 +942,7 @@ static av_cold int vpx_init(AVCodecContext *avctx, > > enccfg.g_timebase.num = avctx->time_base.num; > > enccfg.g_timebase.den = avctx->time_base.den; > > enccfg.g_threads = > > -FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), > > 16); > > +avctx->thread_count ? avctx->thread_count : av_cpu_count(); > > enccfg.g_lag_in_frames= ctx->lag_in_frames; > > > Do you check the change with the old version libvpx? as I know, older > versions libvpx setting the number of threads higher than 16 will > cause a crash, so I think at least a version check needs to be added > Do you have a bug or version in mind? There were some performance regressions [1] over the releases and some issues with changing the number of tiles, but I don't remember a crash for a high thread count (though there have been plenty of crashes related to threads in general [2]). The range check predates 1.4.0, which is the minimum required by ffmpeg. [1] https://crbug.com/webm/1574 [2] https://crbug.com/webm/851 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavc/libvpx: remove thread limit
On Thu, Jan 5, 2023 at 2:42 AM Dmitrii Ovchinnikov wrote: > > From: Dmitrii Ovchinnikov > > This change improves the performance and multicore > scalability of the vp9 codec for streaming single-pass encoded videos. The > current thread limit for ffmpeg codecs is 16 (MAX_AUTO_THREADS in > pthread_internal.h) due to a limitation in H.264 codec that prevents more > than 16 threads being used. > > Increasing the thread limit to 64 for vp9 improves > the performance for encoding 4K raw videos for streaming by up to 47% > compared to 16 threads, and from 20-30% for 32 threads, with the same quality > as measured by the VMAF score. > > Did not need to add a check for limit in libvpx as it is already present > in libvpx/vp9/vp9_cx_iface.c: > RANGE_CHECK_HI(cfg, g_threads, 64); > As demonstrated by following message when -threads is set to anything more > than 64 > [libvpx-vp9 @ 0x30ed380] Additional information: g_threads out of range > [..64] > The difference is that it will cause a failure rather than silently capping the value which might break some workflows. libaomenc caps at 64, so it may be best to match that implementation for now. I'll make that change before submitting unless there are other comments. With this change there will still be the misleading output from validate_thread_parameters() in pthread.c, though it's not a unique problem to libvpxenc: [libvpx-vp9 @ 0x5639aa4c0200] Application has requested 64 threads. Using a thread count greater than 16 is not recommended. ___ 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 05/31] avcodec/libvpxenc: use av_dict_iterate
On Sat, Nov 26, 2022 at 6:47 AM Marvin Scholz wrote:
>
> ---
> libavcodec/libvpxenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
lgtm.
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 667cffc200..9aa5510c28 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -900,7 +900,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
> vpx_codec_caps_t codec_caps = vpx_codec_get_caps(iface);
> vpx_svc_extra_cfg_t svc_params;
> #endif
> -AVDictionaryEntry* en = NULL;
> +const AVDictionaryEntry* en = NULL;
>
> av_log(avctx, AV_LOG_INFO, "%s\n", vpx_codec_version_str());
> av_log(avctx, AV_LOG_VERBOSE, "%s\n", vpx_codec_build_config());
> @@ -1072,7 +1072,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>
> enccfg.g_error_resilient = ctx->error_resilient || ctx->flags &
> VP8F_ERROR_RESILIENT;
>
> -while ((en = av_dict_get(ctx->vpx_ts_parameters, "", en,
> AV_DICT_IGNORE_SUFFIX))) {
> +while ((en = av_dict_iterate(ctx->vpx_ts_parameters, en))) {
> if (vpx_ts_param_parse(ctx, &enccfg, en->key, en->value,
> avctx->codec_id) < 0)
> av_log(avctx, AV_LOG_WARNING,
> "Error parsing option '%s = %s'.\n",
> --
> 2.37.0 (Apple Git-136)
>
> ___
> 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] lavc/libvpx: increase thread limit to 64
On Tue, Oct 25, 2022 at 8:56 AM Dmitrii Ovchinnikov wrote: > > >> Why do you still impose an upper limit unconditionally even if the > >>user has set his preferred number of threads? > Libvpx-vp9 does not support number of threads greater than 64, so we impose > an upper limit of 64. > E.g. if we set it any higher we get the following execution error: > [libvpx-vp9 @ 0x2f631c0] Failed to initialize encoder: Invalid parameter > [libvpx-vp9 @ 0x2f631c0] Additional information: g_threads out of range > [..64] > Error initializing output stream 0:0 -- Error while opening encoder for > output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, > width or height > Deferring the check to libvpx should be fine and would mean less maintenance of this wrapper if there are any changes made there. > >>According to > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-November/236406.html the > >>maximum of 16 has not been chosen because of H.264, but because there > >>was some form of restriction in libvpx. Or at least there was belief in > >>the existence of such a restriction. > There is a restriction of maximum 64 threads, not 16. > > >>This code potentially calls av_cpu_count() twice. > Can you please clarify how it calls it twice? 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] avcodec/libaomdec: fix pix_fmt w/AVCOL_SPC_RGB
On Tue, Oct 25, 2022 at 10:02 PM James Zern wrote: > > On Tue, Oct 25, 2022 at 11:28 AM James Zern wrote: > > > > Signed-off-by: James Zern > > --- > > libavcodec/libaomdec.c | 8 ++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > I was reminded that there was an earlier patch [1], which I had an > open comment on. I think it's better to be consistent with the > libdav1d wrapper and ffvp9/libvpx for now. > I pushed this. Any other fixes should try to keep both wrappers in sync. > [1] > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210606051612.89211-1-val.zapod...@gmail.com/ ___ 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] avcodec/libaomdec: fix pix_fmt w/AVCOL_SPC_RGB
On Tue, Oct 25, 2022 at 11:28 AM James Zern wrote: > > Signed-off-by: James Zern > --- > libavcodec/libaomdec.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > I was reminded that there was an earlier patch [1], which I had an open comment on. I think it's better to be consistent with the libdav1d wrapper and ffvp9/libvpx for now. [1] https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210606051612.89211-1-val.zapod...@gmail.com/ ___ 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/libaomdec: fix pix_fmt w/AVCOL_SPC_RGB
Signed-off-by: James Zern
---
libavcodec/libaomdec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 378d638a89..53982559d9 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -113,15 +113,19 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
aom_image *img)
case AOM_IMG_FMT_I444:
case AOM_IMG_FMT_I44416:
if (img->bit_depth == 8) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P;
+avctx->pix_fmt = avctx->colorspace == AVCOL_SPC_RGB ?
+ AV_PIX_FMT_GBRP : AV_PIX_FMT_YUV444P;
avctx->profile = FF_PROFILE_AV1_HIGH;
return 0;
} else if (img->bit_depth == 10) {
avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
+avctx->pix_fmt = avctx->colorspace == AVCOL_SPC_RGB ?
+ AV_PIX_FMT_GBRP10 : AV_PIX_FMT_YUV444P10;
avctx->profile = FF_PROFILE_AV1_HIGH;
return 0;
} else if (img->bit_depth == 12) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P12;
+avctx->pix_fmt = avctx->colorspace == AVCOL_SPC_RGB ?
+ AV_PIX_FMT_GBRP12 : AV_PIX_FMT_YUV444P12;
avctx->profile = FF_PROFILE_AV1_PROFESSIONAL;
return 0;
} else {
--
2.38.0.135.g90850a2211-goog
___
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/movenc: Write auxi box for animated AVIF with alpha
On Wed, Sep 21, 2022 at 12:14 PM James Zern wrote: > > On Tue, Sep 20, 2022 at 2:17 PM Vignesh Venkatasubramanian > wrote: > > > > According to the HEIF specification (ISO/IEC 23008-12) Section > > 7.5.3.1, tracks with handler_type 'auxv' must contain a 'auxi' box > > in its SampleEntry to notify the nature of the auxiliary track to the > > decoder. > > > > The content is the same as the 'auxC' box. So parameterize and re-use > > the existing function. > > > > Signed-off-by: Vignesh Venkatasubramanian > > --- > > libavformat/movenc.c | 27 +++ > > 1 file changed, 15 insertions(+), 12 deletions(-) > > > > lgtm. 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/movenc: Write auxi box for animated AVIF with alpha
On Tue, Sep 20, 2022 at 2:17 PM Vignesh Venkatasubramanian wrote: > > According to the HEIF specification (ISO/IEC 23008-12) Section > 7.5.3.1, tracks with handler_type 'auxv' must contain a 'auxi' box > in its SampleEntry to notify the nature of the auxiliary track to the > decoder. > > The content is the same as the 'auxC' box. So parameterize and re-use > the existing function. > > Signed-off-by: Vignesh Venkatasubramanian > --- > libavformat/movenc.c | 27 +++ > 1 file changed, 15 insertions(+), 12 deletions(-) > 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] avformat/movenc: Write auxi box for animated AVIF with alpha
On Mon, Sep 19, 2022 at 4:03 PM Vignesh Venkatasubramanian wrote: > > According to the HEIF specification Section 7.5.3.1, tracks with It might be worth adding ISO/IEC 23008-12 for added precision. > handler_type 'auxv' must contain a 'auxi' box in its > SampleEntry to notify the nature of the auxiliary track to the > decoder. > > The content is the same as the 'auxC' box. So paramterize and re-use parameterize > the existing function. > > Signed-off-by: Vignesh Venkatasubramanian > --- > libavformat/movenc.c | 27 +++ > 1 file changed, 15 insertions(+), 12 deletions(-) > 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".
[FFmpeg-devel] [PATCH] avcodec/libvpxenc: add -min-gf-interval
this maps to the vpxenc argument with the same name and the
VP9E_SET_MIN_GF_INTERVAL codec control
Signed-off-by: James Zern
---
doc/encoders.texi | 2 ++
libavcodec/libvpxenc.c | 11 +++
libavcodec/version.h | 2 +-
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index ac71f50ad2..5a5579d5e5 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2176,6 +2176,8 @@ Set altref noise reduction filter type: backward,
forward, centered.
Set altref noise reduction filter strength.
@item rc-lookahead, lag-in-frames (@emph{lag-in-frames})
Set number of frames to look ahead for frametype and ratecontrol.
+@item min-gf-interval
+Set minimum golden/alternate reference frame interval (VP9 only).
@end table
@item error-resilient
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 09b56aae2a..667cffc200 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -131,6 +131,7 @@ typedef struct VPxEncoderContext {
int tune_content;
int corpus_complexity;
int tpl_model;
+int min_gf_interval;
AVFifo *hdr10_plus_fifo;
/**
* If the driver does not support ROI then warn the first time we
@@ -186,6 +187,9 @@ static const char *const ctlidstr[] = {
#ifdef VPX_CTRL_VP9E_SET_TPL
[VP9E_SET_TPL] = "VP9E_SET_TPL",
#endif
+#ifdef VPX_CTRL_VP9E_SET_MIN_GF_INTERVAL
+[VP9E_SET_MIN_GF_INTERVAL] = "VP9E_SET_MIN_GF_INTERVAL",
+#endif
#endif
};
@@ -1173,6 +1177,10 @@ static av_cold int vpx_init(AVCodecContext *avctx,
#ifdef VPX_CTRL_VP9E_SET_TPL
if (ctx->tpl_model >= 0)
codecctl_int(avctx, VP9E_SET_TPL, ctx->tpl_model);
+#endif
+#ifdef VPX_CTRL_VP9E_SET_MIN_GF_INTERVAL
+if (ctx->min_gf_interval >= 0)
+codecctl_int(avctx, VP9E_SET_MIN_GF_INTERVAL,
ctx->min_gf_interval);
#endif
}
#endif
@@ -1911,6 +1919,9 @@ static const AVOption vp9_options[] = {
#endif
#ifdef VPX_CTRL_VP9E_SET_TPL
{ "enable-tpl", "Enable temporal dependency model",
OFFSET(tpl_model), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE },
+#endif
+#ifdef VPX_CTRL_VP9E_SET_MIN_GF_INTERVAL
+{ "min-gf-interval", "Minimum golden/alternate reference frame interval",
OFFSET(min_gf_interval), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VE },
#endif
LEGACY_OPTIONS
{ NULL }
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 2328be4b26..7e89daf017 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
#include "version_major.h"
#define LIBAVCODEC_VERSION_MINOR 43
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.37.2.789.g6183377224-goog
___
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] avcodec/libaomenc: fix compile after 5bab794
On Thu, Aug 25, 2022 at 12:30 PM James Zern wrote:
>
> encoder is a struct, not a pointer; use '.' to access iface.
>
> Signed-off-by: James Zern
> ---
> libavcodec/libaomenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Already fixed.
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index a82b933c18..1e89b7e3a8 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -400,7 +400,7 @@ static av_cold int aom_free(AVCodecContext *avctx)
> #if defined(AOM_CTRL_AV1E_GET_NUM_OPERATING_POINTS) && \
> defined(AOM_CTRL_AV1E_GET_SEQ_LEVEL_IDX) && \
> defined(AOM_CTRL_AV1E_GET_TARGET_SEQ_LEVEL_IDX)
> -if (ctx->encoder->iface && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
> +if (ctx->encoder.iface && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
> int num_operating_points;
> int levels[32];
> int target_levels[32];
> --
> 2.37.2.672.g94769d06f0-goog
>
___
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] avcodec/libaomenc: add init cleanup flag
On Thu, Aug 25, 2022 at 12:28 PM James Almer wrote:
>
> On 8/25/2022 4:21 PM, James Zern wrote:
> > On Thu, Aug 25, 2022 at 10:39 AM James Almer wrote:
> >>
> >> On 8/25/2022 2:34 PM, James Zern wrote:
> >>> On Thu, Aug 25, 2022 at 10:16 AM James Almer wrote:
> >>>>
> >>>> Signed-off-by: James Almer
> >>>> ---
> >>>> There doesn't seem to be any proper API to check if an encoder is open.
> >>>>
> >>>
> >>> true.
> >>>
> >>>>libavcodec/libaomenc.c | 3 ++-
> >>>>1 file changed, 2 insertions(+), 1 deletion(-)
> >>>>
> >>>
> >>> lgtm.
> >>
> >> Will apply, thanks.
> >>
> >>>
> >>>> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> >>>> index 485f554165..fb9a6ff8b2 100644
> >>>> --- a/libavcodec/libaomenc.c
> >>>> +++ b/libavcodec/libaomenc.c
> >>>> @@ -400,7 +400,7 @@ static av_cold int aom_free(AVCodecContext *avctx)
> >>>>#if defined(AOM_CTRL_AV1E_GET_NUM_OPERATING_POINTS) && \
> >>>>defined(AOM_CTRL_AV1E_GET_SEQ_LEVEL_IDX) && \
> >>>>defined(AOM_CTRL_AV1E_GET_TARGET_SEQ_LEVEL_IDX)
> >>>> -if (!(avctx->flags & AV_CODEC_FLAG_PASS1)) {
> >>>> +if (ctx->encoder->iface && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
> >
> > I missed this, it should be 'ctx->encoder.iface'.
>
> Huh. When were those three defines above added? Guess they are not in
> any tagged release?
>
> Fixed in any case. Thanks.
>
Thanks, you beat me to it. You're right, they're not in a tagged
release yet. 3.5.0 will have them.
___
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/libaomenc: fix compile after 5bab794
encoder is a struct, not a pointer; use '.' to access iface.
Signed-off-by: James Zern
---
libavcodec/libaomenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index a82b933c18..1e89b7e3a8 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -400,7 +400,7 @@ static av_cold int aom_free(AVCodecContext *avctx)
#if defined(AOM_CTRL_AV1E_GET_NUM_OPERATING_POINTS) && \
defined(AOM_CTRL_AV1E_GET_SEQ_LEVEL_IDX) && \
defined(AOM_CTRL_AV1E_GET_TARGET_SEQ_LEVEL_IDX)
-if (ctx->encoder->iface && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
+if (ctx->encoder.iface && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
int num_operating_points;
int levels[32];
int target_levels[32];
--
2.37.2.672.g94769d06f0-goog
___
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] avcodec/libaomenc: add init cleanup flag
On Thu, Aug 25, 2022 at 10:39 AM James Almer wrote:
>
> On 8/25/2022 2:34 PM, James Zern wrote:
> > On Thu, Aug 25, 2022 at 10:16 AM James Almer wrote:
> >>
> >> Signed-off-by: James Almer
> >> ---
> >> There doesn't seem to be any proper API to check if an encoder is open.
> >>
> >
> > true.
> >
> >> libavcodec/libaomenc.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >
> > lgtm.
>
> Will apply, thanks.
>
> >
> >> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> >> index 485f554165..fb9a6ff8b2 100644
> >> --- a/libavcodec/libaomenc.c
> >> +++ b/libavcodec/libaomenc.c
> >> @@ -400,7 +400,7 @@ static av_cold int aom_free(AVCodecContext *avctx)
> >> #if defined(AOM_CTRL_AV1E_GET_NUM_OPERATING_POINTS) && \
> >> defined(AOM_CTRL_AV1E_GET_SEQ_LEVEL_IDX) && \
> >> defined(AOM_CTRL_AV1E_GET_TARGET_SEQ_LEVEL_IDX)
> >> -if (!(avctx->flags & AV_CODEC_FLAG_PASS1)) {
> >> +if (ctx->encoder->iface && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
I missed this, it should be 'ctx->encoder.iface'.
> >
> > This check is fine, though the codec control call should fail if iface is
> > null.
> >
> >> int num_operating_points;
> >> int levels[32];
> >> int target_levels[32];
> >> @@ -1544,6 +1544,7 @@ FFCodec ff_libaom_av1_encoder = {
> >> FF_CODEC_ENCODE_CB(aom_encode),
> >> .close = aom_free,
> >> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
> >> + FF_CODEC_CAP_INIT_CLEANUP |
> >> FF_CODEC_CAP_AUTO_THREADS,
> >> .defaults = defaults,
> >> .init_static_data = av1_init_static,
> >> --
> >> 2.37.2
> >>
> >> ___
> >> 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".
___
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] avcodec/libaomenc: add init cleanup flag
On Thu, Aug 25, 2022 at 10:16 AM James Almer wrote:
>
> Signed-off-by: James Almer
> ---
> There doesn't seem to be any proper API to check if an encoder is open.
>
true.
> libavcodec/libaomenc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
lgtm.
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 485f554165..fb9a6ff8b2 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -400,7 +400,7 @@ static av_cold int aom_free(AVCodecContext *avctx)
> #if defined(AOM_CTRL_AV1E_GET_NUM_OPERATING_POINTS) && \
> defined(AOM_CTRL_AV1E_GET_SEQ_LEVEL_IDX) && \
> defined(AOM_CTRL_AV1E_GET_TARGET_SEQ_LEVEL_IDX)
> -if (!(avctx->flags & AV_CODEC_FLAG_PASS1)) {
> +if (ctx->encoder->iface && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
This check is fine, though the codec control call should fail if iface is null.
> int num_operating_points;
> int levels[32];
> int target_levels[32];
> @@ -1544,6 +1544,7 @@ FFCodec ff_libaom_av1_encoder = {
> FF_CODEC_ENCODE_CB(aom_encode),
> .close = aom_free,
> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
> + FF_CODEC_CAP_INIT_CLEANUP |
>FF_CODEC_CAP_AUTO_THREADS,
> .defaults = defaults,
> .init_static_data = av1_init_static,
> --
> 2.37.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libaomenc: use av_fast_realloc() to resize the stats buffer
On Tue, Aug 23, 2022 at 4:34 PM James Almer wrote: > > Signed-off-by: James Almer > --- > libavcodec/libaomenc.c | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) > 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 1/2] avcodec/libvpxenc: use av_fast_realloc() to resize the stats buffer
On Tue, Aug 23, 2022 at 4:34 PM James Almer wrote: > > Signed-off-by: James Almer > --- > libavcodec/libvpxenc.c | 15 ++- > 1 file changed, 10 insertions(+), 5 deletions(-) > 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 1/2] avformat/mov: Rework the AVIF parser to handle multiple items
On Tue, Aug 2, 2022 at 9:54 AM James Zern wrote: > > Andreas, > > On Thu, Jul 28, 2022 at 11:25 AM Vignesh Venkatasubramanian > wrote: > > > > Stores the item ids of all the items found in the file and > > processes the primary item at the end of the meta box. This patch > > does not change any behavior. It sets up the code for parsing > > alpha channel (and possibly images with 'grid') in follow up > > patches. > > > > Signed-off-by: Vignesh Venkatasubramanian > > --- > > libavformat/isom.h | 6 ++ > > libavformat/mov.c | 143 +++-- > > 2 files changed, 92 insertions(+), 57 deletions(-) > > > > Any more comments on this one? > 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 1/2] avformat/mov: Rework the AVIF parser to handle multiple items
Andreas,
On Thu, Jul 28, 2022 at 11:25 AM Vignesh Venkatasubramanian
wrote:
>
> Stores the item ids of all the items found in the file and
> processes the primary item at the end of the meta box. This patch
> does not change any behavior. It sets up the code for parsing
> alpha channel (and possibly images with 'grid') in follow up
> patches.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavformat/isom.h | 6 ++
> libavformat/mov.c | 143 +++--
> 2 files changed, 92 insertions(+), 57 deletions(-)
>
Any more comments on this one?
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index f05c2d9c28..9d8646d2ea 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -318,6 +318,12 @@ typedef struct MOVContext {
> uint32_t max_stts_delta;
> int is_still_picture_avif;
> int primary_item_id;
> +struct {
> +int item_id;
> +int extent_length;
> +int64_t extent_offset;
> +} *avif_info;
> +int avif_info_size;
> } MOVContext;
>
> int ff_mp4_read_descr_len(AVIOContext *pb);
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index a09a762d91..6ee6ed0950 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4698,6 +4698,69 @@ static int mov_read_custom(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return ret;
> }
>
> +static int avif_add_stream(MOVContext *c, int item_id)
> +{
> +MOVStreamContext *sc;
> +AVStream *st;
> +int item_index = -1;
> +for (int i = 0; i < c->avif_info_size; i++)
> +if (c->avif_info[i].item_id == item_id) {
> +item_index = i;
> +break;
> +}
> +if (item_index < 0)
> +return AVERROR_INVALIDDATA;
> +st = avformat_new_stream(c->fc, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +st->id = c->fc->nb_streams;
> +sc = av_mallocz(sizeof(MOVStreamContext));
> +if (!sc)
> +return AVERROR(ENOMEM);
> +
> +st->priv_data = sc;
> +st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
> +st->codecpar->codec_id = AV_CODEC_ID_AV1;
> +sc->ffindex = st->index;
> +c->trak_index = st->index;
> +st->avg_frame_rate.num = st->avg_frame_rate.den = 1;
> +st->time_base.num = st->time_base.den = 1;
> +st->nb_frames = 1;
> +sc->time_scale = 1;
> +sc = st->priv_data;
> +sc->pb = c->fc->pb;
> +sc->pb_is_copied = 1;
> +
> +// Populate the necessary fields used by mov_build_index.
> +sc->stsc_count = 1;
> +sc->stsc_data = av_malloc_array(1, sizeof(*sc->stsc_data));
> +if (!sc->stsc_data)
> +return AVERROR(ENOMEM);
> +sc->stsc_data[0].first = 1;
> +sc->stsc_data[0].count = 1;
> +sc->stsc_data[0].id = 1;
> +sc->chunk_count = 1;
> +sc->chunk_offsets = av_malloc_array(1, sizeof(*sc->chunk_offsets));
> +if (!sc->chunk_offsets)
> +return AVERROR(ENOMEM);
> +sc->sample_count = 1;
> +sc->sample_sizes = av_malloc_array(1, sizeof(*sc->sample_sizes));
> +if (!sc->sample_sizes)
> +return AVERROR(ENOMEM);
> +sc->stts_count = 1;
> +sc->stts_data = av_malloc_array(1, sizeof(*sc->stts_data));
> +if (!sc->stts_data)
> +return AVERROR(ENOMEM);
> +sc->stts_data[0].count = 1;
> +// Not used for still images. But needed by mov_build_index.
> +sc->stts_data[0].duration = 0;
> +sc->sample_sizes[0] = c->avif_info[item_index].extent_length;
> +sc->chunk_offsets[0] = c->avif_info[item_index].extent_offset;
> +
> +mov_build_index(c, st);
> +return 0;
> +}
> +
> static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> {
> while (atom.size > 8) {
> @@ -4707,9 +4770,23 @@ static int mov_read_meta(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> tag = avio_rl32(pb);
> atom.size -= 4;
> if (tag == MKTAG('h','d','l','r')) {
> +int ret;
> avio_seek(pb, -8, SEEK_CUR);
> atom.size += 8;
> -return mov_read_default(c, pb, atom);
> +if ((ret = mov_read_default(c, pb, atom)) < 0)
> +return ret;
> +if (c->is_still_picture_avif) {
> +int ret;
> +// Add a stream for the YUV planes (primary item).
> +if ((ret = avif_add_stream(c, c->primary_item_id)) < 0)
> +return ret;
> +// For still AVIF images, the meta box contains all the
> +// necessary information that would generally be provided by
> the
> +// moov box. So simply mark that we have found the moov box
> so
> +// that parsing can continue.
> +c->found_moov = 1;
> +}
> +return ret;
> }
> }
> return 0;
> @@ -7478,8 +7555,6 @@ static int mov_read_iloc(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> int item_count, extent_count;
> uint64_t base_offset, extent_offse
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: Rework the AVIF parser to handle multiple items
On Wed, Jul 27, 2022 at 9:12 AM Vignesh Venkatasubramanian wrote: > > Stores the item ids of all the items found in the file and > processes the primary item at the end of the meta box. This patch > does not change any behavior. It sets up the code for parsing > alpha channel (and possibly images with 'grid') in follow up > patches. > > Signed-off-by: Vignesh Venkatasubramanian > --- > libavformat/isom.h | 4 ++ > libavformat/mov.c | 146 - > 2 files changed, 95 insertions(+), 55 deletions(-) > lgtm. I'll submit this soon if there aren't any other comments. ___ 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] avformat/mov: Rework the AVIF parser to handle multiple items
On Fri, Jul 22, 2022 at 11:21 AM Vignesh Venkatasubramanian
wrote:
>
> On Wed, Jul 13, 2022 at 9:12 AM Vignesh Venkatasubramanian
> wrote:
> >
> > On Mon, Jul 11, 2022 at 3:25 PM James Zern
> > wrote:
> > >
> > > On Thu, Jun 30, 2022 at 2:04 PM Vignesh Venkatasubramanian
> > > wrote:
> > > >
> > > > Stores the item ids of all the items found in the file and
> > > > processes the primary item at the end of the meta box. This patch
> > > > does not change any behavior. It sets up the code for parsing
> > > > alpha channel (and possibly images with 'grid') in follow up
> > > > patches.
> > > >
> > > > Signed-off-by: Vignesh Venkatasubramanian
> > > > ---
> > > > libavformat/isom.h | 4 ++
> > > > libavformat/mov.c | 148 -
> > > > 2 files changed, 97 insertions(+), 55 deletions(-)
> > > >
> > > > [...]
> > >
> > > @@ -4692,9 +4755,25 @@ static int mov_read_meta(MOVContext *c,
> > > AVIOContext *pb, MOVAtom atom)
> > > tag = avio_rl32(pb);
> > > atom.size -= 4;
> > > if (tag == MKTAG('h','d','l','r')) {
> > > +int ret;
> > > avio_seek(pb, -8, SEEK_CUR);
> > > atom.size += 8;
> > > -return mov_read_default(c, pb, atom);
> > > +ret = mov_read_default(c, pb, atom);
> > > +if (ret < 0)
> > >
> > > In some other cases these two lines are combined, if ((ret = ...
> > >
> >
> > Done.
> >
> > > +return ret;
> > > +if (c->is_still_picture_avif) {
> > > +int ret;
> > > +// Add a stream for the YUV planes (primary item).
> > > +ret = avif_add_stream(c, c->primary_item_id);
> > > +if (ret)
> > >
> > > This could be updated too and use '< 0' to match other code.
> > >
> >
> > Done.
> >
> > > +return ret;
> > > +// For still AVIF images, the meta box contains all the
> > > +// necessary information that would generally be
> > > provided by the
> > > +// moov box. So simply mark that we have found the moov
> > > box so
> > > +// that parsing can continue.
> > > +c->found_moov = 1;
> > > +}
> > > +return ret;
> > > }
> > > ___
> > > 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".
> >
> >
> >
> > --
> > Vignesh
>
> Any further comments on this one?
>
> Please note that i have abandoned the second patch in this list. But
> this one is still up for merging.
>
This looks like it needs to be rebased. I'll take a look after that.
___
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] avformat/mov: Rework the AVIF parser to handle multiple items
On Thu, Jun 30, 2022 at 2:04 PM Vignesh Venkatasubramanian
wrote:
>
> Stores the item ids of all the items found in the file and
> processes the primary item at the end of the meta box. This patch
> does not change any behavior. It sets up the code for parsing
> alpha channel (and possibly images with 'grid') in follow up
> patches.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavformat/isom.h | 4 ++
> libavformat/mov.c | 148 -
> 2 files changed, 97 insertions(+), 55 deletions(-)
>
> [...]
@@ -4692,9 +4755,25 @@ static int mov_read_meta(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
tag = avio_rl32(pb);
atom.size -= 4;
if (tag == MKTAG('h','d','l','r')) {
+int ret;
avio_seek(pb, -8, SEEK_CUR);
atom.size += 8;
-return mov_read_default(c, pb, atom);
+ret = mov_read_default(c, pb, atom);
+if (ret < 0)
In some other cases these two lines are combined, if ((ret = ...
+return ret;
+if (c->is_still_picture_avif) {
+int ret;
+// Add a stream for the YUV planes (primary item).
+ret = avif_add_stream(c, c->primary_item_id);
+if (ret)
This could be updated too and use '< 0' to match other code.
+return ret;
+// For still AVIF images, the meta box contains all the
+// necessary information that would generally be
provided by the
+// moov box. So simply mark that we have found the moov box so
+// that parsing can continue.
+c->found_moov = 1;
+}
+return ret;
}
___
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/mov: Only read the primary item for AVIF
On Tue, Jun 28, 2022 at 12:02 PM James Zern wrote: > > On Tue, Jun 28, 2022 at 11:56 AM Vignesh Venkatasubramanian > wrote: > > > > Update the still AVIF parser to only read the primary item. With this > > patch, AVIF still images with exif/icc/alpha channel will no longer > > fail to parse. > > > > For example, this patch enables parsing of files in: > > https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Microsoft > > > > Adding two fate tests: > > 1) demuxing of still image with 1 item - this test will pass regardlesss I fixed the 'regardless' typo. > >of this patch. > > 2) demuxing of still image with 2 items - this test will fail without > >this patch and will pass with patch applied. > > > > Partially fixes trac ticket #7621 > > > > Signed-off-by: Vignesh Venkatasubramanian > > --- > > libavformat/isom.h| 1 + > > libavformat/mov.c | 41 ++- > > tests/fate/mov.mak| 13 ++ > > .../fate/mov-avif-demux-still-image-1-item| 11 + > > .../mov-avif-demux-still-image-multiple-items | 11 + > > 5 files changed, 57 insertions(+), 20 deletions(-) > > create mode 100644 tests/ref/fate/mov-avif-demux-still-image-1-item > > create mode 100644 tests/ref/fate/mov-avif-demux-still-image-multiple-items > > > > lgtm. I'll submit this soon if there aren't any comments. applied, thanks for the 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] avformat/mov: Only read the primary item for AVIF
On Tue, Jun 28, 2022 at 11:56 AM Vignesh Venkatasubramanian wrote: > > Update the still AVIF parser to only read the primary item. With this > patch, AVIF still images with exif/icc/alpha channel will no longer > fail to parse. > > For example, this patch enables parsing of files in: > https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Microsoft > > Adding two fate tests: > 1) demuxing of still image with 1 item - this test will pass regardlesss >of this patch. > 2) demuxing of still image with 2 items - this test will fail without >this patch and will pass with patch applied. > > Partially fixes trac ticket #7621 > > Signed-off-by: Vignesh Venkatasubramanian > --- > libavformat/isom.h| 1 + > libavformat/mov.c | 41 ++- > tests/fate/mov.mak| 13 ++ > .../fate/mov-avif-demux-still-image-1-item| 11 + > .../mov-avif-demux-still-image-multiple-items | 11 + > 5 files changed, 57 insertions(+), 20 deletions(-) > create mode 100644 tests/ref/fate/mov-avif-demux-still-image-1-item > create mode 100644 tests/ref/fate/mov-avif-demux-still-image-multiple-items > lgtm. I'll submit this soon if there aren't any comments. ___ 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] [fate] add webp/dual_transform.webp
Reviving this from samples-requ...@ffmpeg.org. The patch has been merged, all that is needed is to add the file and enable the test. The file can be downloaded from gitiles without needing to clone the repo [1]. This is to add coverage for a fix for 9368 [2][3]. [1] curl "https://chromium.googlesource.com/webm/libwebp-test-data/+/refs/heads/main/dual_transform.webp?format=TEXT"; |base64 -d >dual_transform.webp [2] https://trac.ffmpeg.org/ticket/9368 [3] https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210830121051.1703262-1-mar...@google.com/ ___ 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/mov: Only read the primary item for AVIF
On Mon, Jun 13, 2022 at 9:32 AM Vignesh Venkatasubramanian wrote: > > On Fri, Jun 10, 2022 at 10:34 AM Vignesh Venkatasubramanian > wrote: > > > > On Thu, Jun 9, 2022 at 12:50 AM Gyan Doshi wrote: > > > > > > > > > > > > On 2022-06-08 10:51 pm, Vignesh Venkatasubramanian wrote: > > > > On Thu, Jun 2, 2022 at 1:35 PM James Zern wrote: > > > >> On Wed, Jun 1, 2022 at 1:38 PM Vignesh Venkatasubramanian > > > >> wrote: > > > >>> On Wed, Jun 1, 2022 at 10:30 AM James Zern wrote: > > > >>>> On Sun, Apr 24, 2022 at 11:35 AM Vignesh Venkatasubramanian > > > >>>> wrote: > > > >>>>> Update the still AVIF parser to only read the primary item. With > > > >>>>> this > > > >>>>> patch, AVIF still images with exif/icc/alpha channel will no longer > > > >>>>> fail to parse. > > > >>>>> > > > >>>>> For example, this patch enables parsing of files in: > > > >>>>> https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Microsoft > > > >>>>> > > > >>>> Can some of the failing files or similar ones be added to fate? > > > >>> There are no fate tests for AVIF parsing as of now. I was thinking > > > >>> about adding some for the muxing. But i am not sure what can be done > > > >>> here for the parsing. > > > >>> > > > >> Thanks. Are there any for general mov/mp4 parsing that could be > > > >> extended? This looks good otherwise. > > > > From what i see, most of the mov tests only seem to be for muxing. I'm > > > > not entirely certain about how to add a test for AVIF parsing. If > > > > anybody has an idea, i'd be open to adding it. > > > > > > Basic test would use the framemd5 muxer to compare demuxed packets with > > > a reference. > > > See fate-ffmpeg-streamloop > > > > > > > Thank you i have added a couple of fate tests. > > > > I am not sure how to add the AVIF files to the fate test server. I > > have them on Google Drive here: > > > > https://drive.google.com/file/d/1diZoM0Ew7Co3Yh5w5y1J-3IiBYVmUv9J/view?usp=sharing > > https://drive.google.com/file/d/1DdrD1mW36evt40a4RkeLYpx-oojmbc3z/view?usp=sharing > > > > These links should be publicly available without any sign in required. > > Please let me know if there is another preferred way of sharing test > > files and i can share it that way. > > > > Also, i forgot to mention that these files have to be uploaded under a > new directory called "avif" in the fate server. > Can you send a separate patch with the tests disabled and marked by a TODO to enable them after the files are uploaded? https://ffmpeg.org/developer.html#Adding-files-to-the-fate_002dsuite-dataset ___ 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/movenc: Support alpha channel for AVIF
On Mon, Jun 27, 2022 at 9:48 AM James Almer wrote: > > On 6/27/2022 1:43 PM, Vignesh Venkatasubramanian wrote: > > On Tue, Jun 21, 2022 at 10:12 AM Vignesh Venkatasubramanian > > wrote: > >> > >> On Mon, Jun 13, 2022 at 10:17 AM James Zern > >> wrote: > >>> > >>> On Wed, Jun 1, 2022 at 11:06 AM Vignesh Venkatasubramanian > >>> wrote: > >>>> > >>>> AVIF specification allows for alpha channel as an auxiliary item (in > >>>> case of still images) or as an auxiliary track (in case of animated > >>>> images). Add support for both of these. The AVIF muxer will take > >>>> exactly two streams (when alpha is present) as input (first one being > >>>> the YUV planes and the second one being the alpha plane). > >>>> > >>>> The input has to come from two different images (one of it color and > >>>> the other one being alpha), or it can come from a single file > >>>> source with the alpha channel extracted using the "alphaextract" > >>>> filter. > >>>> > >>>> Example using alphaextract: > >>>> ffmpeg -i rgba.png -filter_complex "[0:v]alphaextract[a]" -map 0 -map > >>>> "[a]" -still-picture 1 avif_with_alpha.avif > >>>> > >>>> Example using two sources (first source can be in any pixel format and > >>>> the second source has to be in monochrome grey pixel format): > >>>> ffmpeg -i color.avif -i grey.avif -map 0 -map 1 -c copy > >>>> avif_with_alpha.avif > >>>> > >>>> The generated files pass the compliance checks in Compliance Warden: > >>>> https://github.com/gpac/ComplianceWarden > >>>> > >>>> libavif (the reference avif library) is able to decode the files > >>>> generated using this patch. > >>>> > >>>> They also play back properly (with transparent background) in: > >>>> 1) Chrome > >>>> 2) Firefox (only still AVIF, no animation support) > >>>> > >>>> Signed-off-by: Vignesh Venkatasubramanian > >>>> --- > >>>> libavformat/movenc.c | 188 +-- > >>>> libavformat/movenc.h | 4 +- > >>>> 2 files changed, 130 insertions(+), 62 deletions(-) > >>>> > >>> > >>> 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". > >> > >> Any more comments on this? If not can this be merged please? :) > >> > > > > Another ping on this please. > > > >> -- > >> Vignesh > > I thought James Zern had push access, which is why i didn't apply it as > soon as he reviewed it. Sorry. > > Pushed it now. > Sorry for the confusion James. I held off because I'm not a maintainer of this file, so I wanted to make sure there was another reviewer. ___ 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] avcodec/libaomenc: Get number of operating points
On Thu, Jun 16, 2022 at 10:36 AM James Zern wrote: > > On Thu, Jun 16, 2022 at 9:24 AM Wan-Teh Chang wrote: > > > > Use the new codec control AV1E_GET_NUM_OPERATING_POINTS to get the > > number of operating points. This is the size of the output arrays of > > AV1E_GET_SEQ_LEVEL_IDX and AV1E_GET_TARGET_SEQ_LEVEL_IDX. > > > > Signed-off-by: Wan-Teh Chang > > --- > > libavcodec/libaomenc.c | 20 ++-- > > 1 file changed, 14 insertions(+), 6 deletions(-) > > > > lgtm. Applied, thanks for the 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] avcodec/libaomenc: Get number of operating points
On Thu, Jun 16, 2022 at 9:24 AM Wan-Teh Chang wrote: > > Use the new codec control AV1E_GET_NUM_OPERATING_POINTS to get the > number of operating points. This is the size of the output arrays of > AV1E_GET_SEQ_LEVEL_IDX and AV1E_GET_TARGET_SEQ_LEVEL_IDX. > > Signed-off-by: Wan-Teh Chang > --- > libavcodec/libaomenc.c | 20 ++-- > 1 file changed, 14 insertions(+), 6 deletions(-) > 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] avformat/movenc: Support alpha channel for AVIF
On Wed, Jun 1, 2022 at 11:06 AM Vignesh Venkatasubramanian wrote: > > AVIF specification allows for alpha channel as an auxiliary item (in > case of still images) or as an auxiliary track (in case of animated > images). Add support for both of these. The AVIF muxer will take > exactly two streams (when alpha is present) as input (first one being > the YUV planes and the second one being the alpha plane). > > The input has to come from two different images (one of it color and > the other one being alpha), or it can come from a single file > source with the alpha channel extracted using the "alphaextract" > filter. > > Example using alphaextract: > ffmpeg -i rgba.png -filter_complex "[0:v]alphaextract[a]" -map 0 -map "[a]" > -still-picture 1 avif_with_alpha.avif > > Example using two sources (first source can be in any pixel format and > the second source has to be in monochrome grey pixel format): > ffmpeg -i color.avif -i grey.avif -map 0 -map 1 -c copy avif_with_alpha.avif > > The generated files pass the compliance checks in Compliance Warden: > https://github.com/gpac/ComplianceWarden > > libavif (the reference avif library) is able to decode the files > generated using this patch. > > They also play back properly (with transparent background) in: > 1) Chrome > 2) Firefox (only still AVIF, no animation support) > > Signed-off-by: Vignesh Venkatasubramanian > --- > libavformat/movenc.c | 188 +-- > libavformat/movenc.h | 4 +- > 2 files changed, 130 insertions(+), 62 deletions(-) > 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] avformat/mov: Only read the primary item for AVIF
On Wed, Jun 1, 2022 at 1:38 PM Vignesh Venkatasubramanian wrote: > > On Wed, Jun 1, 2022 at 10:30 AM James Zern wrote: > > > > On Sun, Apr 24, 2022 at 11:35 AM Vignesh Venkatasubramanian > > wrote: > > > > > > Update the still AVIF parser to only read the primary item. With this > > > patch, AVIF still images with exif/icc/alpha channel will no longer > > > fail to parse. > > > > > > For example, this patch enables parsing of files in: > > > https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Microsoft > > > > > > > Can some of the failing files or similar ones be added to fate? > > There are no fate tests for AVIF parsing as of now. I was thinking > about adding some for the muxing. But i am not sure what can be done > here for the parsing. > Thanks. Are there any for general mov/mp4 parsing that could be extended? This looks good otherwise. ___ 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/movenc: Support alpha channel for AVIF
On Wed, May 18, 2022 at 2:56 PM Vignesh Venkatasubramanian
wrote:
>
> AVIF specification allows for alpha channel as an auxillary item (in
auxiliary
> case of still images) or as an auxillary track (in case of animated
> images). Add support for both of these. The AVIF muxer will take
> exactly two streams (when alpha is present) as input (first one being
> the YUV planes and the second one being the alpha plane).
>
> The input has to come from two different images (one of it color and
> the other one being alpha), or it can come from a single file
> source with the alpha channel extracted using the "alphaextract"
> filter.
>
> Example using alphaextract:
> ffmpeg -i rgba.png -filter_complex "[0:v]alphaextract[a]" -map 0 -map "[a]"
> -still-picture 1 avif_with_alpha.avif
>
> Example using two sources (first source can be in any pixel format and
> the second source has to be in monochrome grey pixel format):
> ffmpeg -i color.avif -i grey.avif -map 0 -map 1 -c copy avif_with_alpha.avif
>
> The generated files pass the compliance checks in Compliance Warden:
> https://github.com/gpac/ComplianceWarden
>
> libavif (the reference avif library) is able to decode the files
> generated using this patch.
>
> They also play back properly (with transparent background) in:
> 1) Chrome
> 2) Firefox (only still AVIF, no animation support)
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavformat/movenc.c | 185 +--
> libavformat/movenc.h | 4 +-
> 2 files changed, 128 insertions(+), 61 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index de971f94e8..00e42b7abb 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -2852,7 +2852,7 @@ static int mov_write_hdlr_tag(AVFormatContext *s,
> AVIOContext *pb, MOVTrack *tra
> hdlr = (track->mode == MODE_MOV) ? "mhlr" : "\0\0\0\0";
> if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
> if (track->mode == MODE_AVIF) {
> -hdlr_type = "pict";
> +hdlr_type = (track == &mov->tracks[0]) ? "pict" : "auxv";
> descr = "PictureHandler";
> } else {
> hdlr_type = "vide";
> @@ -2940,57 +2940,83 @@ static int mov_write_iloc_tag(AVIOContext *pb,
> MOVMuxContext *mov, AVFormatConte
> avio_wb32(pb, 0); /* Version & flags */
> avio_w8(pb, (4 << 4) + 4); /* offset_size(4) and length_size(4) */
> avio_w8(pb, 0); /* base_offset_size(4) and reserved(4) */
> -avio_wb16(pb, 1); /* item_count */
> +avio_wb16(pb, s->nb_streams); /* item_count */
This assumes at most 2 streams for AVIF, the use of nb_streams here and
elsewhere carry any risk for other formats?
> [...]
>
> @@ -6874,14 +6920,23 @@ static int mov_init(AVFormatContext *s)
>
> /* AVIF output must have exactly one video stream */
This is no longer true.
> if (mov->mode == MODE_AVIF) {
> -if (s->nb_streams > 1) {
> -av_log(s, AV_LOG_ERROR, "AVIF output requires exactly one
> stream\n");
> +if (s->nb_streams > 2) {
> +av_log(s, AV_LOG_ERROR, "AVIF output requires exactly one or two
> streams\n");
> return AVERROR(EINVAL);
> }
> -if (s->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) {
> -av_log(s, AV_LOG_ERROR, "AVIF output requires one video
> stream\n");
> +if (s->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO &&
> +(s->nb_streams > 1 && s->streams[1]->codecpar->codec_type !=
> AVMEDIA_TYPE_VIDEO)) {
> +av_log(s, AV_LOG_ERROR, "AVIF output supports only video
> streams\n");
> return AVERROR(EINVAL);
> }
> +if (s->nb_streams > 1) {
> +const AVPixFmtDescriptor *pixdesc =
> +av_pix_fmt_desc_get(s->streams[1]->codecpar->format);
> +if (pixdesc->nb_components != 1) {
> +av_log(s, AV_LOG_ERROR, "Second stream for AVIF (alpha)
> output must have exactly one plane\n");
> +return AVERROR(EINVAL);
> +}
> +}
> s->streams[0]->disposition |= AV_DISPOSITION_DEFAULT;
> }
>
> @@ -7543,18 +7598,25 @@ static int avif_write_trailer(AVFormatContext *s)
> {
> AVIOContext *pb = s->pb;
> MOVMuxContext *mov = s->priv_data;
> -int64_t pos_backup, mdat_pos;
> +int64_t pos_backup, extent_offsets[2];
> uint8_t *buf;
> -int buf_size, moov_size;
> +int buf_size, moov_size, i;
>
> if (mov->moov_written) return 0;
>
> mov->is_animated_avif = s->streams[0]->nb_frames > 1;
> +if (mov->is_animated_avif && s->nb_streams > 1) {
> +// For animated avif with alpha channel, we need to write a the tref
...write a tref...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-
Re: [FFmpeg-devel] [PATCH] avformat/mov: Only read the primary item for AVIF
On Sun, Apr 24, 2022 at 11:35 AM Vignesh Venkatasubramanian wrote: > > Update the still AVIF parser to only read the primary item. With this > patch, AVIF still images with exif/icc/alpha channel will no longer > fail to parse. > > For example, this patch enables parsing of files in: > https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Microsoft > Can some of the failing files or similar ones be added to fate? ___ 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/libaomenc: Add unmet target level warning
On Tue, May 17, 2022 at 12:45 PM James Zern wrote: > > On Tue, Apr 19, 2022 at 11:20 AM Bohan Li > wrote: > > > > When target levels are set, this patch checks whether they are > > satisfied by libaom. If not, a warning is shown. Otherwise the output > > levels are also logged. > > > > This patch applies basically the same approach used for libvpx. > > > > Signed-off-by: Bohan Li > > --- > > libavcodec/libaomenc.c | 64 ++ > > 1 file changed, 64 insertions(+) > > > > lgtm. applied. thanks for the 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 v2] avcodec/libaomenc: Add unmet target level warning
On Tue, May 17, 2022 at 12:45 PM James Zern wrote:
>
> On Tue, Apr 19, 2022 at 11:20 AM Bohan Li
> wrote:
> >
> > When target levels are set, this patch checks whether they are
> > satisfied by libaom. If not, a warning is shown. Otherwise the output
> > levels are also logged.
> >
> > This patch applies basically the same approach used for libvpx.
> >
> > Signed-off-by: Bohan Li
> > ---
> > libavcodec/libaomenc.c | 64 ++
> > 1 file changed, 64 insertions(+)
> >
>
> lgtm.
> +} else if (target_levels[i] < 31) {
> +// Log the encoded level if a target level was given
> +av_log(avctx, AV_LOG_INFO,
> + "Output level for operating point %d is %d.%d.",
> + i, 2 + (levels[i] >> 2), levels[i] & 3);
> +}
Actually this is a bit spammy. If there's only one operating point set
then I'd expect a single line output, but this seems to print all 32
regardless. Is that expected?
___
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/libaomenc: Add unmet target level warning
On Tue, Apr 19, 2022 at 11:20 AM Bohan Li wrote: > > When target levels are set, this patch checks whether they are > satisfied by libaom. If not, a warning is shown. Otherwise the output > levels are also logged. > > This patch applies basically the same approach used for libvpx. > > Signed-off-by: Bohan Li > --- > libavcodec/libaomenc.c | 64 ++ > 1 file changed, 64 insertions(+) > 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] avcodec/libaomenc: Expose the allintra usage mode
On Tue, May 17, 2022 at 11:24 AM Vignesh Venkatasubramanian
wrote:
>
> libaom added an usage=allintra mode for doing better with still
> images. Expose that in the ffmpeg's wrapper. This is especially
> useful for encoding still AVIF images.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavcodec/libaomenc.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
lgtm. It seems this was never documented in encoders.texi:
http://ffmpeg.org/ffmpeg-codecs.html#libaom_002dav1
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 0411773bbf..7a601c120e 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -1298,8 +1298,11 @@ static const AVOption options[] = {
> { "enable-intrabc", "Enable intra block copy prediction mode",
> OFFSET(enable_intrabc), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
> { "enable-restoration", "Enable Loop Restoration filtering",
> OFFSET(enable_restoration), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
> { "usage", "Quality and compression efficiency vs speed
> trade-off", OFFSET(usage), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, VE,
> "usage"},
> -{ "good","Good quality", 0, AV_OPT_TYPE_CONST, {.i64 =
> 0 /* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
> -{ "realtime","Realtime encoding", 0, AV_OPT_TYPE_CONST, {.i64 =
> 1 /* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
> +{ "good","Good quality", 0, AV_OPT_TYPE_CONST, {.i64 =
> 0 /* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
> +{ "realtime","Realtime encoding", 0, AV_OPT_TYPE_CONST, {.i64 =
> 1 /* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
> +#ifdef AOM_USAGE_ALL_INTRA
> +{ "allintra","All Intra encoding", 0, AV_OPT_TYPE_CONST, {.i64 =
> 2 /* AOM_USAGE_ALL_INTRA */},0, 0, VE, "usage"},
> +#endif
> { "tune","The metric that the encoder tunes for.
> Automatically chosen by the encoder by default", OFFSET(tune),
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, AOM_TUNE_SSIM, VE, "tune"},
> { "psnr",NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> AOM_TUNE_PSNR}, 0, 0, VE, "tune"},
> { "ssim",NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> AOM_TUNE_SSIM}, 0, 0, VE, "tune"},
> --
> 2.36.0.550.gb090851708-goog
>
> ___
> 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/img2: Add support for AVIF mux in image2
On Mon, May 16, 2022 at 10:40 AM Vignesh Venkatasubramanian wrote: > > Add support for AVIF muxing in the image2 muxer. > > Tested with this example: > ffmpeg -lavfi testsrc=duration=1:size=320x320 -g 1 -flags global_header -c:v > libaom-av1 -f image2 img-%2d.avif > > Signed-off-by: Vignesh Venkatasubramanian > --- > libavformat/img2enc.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > 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 3/3] avformat/movenc: Add support for AVIF muxing
On Mon, May 2, 2022 at 2:35 PM Vignesh Venkatasubramanian wrote: > > Add an AVIF muxer by re-using the existing the mov/mp4 muxer. > > AVIF Specification: https://aomediacodec.github.io/av1-avif > > Sample usage for still image: > ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif > > Sample usage for animated AVIF image: > ffmpeg -i video.mp4 animated.avif > > We can re-use any of the AV1 encoding options that will make > sense for image encoding (like bitrate, tiles, encoding speed, > etc). > > The files generated by this muxer has been verified to be valid > AVIF files by the following: > 1) Displays on Chrome (both still and animated images). > 2) Displays on Firefox (only still images, firefox does not support >animated AVIF yet). > 3) Verified to be valid by Compliance Warden: >https://github.com/gpac/ComplianceWarden > > Fixes the encoder/muxer part of Trac Ticket #7621 > > Signed-off-by: Vignesh Venkatasubramanian > --- > configure| 1 + > libavformat/allformats.c | 1 + > libavformat/movenc.c | 335 --- > libavformat/movenc.h | 5 + > 4 files changed, 317 insertions(+), 25 deletions(-) > 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 3/3] avformat/movenc: Add support for AVIF muxing
On Wed, Apr 13, 2022 at 1:40 PM Vignesh Venkatasubramanian
wrote:
>
> Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
>
> AVIF Specification: https://aomediacodec.github.io/av1-avif
>
> Sample usage for still image:
> ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
>
> Sample usage for animated AVIF image:
> ffmpeg -i video.mp4 animated.avif
>
> We can re-use any of the AV1 encoding options that will make
> sense for image encoding (like bitrate, tiles, encoding speed,
> etc).
>
> The files generated by this muxer has been verified to be valid
> AVIF files by the following:
> 1) Displays on Chrome (both still and animated images).
> 2) Displays on Firefox (only still images, firefox does not support
>animated AVIF yet).
> 3) Verified to be valid by Compliance Warden:
>https://github.com/gpac/ComplianceWarden
>
> Fixes the encoder/muxer part of Trac Ticket #7621
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> configure| 1 +
> libavformat/allformats.c | 1 +
> libavformat/movenc.c | 337 ---
> libavformat/movenc.h | 5 +
> 4 files changed, 319 insertions(+), 25 deletions(-)
>
It would be good to have a Changelog entry after the ticket is fixed.
> [...]
> @@ -2823,7 +2848,10 @@ static int mov_write_hdlr_tag(AVFormatContext *s,
> AVIOContext *pb, MOVTrack *tra
>
> if (track) {
> hdlr = (track->mode == MODE_MOV) ? "mhlr" : "\0\0\0\0";
> -if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
> +if (track->mode == MODE_AVIF) {
> +hdlr_type = "pict";
> +descr = "ffmpeg";
Should this be PictureHandler or blank? What's written for heic?
> [...]
> +static int mov_write_ispe_tag(AVIOContext *pb, MOVMuxContext *mov,
> AVFormatContext *s)
> +{
> +int64_t pos = avio_tell(pb);
> +avio_wb32(pb, 0); /* size */
> +ffio_wfourcc(pb, "ispe");
> +avio_wb32(pb, 0); /* Version & flags */
> +avio_wb32(pb, s->streams[0]->codecpar->width); /* image_width */
> +avio_wb32(pb, s->streams[0]->codecpar->height); /* image_height */
> +return update_size(pb, pos);
> +}
> +
> +
This extra line could be removed.
> [...]
> +/* AVIF output must have exactly one video stream */
> +if (mov->mode == MODE_AVIF) {
> +if (s->nb_streams > 1) {
> +av_log(s, AV_LOG_ERROR, "AVIF output requires exactly one
> stream\n");
> +return AVERROR(EINVAL);
> +}
> +if (s->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) {
> +av_log(s, AV_LOG_ERROR, "AVIF output requires one video
> stream\n");
> +return AVERROR(EINVAL);
> +}
> +}
> +
> +
This one too.
___
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/movenc: Add support for AVIF muxing
On Mon, Mar 28, 2022 at 1:49 PM Vignesh Venkatasubramanian
wrote:
>
> Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
>
> AVIF Specifiation: https://aomediacodec.github.io/av1-avif
>
Specification
> Sample usage for still image:
> ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
>
> Sample usage for animated AVIF image:
> ffmpeg -i video.mp4 animated.avif
>
> We can re-use any of the AV1 encoding options that will make
> sense for image encoding (like bitrate, tiles, encoding speed,
> etc).
>
> The files generated by this muxer has been verified to be valid
> AVIF files by the following:
> 1) Displays on Chrome (both still and animated images).
> 2) Displays on Firefox (only still images, firefox does not support
>animated AVIF yet).
> 3) Verfied to be valid by Compliance Warden:
Verified
>https://github.com/gpac/ComplianceWarden
>
> Fixes the encoder/muxer part of Trac Ticket #7621
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> configure| 1 +
> libavformat/allformats.c | 1 +
> libavformat/movenc.c | 337 ---
> libavformat/movenc.h | 5 +
> 4 files changed, 319 insertions(+), 25 deletions(-)
>
There might be some other issues, you can try tools/patcheck.
> [...]
> @@ -5068,6 +5231,31 @@ static int mov_write_ftyp_tag(AVIOContext *pb,
> AVFormatContext *s)
> // compatible brand a second time.
> if (mov->mode == MODE_ISM) {
> ffio_wfourcc(pb, "piff");
> +} else if (mov->mode == MODE_AVIF) {
> +const AVPixFmtDescriptor *pix_fmt_desc =
> +av_pix_fmt_desc_get(s->streams[0]->codecpar->format);
> +const int depth = pix_fmt_desc->comp[0].depth;
> +if (mov->is_animated_avif) {
> +// For animated AVIF, major brand is "avis". Add "avif" as a
> +// compatible brand.
> +ffio_wfourcc(pb, "avif");
> +ffio_wfourcc(pb, "msf1");
> +ffio_wfourcc(pb, "iso8");
> +}
> +ffio_wfourcc(pb, "mif1");
> +ffio_wfourcc(pb, "miaf");
> +if (depth == 8 || depth == 10) {
> +// MA1B and MA1A brands are based on AV1 profile. Short hand for
> +// computing that is based on chroma subsampling type. 420 chroma
> +// subsampling is MA1B. 444 chroma subsampling is MA1A.
> +if (pix_fmt_desc->log2_chroma_w == 0 &&
> pix_fmt_desc->log2_chroma_h == 0) {
!... is the preferred style.
> @@ -6773,12 +6983,13 @@ static int mov_init(AVFormatContext *s)
> pix_fmt == AV_PIX_FMT_MONOWHITE ||
> pix_fmt == AV_PIX_FMT_MONOBLACK;
> }
> -if (track->par->codec_id == AV_CODEC_ID_VP9 ||
> -track->par->codec_id == AV_CODEC_ID_AV1) {
> -if (track->mode != MODE_MP4) {
> -av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n",
> avcodec_get_name(track->par->codec_id));
> -return AVERROR(EINVAL);
> -}
> +if (track->par->codec_id == AV_CODEC_ID_VP9 && track->mode !=
> MODE_MP4) {
> +av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n",
> avcodec_get_name(track->par->codec_id));
> + return AVERROR(EINVAL);
This is indented with tabs.
___
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] avcodec/libvpxenc: enable dynamic max quantizer parameter reconfiguration
On Thu, Mar 31, 2022 at 10:31 AM James Zern wrote: > > On Wed, Mar 30, 2022 at 11:25 AM Danil Chapovalov > wrote: > > > > --- > > doc/encoders.texi | 3 +++ > > libavcodec/libvpxenc.c | 6 ++ > > 2 files changed, 9 insertions(+) > > > > lgtm. I'll submit this with a patch version bump soon if there aren't > any further comments. Applied with some additional error checking. Thanks for the 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] avcodec/libvpxenc: return quantizer parameter for an encoded frame
On Tue, Apr 5, 2022 at 7:23 AM Danil Chapovalov
wrote:
>
> I've rechecked documentation for the "vpx_codec_control" - can't find
> any guarantee about the last parameter when the function fails, thus
> prefer to be on the safe side.
>
The check is fine, though the function can only fail due to invalid
arguments and won't modify the value in that case.
As an aside, try to avoid top posting on this list:
https://ffmpeg.org/contact.html#MailingLists
> On Tue, Apr 5, 2022 at 3:59 PM James Almer wrote:
> >
> > On 4/5/2022 9:15 AM, Danil Chapovalov wrote:
> > > ---
> > > libavcodec/libvpxenc.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> > > index dff1d06b0e..0705863450 100644
> > > --- a/libavcodec/libvpxenc.c
> > > +++ b/libavcodec/libvpxenc.c
> > > @@ -1250,6 +1250,8 @@ static int storeframe(AVCodecContext *avctx, struct
> > > FrameListData *cx_frame,
> > > int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
> > > uint8_t *side_data;
> > > int pict_type;
> > > +int quality;
> > > +VPxContext *ctx = avctx->priv_data;
> > >
> > > if (ret < 0)
> > > return ret;
> > > @@ -1264,7 +1266,12 @@ static int storeframe(AVCodecContext *avctx,
> > > struct FrameListData *cx_frame,
> > > pict_type = AV_PICTURE_TYPE_P;
> > > }
> > >
> > > -ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
> > > +ret = vpx_codec_control(&ctx->encoder, VP8E_GET_LAST_QUANTIZER_64,
> > > &quality);
> > > +if (ret != VPX_CODEC_OK) {
> >
> > Is the last argument guaranteed to be untouched when the return value of
> > vpx_codec_control() is not VPX_CODEC_OK? If so, you can initialize
> > quality to 0 above, and remove this part.
> >
> > > +quality = 0;
> > > +}
> > > +
> > > +ff_side_data_set_encoder_stats(pkt, quality * FF_QP2LAMBDA,
> > > cx_frame->sse + 1,
> > > cx_frame->have_sse ? 3 : 0,
> > > pict_type);
> > >
> > > if (cx_frame->have_sse) {
> > ___
> > 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".
