[FFmpeg-devel] [PATCH 14/18] avcodec/hevcdec: Don't allocate redundant HEVCContexts

[Michael Niedermayer]

On Sat, Jul 02, 2022 at 08:32:06AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Fri, Jul 01, 2022 at 12:29:45AM +0200, Andreas Rheinhardt wrote:
> >> The HEVC decoder has both HEVCContext and HEVCLocalContext
> >> structures. The latter is supposed to be the structure
> >> containing the per-slicethread state.
> >>
> >> Yet up until now that is not how it is handled in practice:
> >> Each HEVCLocalContext has a unique HEVCContext allocated for it
> >> and each of these coincides except in exactly one field: The
> >> corresponding HEVCLocalContext. This makes it possible to pass
> >> the HEVCContext everywhere where logically a HEVCLocalContext
> >> should be used. And up until recently, this is how it has been done.
> >>
> >> Yet the preceding patches changed this, making it possible
> >> to avoid allocating redundant HEVCContexts.
> >>
> >> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>
> >> ---
> >>  libavcodec/hevcdec.c | 40 ++++++++++++++++------------------------
> >>  libavcodec/hevcdec.h |  2 --
> >>  2 files changed, 16 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> >> index 9d1241f293..048fcc76b4 100644
> >> --- a/libavcodec/hevcdec.c
> >> +++ b/libavcodec/hevcdec.c
> >> @@ -2548,13 +2548,12 @@ static int hls_decode_entry_wpp(AVCodecContext *avctxt, void *hevc_lclist,
> >>  {
> >>      HEVCLocalContext *lc = ((HEVCLocalContext**)hevc_lclist)[self_id];
> >>      const HEVCContext *const s = lc->parent;
> >> -    HEVCContext *s1  = avctxt->priv_data;
> >> -    int ctb_size    = 1<< s1->ps.sps->log2_ctb_size;
> >> +    int ctb_size    = 1 << s->ps.sps->log2_ctb_size;
> >>      int more_data   = 1;
> >>      int ctb_row = job;
> >> -    int ctb_addr_rs = s1->sh.slice_ctb_addr_rs + ctb_row * ((s1->ps.sps->width + ctb_size - 1) >> s1->ps.sps->log2_ctb_size);
> >> -    int ctb_addr_ts = s1->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
> >> -    int thread = ctb_row % s1->threads_number;
> >> +    int ctb_addr_rs = s->sh.slice_ctb_addr_rs + ctb_row * ((s->ps.sps->width + ctb_size - 1) >> s->ps.sps->log2_ctb_size);
> >> +    int ctb_addr_ts = s->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
> >> +    int thread = ctb_row % s->threads_number;
> >>      int ret;
> >>  
> >>      if(ctb_row) {
> >> @@ -2572,7 +2571,7 @@ static int hls_decode_entry_wpp(AVCodecContext *avctxt, void *hevc_lclist,
> >>  
> >>          ff_thread_await_progress2(s->avctx, ctb_row, thread, SHIFT_CTB_WPP);
> >>  
> >> -        if (atomic_load(&s1->wpp_err)) {
> >> +        if (atomic_load(&s->wpp_err)) {
> >>              ff_thread_report_progress2(s->avctx, ctb_row , thread, SHIFT_CTB_WPP);
> > 
> > the consts in "const HEVCContext *const " make clang version 6.0.0-1ubuntu2 unhappy
> > (this was building shared libs)
> > 
> > 
> > CC	libavcodec/hevcdec.o
> > src/libavcodec/hevcdec.c:2574:13: 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(&s->wpp_err)) {
> >             ^           ~~~~~~~~~~~
> > /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/hevcdec.o' failed
> > make: *** [libavcodec/hevcdec.o] Error 1
> > 
> > thx
> > 
> 
> Thanks for testing this. atomic_load is indeed declared without const in
> 7.17.7.2:
> 
> C atomic_load(volatile A *object);
> 
> Upon reflection this makes sense, because if atomics are implemented via
> mutexes, even a read may involve a preceding write. So I'll cast const
> away here, too, and add a comment. (It works when casting const away,
> doesn't it?)

This doesnt feel "right". These pointers should not be coming from a const
if they are written to

The compiler accepts it with an explicit cast though. With an implicit cast
it produces a warning

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220706/7c632e8d/attachment.sig>