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

Michael Niedermayer michaelni
Wed Nov 3 20:18:00 CET 2010


On Wed, Nov 03, 2010 at 08:04:57PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2010-11-02 07:57:17 +0100, Reimar D?ffinger encoded:
> > 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).
> 
> Adding a CODEC_CAP_VFLIP should fix the problem, we set the flag in
> the codecs which support that and propagate the bit telling if the
> picref data is vflipped (vflip swaps the bit) up to the decoder, if
> not supported we need a memcpy. I'll try to come with a proof of
> concept, if you have better ideas please share.

you dont need to propagate the bit, linesize < 0 should do

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101103/28a5b604/attachment.pgp>



More information about the ffmpeg-devel mailing list