[FFmpeg-devel] [PATCH] ffmpeg: redesign video resampling in case of mid-stream video size/format change

[Stefano Sabatini]

On date Thursday 2011-04-28 00:55:55 +0200, Stefano Sabatini encoded:
> On date Wednesday 2011-04-27 20:36:02 +0200, Michael Niedermayer encoded:
> > On Wed, Apr 27, 2011 at 10:51:54AM +0200, Stefano Sabatini wrote:
> > > On date Wednesday 2011-04-27 03:12:53 +0200, Michael Niedermayer encoded:
> > > > On Wed, Apr 27, 2011 at 02:34:55AM +0200, Stefano Sabatini wrote:
> > [...]
> > > > > The proper fix consists in dynamic mid-stream reconfiguration, which
> > > > > should fix the problem also for ffplay (which now crashes/misbehaves
> > > > > in that case). The nice thing with the video resampling context is
> > > > > that it can be applied to ffplay as well, and fixes the problem at the
> > > > > application level while a framework solution is developed (and fixes
> > > > > some of the issues with the non-libavfilter path).
> > > > 
> > > 
> > > > what is your oppinion of moving the format/size "equalization" into
> > > > a seperate filter? (that could be placed after vsrc_buffer like any
> > > > other filter, and would
> > > > pass frames through unchanged when they match the output)
> > > 
> > > This would be acceptable (and could be applied also to "fix" the movie
> > > souuce and the ffplay input).
> > 
> > great
> 
> On the other hand I'm already satisfied with the VideoResampleContext
> solution which is also already implemented (and could be used in
> ffplay.c as well), now that I think at it even the equalizer filter
> would be underkill (sure it could update the performed scaling
> according to the size of the input picref, but this wouldn't be
> reflected in the link properties, thus resulting intrinsically broken
> by design, even if somehow working). So please let's move and let's
> try to fix things properly.

Elaborating more, with direct rendering there is another problem:
get_buffer()/reget_buffer() will use the size/format defined in the
libavfilter source link, so it will fail again in case of midstream
size/format change.

The attached patches use the equalizing code in ffplay.c, but due to
the use of direct rendering it will fail with file issue-2217.mjpeg
(check ff_mjpeg_decode_sof, the code calling reget_buffer, the buffer
obtained by get_buffer() won't have the correct number of components
and will cause a segmentation fault) (but seems to work fine with
other files, e.g. 12.mpg and kgv1.avi).

So maybe the best thing is to start to work on the framework changes,
in the meaningwhile I'd prefer the application-level patch in order to
avoid to "pollute" the av_vsrc_buffer.h public API.
-- 
FFmpeg = Faithful and Fundamental Meaningful Perennial Ecumenical Ghost
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-cmdutils-move-VideoResampleContext-to-cmdutils.patch
Type: text/x-diff
Size: 10917 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110428/2d8af121/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-ffplay-add-support-to-mid-stream-video-changes-in-ff.patch
Type: text/x-diff
Size: 3097 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110428/2d8af121/attachment-0001.bin>