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

Robert Krüger krueger at lesspain.de
Wed Oct 30 12:52:42 CET 2013


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.


More information about the Libav-user mailing list