Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] lavc/webp: Remove frame threading
Date: Sun, 22 Oct 2023 16:30:36 +0200
Message-ID: <AS8P250MB074463E090EA1AB47C81CA0E8FD9A@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20231022124525.96162-1-thilo.borgmann@mail.de>

Thilo Borgmann via ffmpeg-devel:
> Revealed by the patch to support animated webp, the current
> frame threading implementation contains a data race.

No, it doesn't: The current implementation does not call
ff_thread_finish_setup() in vp8.c for webp:

    if (ffcodec(avctx->codec)->update_thread_context)
        ff_thread_finish_setup(avctx);

It seems that "the patch to support animated webp" (what patch are we
talking about?) adds an update_thread_context to the webp decoder,
thereby changing things and adding the data race.

> vp8_lossy_decode_frame() calls ff_vp8_decode_frame() wich
> calls ff_thread_finish_setup() to sync its internal slice threading.

Nonsense: ff_thread_finish_setup() is only for frame-threading.

> The race is happens because vp8_lossy_decode_frame() has to touch
> the AVCodecContext after it was passed to ff_vp8_decode_frame() and
> ff_thread_finish_setup() had been called.
> 
> Therefore remove frame threading in webp and rely on slice threading
> in VP8 only.

Also nonsense: The webp decoder does not support slice threading, so the
internal VP8 decoder won't ever use it (even though it supports it).

I am a bit confused here: On the one hand,
https://developers.google.com/speed/webp/docs/riff_container says that
it only uses VP8 key frame encoding; on the other hand, it has this
animation feature. Does this also only use VP8-intra coding (i.e. is the
non-intra part of animation just the blending of earlier frames?)? If it
does, then the webp decoder should be separated from the VP8 decoder
(i.e. it should use it according to the public API) and the sub-decoder
should only be used in single-threaded mode.

IMO removing frame-threading for ordinary WebP due to animated WebP is
unacceptable.

> ---
>  libavcodec/webp.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> index 54b3fde6dc..cde91aa7bb 100644
> --- a/libavcodec/webp.c
> +++ b/libavcodec/webp.c
> @@ -49,7 +49,6 @@
>  #include "decode.h"
>  #include "exif.h"
>  #include "get_bits.h"
> -#include "thread.h"
>  #include "tiff_common.h"
>  #include "vp8.h"
>  
> @@ -570,7 +569,7 @@ static int decode_entropy_coded_image(WebPContext *s, enum ImageRole role,
>      img->frame->height = h;
>  
>      if (role == IMAGE_ROLE_ARGB && !img->is_alpha_primary) {
> -        ret = ff_thread_get_buffer(s->avctx, img->frame, 0);
> +        ret = ff_get_buffer(s->avctx, img->frame, 0);
>      } else
>          ret = av_frame_get_buffer(img->frame, 1);
>      if (ret < 0)
> @@ -1564,6 +1563,6 @@ const FFCodec ff_webp_decoder = {
>      .init           = webp_decode_init,
>      FF_CODEC_DECODE_CB(webp_decode_frame),
>      .close          = webp_decode_close,
> -    .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> +    .p.capabilities = AV_CODEC_CAP_DR1,
>      .caps_internal  = FF_CODEC_CAP_ICC_PROFILES,
>  };


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2023-10-22 14:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-22 12:45 Thilo Borgmann via ffmpeg-devel
2023-10-22 14:30 ` Andreas Rheinhardt [this message]
2023-10-23  6:41   ` Thilo Borgmann via ffmpeg-devel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AS8P250MB074463E090EA1AB47C81CA0E8FD9A@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM \
    --to=andreas.rheinhardt@outlook.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git