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

[Måns Rullgård]

Michael Niedermayer said:
> Hi
>
> On Thu, Mar 02, 2006 at 07:57:23PM -0500, Dan Maas wrote:
> [...]
>> With regards to Baptiste's question of "why not a different codec?"-
>> DV25 and DV50 share so much code (probably 95%) that I don't see a
>> reason to split them up. In the future I may add DV100 (DVCPRO HD) to
>> the mix as well. You can determine the flavor of DV unambiguously just
>> by looking at the resolution and pixel format.
>
> for encoding, the supported pixel formats are a field of AVCodec, now if
> dv would support 2 pixel formats and independant of that one or more
> resolutions then a single codec_id would be fine but dv has a very strict
> small set of supported resolution-pix_fmt-framerate, other mixes arent
> allowed and in case of resolution-pix_fmt would need some new tables to
> be invented
>
> so while a single codec_id for encoding would work fine, the end user
> would be much more happy i think if you would add several so an application
> like ffmpeg.c could automatically select a supported pix_fmt and framerate
> from the codec_id, note, the only change for this is to duplicate your
> AVCodec structure and fill in the pix_fmt/framerate/name and register that
> AVCodec no need to touch or split any of th actual code, and for decoding
> you will probably use a single codec_id for for all ...
>
> iam not sure what to do at the remuxing side, but it seems the mov muxer
> will still have to check for resolution/framerate/... to find a valid
> codec_tag as in case of remuxing the codec_id would be the generic dv
> decoder one
>
> if anyone, mans? has another suggestion for how the same end user
> friendliness could be achived then speak up ...

The problem with separate codec IDs is that it makes it impossible for the
user to request DV encoding without knowing which codec ID goes with which
pixfmt/resolution/framerate combo.  The better model from a user perspective
would be to have the DV encoder select the variety that matches the input,
or return an error if the parameters are not supported.

To facilitate automatic selection of conversions to apply before encoding,
I vote for inventing those new tables.  I'll do a survey of restrictions
is various codecs and see if I can think of a sensible solution.

-- 
M?ns Rullg?rd
mru at inprovide.com