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

[Baptiste COUDURIER]

Dan Maas wrote:
>>That fixes pix_fmt detection on most dv streams.
> 
> 
> Thanks, this looks good to me.

Nice.

> The problem with DV in MOV is that the packet formatting functions in
> libavformat/dv.c are never called at all.
> 
> (except for a small piece in dvvideo_encode_frame(), which is just a
> hack so that dv_frame_profile() works).
> 
> This is the architecture issue I pointed out earlier. If you want
> fully working DV-in-MOV you will need to do two things:
> 
> 1) Fill in all of the headers. This will involve moving
> dv_format_frame() and associated functions into the avcodec, and
> calling them from dvvideo_encode_frame().

We encoutered that specific problem with h264 too. Point where we all
agreed was that encoder must create a working elementary stream,
bytestream or format defined in specifications.

> 2) Fill in the audio samples. This is the hard one. My first instinct
> is to add a special callback function from the MOV/AVI avformat
> wrappers, to tell the video codec that audio samples are available.
> But I'm not very familiar with the guts of muxing, so perhaps there is
> an easier way.

It could be called from movenc, I figured out how to recreate a good
frame, filling frame with unneeded garbage audio, but point is, can a
DVVIDEO frame be found without audio nor headers. Does it even exists ?

There are some MOV samples generated by FCP with DVCPRO, DVCPRO50,
DVCPROHD on archive:

http://www.mplayerhq.hu/MPlayer/samples/mov/FCP/

I guess finding a solution without audio would be the best, and we need
to define what a 'raw' DV stream is.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312