[FFmpeg-trac] #1767(avformat:new): 24bit audio in mov is flagged as 16bit in stsd atom

FFmpeg trac at avcodec.org
Mon Oct 1 16:20:43 CEST 2012


#1767: 24bit audio in mov is flagged as 16bit in stsd atom
------------------------------------+------------------------------------
             Reporter:  nichot20    |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avformat
              Version:  git-master  |               Resolution:
             Keywords:  mov         |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------

Comment (by nichot20):

 Replying to [comment:5 nichot20]:
 > Replying to [comment:3 muken]:
 > > According to qtff.pdf, when a sound sample description is version=1 or
 2, sample size field shall be set to 16.
 > > So, it is not a bug.
 > > The actual sample size is placed more downward.
 > > Early sample size field shall be ignored by readers.
 >
 > I note that both the original, and stream copied file have stsd
 version=0, not the 1 or 2 you mention.
 >
 > Looking at the code the value is set based upon the value of
 AV_CODEC_ID_* when (version != 2) and comparison with the original file
 shows that Quicktime Pro uses a value of 24.
 >
 > The only other differences to the original file seems to be that QT Pro
 adds in the extended version info which ffmpeg only adds for version 1
 (line 672)


 I have now managed to obtain a later copy of qtff.pdf dated 2012-08-14. It
 would appear that the correct behavior is indeed for stsd->sample size to
 be only either 8 or 16 for ''all'' versions of stsd. '''But''' if the
 actual sample size is greater than 16 bits, then the version should be
 changed to version 1 and the "bytes per packet" set to reflect the actual
 value (pages 178-179). Unfortunately Quicktime Pro 7 does not seem to
 follow this convention, which misled me.

 However mov.c is also behaving incorrectly as it is not changing the
 version from 0 to 1, and adding in the "Sound Description V1 extended
 info" for bit depths greater than 16 in order to provide the correct
 value. This can lead to some applications trying to handle the sound as 16
 bit.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1767#comment:6>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list