[Ffmpeg-devel] [PATCH] AVISynth support

[Michael Niedermayer]

Hi

On Thu, Aug 17, 2006 at 01:46:27PM +0200, Steve Lhomme wrote:
> Michael Niedermayer wrote:
> >Hi
> >
> >On Wed, Aug 16, 2006 at 11:45:07PM +0200, Steve Lhomme wrote:
> >>Hi,
> >>
> >>As we just added AVISynth support to DrFFMPEG I thought it would be nice 
> >>to share with the bigger FFMPEG community. So here is a patch against 
> >>latest SVN.
> >
> >[...]
> >
> >ok heres a quick review (ill do a full review if someone against my 
> >expectation fixes the found issues)
> >
> >the demuxer accesses various internal variables of the stream layer this is
> >not ok, neither is it ok if the demuxer accesses avisynth stuff, this 
> >belongs
> >only to the stream layer
> >
> >the correct way to implement this is to let the avisynth_protocol transform
> >the stuff from avisynth to a simple "virtual" file, your code does that 
> >already partially, but instead of passing all data through, your demuxer 
> >just
> >accesses various internal strctures from the avisynth_protocol
> >if you would implement this without such hacks then you wouldnt need a
> >new demuxer at all but the avisynth_protocol could directly be used by the
> >avi demuxer ...
> 
> So instead of the current hack you prefer to hack the AVI demuxer ?

no, of course not, the avi demuxer does ot need to be changed at all


> 
> FYI AVISynth outputs raw frames. Right now the virtual file creates a 
> interleaved stream which each frame in raw format (audio and video). If 
> it was to be used as this, none of the probe existing would recognise 
> the stream as AVS. That's why the pseudo-demuxer part is needed. Now you 
> want to put it in AVI. OK, but what does AVI have in common with an 
> interleaved raw format ? Or should the virtual file generate fake RIFF 
> headers too ? 

of course, should it create them, currently you take the various AVI
structures from AVISynth and decode them using duplicated code, they should
simply be placed in the virtual AVI file and the few missing headers be 
added than you have a complete avi file which can be demuxed


> If so that's more work that I'm willing to put in this 
> working solution.

as expected


> 
> >>Index: libavutil/avutil.h
> >>===================================================================
> >>--- libavutil/avutil.h	(revision 6005)
> >>+++ libavutil/avutil.h	(working copy)
> >>@@ -70,6 +70,7 @@
> >>     PIX_FMT_XVMC_MPEG2_IDCT,
> >>     PIX_FMT_UYVY422,   ///< Packed pixel, Cb Y0 Cr Y1
> >>     PIX_FMT_UYVY411,   ///< Packed pixel, Cb Y0 Y1 Cr Y2 Y3
> >>+    PIX_FMT_YVU420P,   ///< Planar YUV 4:2:0 (1 Cb & Cr sample per 2x2 Y 
> >>samples)
> >>     PIX_FMT_NB,
> >> };
> >
> >PIX_FMT_YVU420P is PIX_FMT_YUV420P with the pointers to the U and V
> >planes exchanged it doesnt need an new format id and neither needs a
> >memcpy() based conversation routine, exchanging the pointers is enough
> 
> Exchanging the pointer ok, but where ? 

in the raw video decoder


> If that's in the demuxer it's 
> possible (even though it's ugly).

i dont want to know how you are going to exchange pointers in the demuxer
considering that these pointers arent in the demuxer


> If it's somewhere else, how do you 
> know you're dealing with YUV420P or YVU420P if they use the same ID ?

codec_tag

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is