[FFmpeg-devel] [PATCH 18/18] h264_ps: pass AVCodecContext as void* where possible

[Michael Niedermayer]

On Wed, Mar 18, 2020 at 10:02:39AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-03-16 12:23:11)
> > On Sun, Mar 15, 2020 at 06:02:04PM +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2020-03-13 23:29:12)
> > > > On Fri, Mar 13, 2020 at 11:28:50AM +0100, Anton Khirnov wrote:
> > > > > Makes sure it is only used for logging and nothing else.
> > > > > ---
> > > > >  libavcodec/h264_ps.c | 18 +++++++++---------
> > > > >  1 file changed, 9 insertions(+), 9 deletions(-)
> > > > > 
> > > > > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> > > > > index 1951bb1161..4ef25aa514 100644
> > > > > --- a/libavcodec/h264_ps.c
> > > > > +++ b/libavcodec/h264_ps.c
> > > > > @@ -104,14 +104,14 @@ static void remove_sps(H264ParamSets *s, int id)
> > > > >      av_buffer_unref(&s->sps_list[id]);
> > > > >  }
> > > > >  
> > > > > -static inline int decode_hrd_parameters(GetBitContext *gb, AVCodecContext *avctx,
> > > > > +static inline int decode_hrd_parameters(GetBitContext *gb, void *logctx,
> > > > 
> > > > this is a double sided sword
> > > > while fields of logctx cannot be used its after this possible to pass
> > > > wrong things as logctx
> > > 
> > > Right, but that should be easily noticeable since it will crash on
> > > dereferencing the AVClass. I consider the danger of people accessing the
> > > AVCodecContext inappropriately to be bigger (since it's done in many
> > > places already).
> > > 
> > 
> > > But we might want to consider something like
> > > typedef AVClass* AVLogger
> > 
> > yes, if that ends up looking clean in practice then iam certainly in favor
> 
> That would require changes to the logging API though, so would be
> outside of the scope of this set.
> Are you objecting to the patch as it is?

no i dont really mind, iam fine with the code as it is before as well as after
the patch. Its better in one way worse in another. So really no reason for me
to be against this if someone else has a preferrance

Thanks

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200323/50e7715e/attachment.sig>