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

[Michael Niedermayer]

On Sun, Oct 05, 2008 at 04:16:16PM +0200, Stefano Sabatini wrote:
> On date Saturday 2008-10-04 16:17:20 +0200, Michael Niedermayer encoded:
> > On Sat, Oct 04, 2008 at 12:39:41PM +0200, Stefano Sabatini wrote:
> > > 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.
> > 
> > simply not freeing packets too early ...
> 
> Are we sure this is a viable solution?
> 
> In ffmpeg/ffplay outside of libavfilter this works because we process
> the input packet, *then* we free them in the same routine after we use
> the output packet, while in general when processing the input packet
> we don't know (and we shouldn't know) when we ended to process the
> corresponding decoded *output* frame/frames.

frames could have been allocated by (av_)malloc() by some API like SDL,
could physically be in video memory, ...
is a storeage shared with a AVPacket so different?


[...]
> I think this is possible but I'm not sure it is worth the complexity
> it adds, maybe a memcpy is just cheaper.

I do not plan to approve an unneeded memcpy() of all raw video data.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20081005/2f54c9cf/attachment.pgp>