Hi On 25 October 2017 at 23:57, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
>> ISOBMFF only defines that AudioSampleEntryV1 should be used instead, >> in which case the sampling_rate is a 32 bits integer (ISO 14496-12 >> 12.2.3.2) > > Not sure I understand: > In ticket #6609, I asked if this is a flac-only issue. > You answered: "The issue can be reproduced with any codec." The issue can be reproduced with every codec. That is, every mp4 file with an audio sampling rate greater than INT16_MAX will have 0 for the sample_rate value. This will prevent those generated files to be played in Firefox for example. A sampling rate of 0 being treated as invalid. This is why I answered that the problem could be reproduce with any codecs. It is a problem with all audio codec when used with FFmpeg generated mp4. However, only the flac-in-isobmff defines on what to do. If we were to generalize the fix to other codec, then those files wouldn't be spec compliant either (though it's my belief it would be better if it were). > > So why does your patch only fix the issue for flac? > Or do I misunderstand? Only the flac-in-isobmff clearly states what to do under those circumstances. For the other format, there's no specific documentation on what should be done for how to store sampling rate value greater than 16 bits. ISOBMFF spec itself define an AudioSampleEntryV1 box instead which has the sampling rate store on 32 bits instead. FFmpeg doesn't support AudioSampleEntryV1 So the special fix for flac is one poor man's attempt to make things better without having to implement a much more complex fix. (That and few players supports AudioSampleEntryV1 either) Hope this help clarify the problem at hand better. Sorry if I didn't make things clearer earlier. JY _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel