[Libav-user] Questions regarding change in lib behaviour for mpeg2 fourCCs in mov
krueger at lesspain.de
Sun Nov 3 15:22:49 CET 2013
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:
>>> a recent update of our application showed that setting the codec_tag
>>> for muxing no longer worked for mpeg2. AFAICS the reason is commit
>>> 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
> 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.
More information about the Libav-user