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

[Benoit Fouet]

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.

What's wrong with documenting the current behavior ?

Ben