On 01/03/14 03:27, Tim Walker wrote: > Then, HEVC muxing is already enabled for matroskaenc and movenc with > MODE_MOV, both seemingly unintended side effects of decoding support > added in 959bea1 and ea29f96. Since we don't write the extradata > properly nor reformat the input packets when they're in Annex B > format, should: > > - fixing these issues (extradata, Annex B -> NAL prefixes) warrant a > version bump? OR - fixing these issues (extradata, Annex B -> NAL > prefixes) warrant backporting to libav10? AND/OR - HEVC muxing in > libav10 be disabled so as to not spread invalid files? > > - adding support for HEVC muxing in MODE_MP4 warrant a version bump? > OR - adding support for HEVC muxing in MODE_MP4 warrant backporting > to libav10?
It should be fixed and backported if is quick enough, I wanted to get libav10 out within the week... > It would seems that the easiest and/or more correct solution would be > to use 'hev1' and format the hvcC accordingly, though there are > further considerations: > > - movenc was set up to use 'hvc1' for MODE_MOV - see above - but > since we do not write the hvcC at present, the produced files are > invalid regardless of what name is used for sample entries, so we > should probably just fix it to match MODE_MP4 once we've decided what > to do Yes. > - according to Yusuke Nakamura, some players (don't know which ones) > only support files with 'hev1' sample entries, whereas others only > support files with 'hvc1' sample entries (and some support both), > though someone did suggest "screw broken players, do the right > thing" avoption to the rescue I guess. > - some software (e.g. VLC) already produce files with 'hvc1', though > TBH I don't know whether they'd be very widespread or if it's > terribly relevant to what we should do We will end up supporting both formats, just make sure we do not generate invalid files. I have already a patch to add standard support to muxers, I'll work on it today. > - we could theoretically use 'hvc1' and filter the bitstream of any > further parameter sets, possibly adding additional sample entries and > storing them there instead Sounds an interesting approach. > - I may have misread ISO/IEC 14496-15, (obviously) feel free to point > out any mistakes on my part I hadn't read it if needed I will in 3 days. > There could always be an option to switch between the two, I suppose > (though this would still require a default value). The default is the easy-to-mux-ts-sources one IMHO. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
