[FFmpeg-devel] [WIP] Fix unnecessary memcpy in ffmpeg when libavfilter is enabled

Reimar Döffinger Reimar.Doeffinger
Tue Nov 2 07:57:17 CET 2010

On Mon, Nov 01, 2010 at 09:32:58PM -0400, Alexander Strange wrote:
> On Nov 1, 2010, at 9:28 PM, Michael Niedermayer wrote:
> > On Tue, Nov 02, 2010 at 02:23:45AM +0100, Stefano Sabatini wrote:
> >> Hi all,
> >> 
> >> check this one. Again another big patch stack to climb before to reach
> >> the top, and I suspect that there are problems with direct rendering
> >> for some codecs, the given patches compile but then they fail
> >> regressions (FFV1 and snow in particular).
> >> 
> > 
> >> Also ffplay always crash when playing a FFV1 file, maybe someone can
> >> have look at it.
> > 
> > its because the buffer is released before its returned
> > 
> > 
> >> 
> >> Also I wonder how should we fix the vflip+DR -> crash problem, if we
> >> should enable codecs to work with reversed frames or if we should
> >> inhibit direct rendering when hflipping is detected in the
> >> filterchain.
> > 
> > CODEC_CAP maybe, but this needs more thought
> Is there any situation where someone would want their video vflipped? I don't think it's worth keeping track of what supports negative stride.

Uh, there are a few rare framebuffer formats that are flipped.
Also video stupidly encoded from BMP files end up flipped.
So far I haven't consider support for flipped stride optional,
the API documentation certainly does not give the slightest
hint to that.
At the very least, please do not think only of ffmpeg but make
sure any other libav* user will become aware, that means at the
very least an explicit stride check for every codec that doesn't
support arbitrary values (not only negatives, but also e.g. stride == 0).

More information about the ffmpeg-devel mailing list