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
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
