[Ffmpeg-devel] [PATCH] AVISynth support

[Steve Lhomme]

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 ?

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 ? If so that's more work that I'm willing to put in this 
working solution.

>> 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 ? If that's in the demuxer it's 
possible (even though it's ugly). If it's somewhere else, how do you 
know you're dealing with YUV420P or YVU420P if they use the same ID ?

Steve