[FFmpeg-devel] [PATCH] Add a CODEC_CAP_USE_INPUT_BUFFER capabilities flag

[Luca Abeni]

Hi Stefano,

Stefano Sabatini wrote:
> On date Monday 2008-10-06 08:41:51 +0200, Luca Abeni encoded:
>> Hi,
>>
>> Stefano Sabatini wrote:
>>> Hi all,
>>>
>>> the new flag will be useful for example in libavfilter when the output
>>> frame is accessed *after* the call to av_packet_free().
>> I am not sure I understand the situation, but if libavfilter is accessing
>> a buffer after freeing it, then I guess this is a bug in libavfilter...
>> Why not calling av_packet_free() only after libavfilter finished to access
>> the buffer?
> 
> I don't know if this is possible in libavfilter

If it's not possible, then I suspect this is a bug: accessing a buffer after
having freed it is always a bug. But maybe I am missing some details about
libavcodec's internals... :)


> but consider this
> situation: two threads working concurrently, the first one extracting
> packets and decoding them, then the decoded frames are sent to another
> thread which process them.
> 
> Since the rawdec decoder uses the same input buffer to set the data
> buffer in the decoded frames, you can't free the input packet data and
> *then* access the decoded frame.
> (BTW I think there are other codecs with this property, I think at
> least the raw audio decoders, I'll check it better if the general idea
> I'm pushing will prove to be correct).
> 
> In this case it's very difficult to free the packet only *after* the
> output frame has been accessed, since this requires a synchronization
> between the two threads which should be ideally independent. 

If you do not want to synchronise the two threads, the only solution is
to duplicate the buffer.

Your solution ends up with never freeing the buffer, and I suspect
a race between the two threads, with the decoder decoding a frame
into a buffer before the second thread can process the previous
frame.


> Making the decoding process aware of the fact that the packet data has
> not to be freed seems to me like a simpler solution.

But I do not see anything similar in your patch :)


			Luca