[Libav-user] Questions regarding change in lib behaviour for mpeg2 fourCCs in mov

[Robert Krüger]

On Wed, Oct 30, 2013 at 12:52 PM, Robert Krüger <krueger at lesspain.de> wrote:
> On Wed, Oct 30, 2013 at 12:32 PM, Paul B Mahol <onemda at gmail.com> wrote:
>> On 10/30/13, Robert Krueger <krueger at lesspain.de> wrote:
>>> Hi,
>>>
>>> a recent update of our application showed that setting the codec_tag
>>> for muxing no longer worked for mpeg2. AFAICS the reason is commit
>>> 713dcdbfcbaa305050ae6362e5131e0e2e705135.
>>>
>>> If I see this correctly, this means if I disagree for whatever reason
>>> with the fourcc that ffmpeg decodes on, my application has no way to
>>> override it. Is this intentional? Couldn't one imagine a case where I
>>> wanted or have to make that decision outside, be it to fulfill some
>>> proprietary requirements?
>>
>> Such as?
>
> For example, both xdcam codecs
>
> XDCAM HD 1080p25 VBR fourCC: xdv7
>
> and
>
> XDCAM EX 1080p25 VBR  fourCC: xdve
>
> Have the same frame rate, pixel format and resolution. If I write an
> application that reads XDCAM HD material and is supposed to e.g.
> create a subclip of that and store it in a new file with the same
> properties as the original quicktime file, I would no longer be able
> to do that after that change.
>
>>
>>>
>>> Is the behaviour regarding muxer and codec_tag defined somewhere?
>>>
>>> Thanks for any insights on this.
>>
>> IIRC that commit is there for some reason.
>
> Yes, to add heuristics for a common broadcast case, which are a nice
> convenience, which I think is good for a lot of users.
>
>>
>> If that commit disabled something which was possible before than
>> that may be bad/good.
>
> So it would be good to know. That's why I am asking because from an
> API user point of view, I do like autocalculation but also see the
> advantage/need to have an override option for people who know what
> they are doing. If the maintainer disagrees, that is of course fine.
> Then I will simply live with a patched version. A patch that lets the
> codec_tag set in the AVCodecContext override the calculated defaults
> (either by default or, if that is a problem in certain cases, by a
> muxer option like override_fourCC or something like that) is trivial.

I will make the patch and the maintainer can then decide whether to
accept or ignore it.