[FFmpeg-devel] [PATCH v2 13/14] vvcdec: add CTU thread logical

Nuo Mi nuomi2021 at gmail.com
Mon Jul 10 10:45:14 EEST 2023


On Sun, Jul 9, 2023 at 9:03 AM Andreas Rheinhardt <
andreas.rheinhardt at outlook.com> wrote:

> Michael Niedermayer:
> > On Fri, Jul 07, 2023 at 10:05:39PM +0800, Nuo Mi wrote:
> >> This is the main entry point for the CTU (Coding Tree Unit) decoder.
> >> The code will divide the CTU decoder into several stages.
> >> It will check the stage dependencies and run the stage decoder.
> >> ---
> >>  libavcodec/vvc/Makefile     |   3 +-
> >>  libavcodec/vvc/vvc_thread.c | 804 ++++++++++++++++++++++++++++++++++++
> >>  libavcodec/vvc/vvc_thread.h |  73 ++++
> >>  3 files changed, 879 insertions(+), 1 deletion(-)
> >>  create mode 100644 libavcodec/vvc/vvc_thread.c
> >>  create mode 100644 libavcodec/vvc/vvc_thread.h
> >
> > seems not to build with enable-shared
> >
> > src/libavcodec/vvc/vvc_thread.c:235:9: error: address argument to atomic
> operation must be a pointer to non-const _Atomic type ('const atomic_int *'
> (aka 'const _Atomic(int) *') invalid)
> >     if (atomic_load(&ft->ret))
> >         ^           ~~~~~~~~
> > /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:134:29: note:
> expanded from macro 'atomic_load'
> > #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
> >                             ^                 ~~~~~~
> > 1 error generated.
> > src/ffbuild/common.mak:81: recipe for target
> 'libavcodec/vvc/vvc_thread.o' failed
> > make: *** [libavcodec/vvc/vvc_thread.o] Error 1
> > make: *** Waiting for unfinished jobs....
> >
> >
>
> atomic_load() does not accept pointers to non-const atomic objects in
> the original C11 spec (presumably the reason for this was that on
> systems that lack atomics of the appropriate size an atomic would need
> to be emulated somehow and this may involve locking and therefore
> require the object to be writable). Your system is old and abides by the
> original spec; AFAIK this point has been changed in later specs.
> The solution is to use a cast.
>
> - Andreas
>
> PS: Exactly the same thing happened in the HEVC decoder.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>
Hi Michael and Andreas,
Thank you for the report and suggestion. will check the HEVC and fix it.


More information about the ffmpeg-devel mailing list