[Ffmpeg-devel] [PATCH] dv pixel format encoding fix

[Rich Felker]

On Fri, Mar 10, 2006 at 07:44:09PM -0800, Roman Shaposhnick wrote:
> On Fri, Mar 10, 2006 at 01:44:12PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Thu, Mar 09, 2006 at 11:00:07PM -0800, Roman Shaposhnick wrote:
> > [...]
> > > > what dv in mov is, is a sick double layer format, its the output of the
> > > > dv muxer put into mov, the only sane way to generate this if we really have
> > > > to support it and IMHO it would be better if we simply say "NO" to this mess
> > > > is to feed the seperate audio and video dv streams into the dv muxer and then
> > > > the combined muxed dv stream into the mov muxer, how to implement this
> > > > cleanly is not exactly obvious, one way would be to call the dv muxer from
> > > > the mov muxer to combine the streams
> > > 
> > >   That's pretty much what's going on in avi*.c on the decoding side when
> > >   DV-in-AVI type 1 is given to the ffmpeg. I also think this is the only
> > >   way to go, however, what's not clear to me is how widespread this double
> > >   layering could be. Is DV really special in that regard or do things like
> > >   AVI-in-MOV or some such happen in real life ?  
> > 
> > MPEG-PS in MOV 
> > 
> > vorbis in ogg in avi, the most braindead thing imaginable, vorbis due to
> > its variable number of samples _and_ bytes per packet is problematic in
> > avi, its possible to store but hackish, storing vorbis in ogg in avi has
> > no effect on the problem (obviously) as either you can or cannot correctly
> > store X in Y, a middle layer wont really help
> 
>   Wow! I have never suspected the world is *so* weird ;-)
> 
>   But anyway, the problem at hand (at least for DV) is not actually a decoding
>   one (although it will be a problem if I get around to implementing metadata
>   streams). The problem is with encoding. Or better yet -- with tools like 
>   FCP expecting to find audio in VIDEO only DV streams embeded in MOV and/or
>   AVI.
> 
>   IOW, we've got an application (ffmpeg in this case) happily doing:
>      
>      avcodec_encode_video(dv_encoder, buffer, buffer_size, &picture);
>      ...
>      pkt.data = buffer;
>      ....
>      av_interleaved_write_frame(mov_or_avi_output_format, &pkt);
> 
>   but in reality (in order to satisfy things like FCP) the last line should
>   more like:
> 
>      av_interleaved_write_frame_doubly_wrapped(mov_or_avi_output_format,
>                                                dv_output_format,
> 					       &pkt);
> 
>   Sooo, may be the right way would be to make applications deal with it by
>   providing 'av_interleaved_write_frame_doubly_wrapped' ?

Personally I'm of the opinion that we should not contribute to the
madness by supporting writing such broken output. Let the people who
insist on making files like this use an external tool from someone
else, which will make them realize that what they're doing is
incorrect and requires special hacks..

Rich