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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
