GNOME Bugzilla – Bug 593647
ffdec_flashsv doesn't work
Last modified: 2010-01-16 16:26:42 UTC
Created attachment 142116 [details] example video Playing back Screen video is broken. The decoder seems to replace the previous picture to an all black image when decoding a new picture. It works in mplayer. An example video is attached.
Confirming. Mplayer even works when using the same ffmpeg/avcodec libraries as gst-ffmpeg in git. Here's a snippet from libavcodec/flashsv.c for the bitstream description of Flash Screen Video decoder: "Directly after the header are the compressed blocks. The blocks have their compressed size represented with 16bits in the beginnig. If the size = 0 then the block is unchanged from the previous frame. All blocks are decompressed until the buffer is consumed." This points out that previous frame should be preserved (and the codec implementation is not doing that for us). On the other hand, the gst plugin seems to only allocate an empty buffer for the next frame. The example video is a desktop recording, which contains a lot of unchanged regions, thus major parts of the frames show as black. I already wrote a quick hack to fix this, but it needs some checking to avoid breaking stuff elsewhere, since the gst plugin handles all codecs in one place.
Created attachment 142679 [details] [review] Patch to preserve unchanged blocks for flashsv decoder
Wouldn't it be far better to check what the idea of the ffmpeg API is? Should buffers be kept around? If so, ffdec should keep the buffer around for all plugins. There might be other plugins that require this behavior where we haven't found out yet. If not, someone should fix ffmpeg's flashsv decoder instead of adding hacks to ffdec that make it even more incomprehensible.
I didn't find any way to handle it when using flashsv. But, I had a chat with the friendly developers at #ffmpeg-devel over this matter. The current implementation in flashsv does not support preserving the unchanged data, so I was asked to file a bug: https://roundup.ffmpeg.org/roundup/ffmpeg/issue1367 Let's see if it can be fixed there. Meanwhile, feel free to ignore the ffmpegdec patch.
Looks like this will be fixed in ffmpeg. I'm closing this bug as NOTGNOME now. Baptiste Coudurier wrote: > Baptiste Coudurier <baptiste.coudurier@gmail.com> added the comment: > > On 09/09/2009 12:57 AM, Jarkko Palviainen wrote: > >> New submission from Jarkko Palviainen<jarkko.palviainen@sesca.com>: >> >> flashsv/libavcodec should keep the previous frame in case the current >> contains unchanged blocks, so that application side does not have to >> handle it explicitly. Otherwise it may lead to video output containing >> black regions. >> > > Looks like reget_buffer should be used.
It's now fixed in ffmpeg side (r19814). AFAIK, this still requires implementing reget_buffer() in gstffmpegdec.
Fixed now by importing a newer ffmpeg snapshot. commit eaac8503c0885924496d999e2f5377909522eb23 Author: Edward Hervey <bilboed@bilboed.com> Date: Wed Jan 6 11:53:01 2010 +0100 ffmpegrev: Bump to ffmpeg r21150 from Jan 11th 2010