On Wed, Oct 30, 2013 at 12:52 PM, Robert Krüger <[email protected]> wrote: > 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.
I will make the patch and the maintainer can then decide whether to accept or ignore it. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
