On Wed, Oct 30, 2013 at 12:32 PM, Paul B Mahol <[email protected]> wrote: > On 10/30/13, Robert Krueger <[email protected]> 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. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
