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

[Stefano Sabatini]

On date Monday 2008-10-06 23:56:53 +0200, Luca Abeni encoded:
> 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.

I can't understand here.

The packet data buffer will be freed when the output frame will be
freed.

Also in the two threads scenario the first thread, after the call to
av_free_packet (which in this case won't free the input packet data,
since that buffer is set in the output frame), simply will pass the
output frame to some queue with locked access accessed by the second
thread (similar to what happens in ffplay).

I can't see how this can lead to some race condition.

> > 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 :)

The packet destruct callback is set to av_destruct_packet_nofree, so
the input packet data is not freed.

Regards.
-- 
FFmpeg = Foolish & Furious MultiPurpose Ecstatic Gorilla