[FFmpeg-devel] [PATCH] [RFC] libavcodec/h264_mp4toannexb_bsf.c: Copy const data

[Michael Niedermayer]

On Mon, Feb 16, 2009 at 09:24:45PM +0100, Benoit Fouet wrote:
> Patrik Kullman wrote :
> > On Mon, 2009-02-16 at 17:44 +0100, Benoit Fouet wrote:
> >   
> >> On 02/16/2009 04:50 PM, Benjamin Larsson wrote:
> >>     
> >>> Benoit Fouet wrote:
> >>>   
> >>>       
> >>>>> ===================================================================
> >>>>> --- libavcodec/h264_mp4toannexb_bsf.c	(revision 17373)
> >>>>> +++ libavcodec/h264_mp4toannexb_bsf.c	(working copy)
> >>>>> @@ -58,7 +58,7 @@
> >>>>>  
> >>>>>      /* nothing to filter */
> >>>>>      if (!avctx->extradata || avctx->extradata_size < 6) {
> >>>>> -        *poutbuf = (uint8_t*) buf;
> >>>>> +        memcpy(*poutbuf, buf, buf_size);
> >>>>>          *poutbuf_size = buf_size;
> >>>>>          return 0;
> >>>>>      }
> >>>>>
> >>>>>     
> >>>>>       
> >>>>>           
> >>>> Index: libavcodec/h264_mp4toannexb_bsf.c
> >>>>
> >>>> you are missing the fact that output buffer is not allocated at that time.
> >>>> BTW, I don't think copying is a good idea, but the fact that output and input data can be the same should be documented, as already told someone else.
> >>>>
> >>>> Ben
> >>>>
> >>>>   
> >>>>     
> >>>>         
> >>> Thus violating the const qualifier ?
> >>>
> >>>   
> >>>       
> >> the BSF part is weird regarding that case.
> >> If the input is not filtered, it just overwrites the output buffer
> >> address...
> >> I don't know what should be done:
> >>  - let things as they are, but document them;
> >>  - change the input to not const, and document why;
> >>  - break the BSF API and use a special return value when no process has
> >> been done, and user should use its input as output;
> >>  - your ad here
> >>
> >> really, I don't know, but I must admit this is not something that
> >> bothers me that much ;)
> >>
> >> Ben
> >>     
> >
> > Can't the API just pass one buffer and the filter can do what it wants
> > with it?
> >
> > Input/output sounds like unnecessary copying even if filtering is done?
> >   
> 
> at the moment, no useless copy is done, but I agree the documentation is
> missing for BSFs
> 
> > Some filters might be able to just modify the buffer, and some might
> > have to create small buffers and then write back, but overall it should
> > mean less copying?
> >
> >   
> 
> and some would need to create anyway another buffer, either larger than
> the input one or not, to handle what they have to.

we could drop the const and add a flag that says that the input buffer may
be changed
and of course document things ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090217/6e875976/attachment.pgp>