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

Michael Niedermayer michaelni at gmx.at
Sat Oct 4 16:17:20 CEST 2008


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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/20081004/b5db5f24/attachment.pgp>


More information about the FFmpeg-soc mailing list