[FFmpeg-devel] [PATCH] ultimotion: use reget_buffer() in ulti_decode_frame()

[Michael Niedermayer]

On Wed, Apr 27, 2011 at 12:18:30PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2011-04-26 11:49:49 +0200, Stefano Sabatini encoded:
> > Also remove unnecessary call to avctx->release_buffer(). reget_buffer
> > is required since apparently the coded needs to be passed the previous
> > frame data again.
> > 
> > Releasing the frame and using get_buffer was working only in the case
> > get_buffer() was returning the old frame data again, and resulting in
> > playback artifacts otherwise.
> > 
> > Fix trac issue #78.
> 
> Adding libav-devel to recipients, to let Kostya comment on it.

>  ulti.c |    7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> be356bf26cf2b458119c71b7202e0b421d8be8a3  0002-ultimotion-use-reget_buffer-in-ulti_decode_frame.patch
> From 4434561b61bfc59ef321a93f086c9bade18e919e Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini <stefano.sabatini-lala at poste.it>
> Date: Tue, 26 Apr 2011 11:45:40 +0200
> Subject: [PATCH] ultimotion: use reget_buffer() in ulti_decode_frame()
> 
> Also remove call to avctx->release_buffer(), which would prevent
> reget_buffer to get the previous image data. reget_buffer is required
> since apparently the codec needs to be feeded with the previous frame
> data.
> 
> Releasing the frame and using get_buffer was working only in the case
> get_buffer() was returning the old frame data, and resulting in
> playback artifacts otherwise.
> 
> Fix trac issue #78.

patch has been applied and pulled

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110428/6d16c0e1/attachment.asc>