[Ffmpeg-devel] Re: [PATCH] DVCPRO50 support

Roman Shaposhnick rvs
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. 
  

Thanks,
Roman.





More information about the ffmpeg-devel mailing list