[FFmpeg-soc] [soc]: r3757 - libavfilter/diffs/01_ffplay_filters.diff

[Stefano Sabatini]

On date Saturday 2008-10-04 00:37:49 +0200, Michael Niedermayer encoded:
> On Fri, Oct 03, 2008 at 04:50:00PM +0200, Stefano Sabatini wrote:
> > On date Friday 2008-10-03 02:11:39 +0200, Michael Niedermayer encoded:
> > > On Thu, Oct 02, 2008 at 10:48:41PM +0200, stefano wrote:
> > > > Author: stefano
> > > > Date: Thu Oct  2 22:48:41 2008
> > > > New Revision: 3757
> > > > 
> > > > Log:
> > > > Fix a crash when using the rawvideo decoder in ffplay.
> > > > 
> > > > The rawvideo decoder uses the packet data to set the data in the
> > > > output AVFrame, so when the packet containing the data was released in
> > > > get_video_frame(), then the AVFrame data was released as well, and
> > > > when accessed caused a crash.
> > > 
> > > this change looks wrong
> > > and i dont mean just the indention
> > 
> > Do you mean only the code or the idea also is in itself wrong? Please
> > give me some hint, so I can fix it as fast as possible.
> 
> checking for a specific codec_id and then handling packets differently
> is not a good idea at all

Yes I agree.

Currently the input buffer in raw_decode() is used to fill the output
picture in avpicture_fill().

The first trivial solution which I can see is to create a new buffer
and memcopy the old one into it, then use this one to fill the
picture. This way we can safely free the input data buffer and still
be able to access the output frame, check the attached patch.

This would affect performance of course but I cannot see other safe
solutions.

Maybe we could set a flag somewhere telling not to duplicate the
buffer, then we could somehow "instruct" the packet to not to free the
data when we free it but I'm not sure this is possible, suggestions
are welcome.

(If it's the case I'll move the thread to ffmpeg-devel).

Regards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rawdec-memcpy-00.patch
Type: text/x-diff
Size: 957 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20081004/086d53e4/attachment.patch>