[Ffmpeg-devel] Re: [PATCH] DVCPRO50 support
Fri Mar 3 21:51:54 CET 2006
On Fri, Mar 03, 2006 at 10:27:31AM +0100, Baptiste COUDURIER wrote:
> Roman Shaposhnick wrote:
> > On Fri, Mar 03, 2006 at 01:05:46AM +0100, Baptiste COUDURIER wrote:
> > [...]
> >>IMHO It would simpler to handle wrapping in
> >>different containers (thinking about MOV), which must be different.
> > Do you have any particular concern in mind ?
> Yes, in MOV, DVCPRO50 fourcc is 'd5vn' for NTSC, 'dv5p' for PAL. DVCPRO
> fourcc is 'dvpp' for PAL (yuv420p and 25mbits/s) and DV is 'dvc ' for
> NTSC, 'dvcp' for PAL.
> If I want to fix movenc.c to properly set fourcc, I need to check
> pix_fmt and bitrate and even resolution or framerate, while a different
> codec_id would make me only check for resolution or framerate.
So it would be correct to say that you don't have an issue with the
decoding side using single codec ID, just with the encoding side ?
If that's so -- I agree we've got a problem there. But the problem on
the encoding side (at least for DV) is much larger that just
having two separate codec ids. The way DV is being handled by AVI
and MOV containers is just braindead -- every tool expects the
AVI-type1 sort of thing regardless of the fact that container format
provides a perfectly legal way of dealing with this issue.
So putting my DV maintainer hat on: I think that we have to address
this issue first and depending on what our solution will be -- the
decision on either separating codec ids or not will follow.
As a general statement, though, I also think that the problem with the
encoding side requiring libavformat to know all the gory details
about codec capabilities and how they translate into fourcc and such
is wrong. However, multiplying codec IDs is too heavy-weight. We need
some lighter version of id (not requiring filling up a complete
AVCodec structure for example) to communicate this information
back to libavformat.
More information about the ffmpeg-devel