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

[Stefano Sabatini]

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, 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. 

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

> > For example it could be used like this:
> > 
> >     if (is->video_st->codec->codec->capabilities & CODEC_CAP_USE_INPUT_BUFFER)
> >         pkt->destruct = av_destruct_packet_nofree;
> >     av_free_packet(pkt);
> 
> Maybe I am misunderstanding something, but this looks like a hack: if the
> destruct method should be av_destruct_packet_nofree(), why not setting it
> to av_destruct_packet_nofree() since the beginning (in the demuxer),
> instead of changing it before calling av_free_packet()?

Good point, attached patch implement this. I'm not really satisfied
with it, indeed in av_read_packet() we don't necessarily already know
the stream codec, in that case I'm using avcodec_find_decoder() to
find the codec and check for its capabilities, and I'm not completely
sure this is a safe solution.

> I do not know the libavfilter internals, but maybe this problem can be
> better solved by using some form of reference counting?
> (when I tried to think about a filter layer some years ago, I arrived to
> the conclusion that a reference counter for these buffers is needed)

There is already a reference counting mechanism implemented in
libavfilter, but it refers to the already allocated pictures rather
than to the input packet buffers.

Thanks for the reviews, regards.
-- 
FFmpeg = Frenzy Friendly Minimalistic Portentous Excellent Guru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-use-input-buffer-cap-01.patch
Type: text/x-diff
Size: 1705 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081006/fc8fc96e/attachment.patch>