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

[Patrik Kullman]

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?
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?