Bmx Merge Request #8: Sound sample description v2, 'wave' and 'chan' atoms (merged)

• Add support for version 2 of sound sample description, previously incorrectly dumped as ver. 1.
• Support atom types with non-printable characters, e.g. terminator atom type.
• Dump siDecompressionParam Atom ('wave').
• Dump Audio Channel Layout Atom ('chan').

Sound sample description before the changes:

stsd: s=       323 (0x00000143), o=     46719 (0x0000b67f)
  version: 0
  flags: 0x000000
  sample_descriptions (0x00000001):
    size: 00000133
    data_format: mp4a (6d 70 34 61)
    reserved: (size 6)  00 00 00 00 00 00  |......|
    data_ref_index: 0x0001
    version: 2
    revision: 0x0000
    vendor: .... (00 00 00 00)
    channel_count: 3
    sample_size: 16
    compression_id: -2
    packet_size: 0
    sample_rate: 1.000000
    remainder...: 271 unparsed bytes
      0000   00 00 00 48 40 e7 70 00  00 00 00 00 00 00 00 06  |...H@.p.........|
      ...

Sound sample description after the changes:

stsd: s=       323 (0x00000143), o=     46719 (0x0000b67f)
  version: 0
  flags: 0x000000
  sample_descriptions (0x00000001):
    size: 00000133
    data_format: mp4a (6d 70 34 61)
    reserved: (size 6)  00 00 00 00 00 00  |......|
    data_ref_index: 0x0001
    version: 2
    revision: 0x0000
    vendor: .... (00 00 00 00)
    size_of_struct_only: 72
    audio_sample_rate: 48000.00
    num_audio_channels: 6
    const_bits_per_channel: 0
    format_specific_flags: 0
    const_bytes_per_audio_packet: 0
    const_LPCM_frames_per_audio_packet: 1024
    wave: s=        91 (0x0000005b), o=     42486 (0x0000a5f6)
        frma: s=        12 (0x0000000c), o=     42494 (0x0000a5fe)
            data_format: mp4a (6d 70 34 61)
        mp4a: s=        12 (0x0000000c), o=     42506 (0x0000a60a)
          0000   00 00 00 00                                       |....|
        esds: s=        51 (0x00000033), o=     42518 (0x0000a616)
          version: 0
          flags: 0x000000
          descriptor:
            tag: 0x03
            length: 34
            es_descriptor:
              es_id: 0x0000
              stream_dep_flag: 0
              url_flag: 0
              reserved: 0
              stream_priority: 0x00
              descriptor:
                tag: 0x04
                length: 20
                decoder_config:
                  obj_profile_indication: 0x40
                  stream_type: 0x05
                  up_stream: 0
                  reserved: 1
                  buffer_size_db: 6144
                  max_bitrate: 768000
                  avg_bitrate: 768000
                  descriptor:
                    tag: 0x05
                    length: 2
                    decoder_specific_info:
                      0000   11 b0                                             |..|
              descriptor:
                tag: 0x06
                length: 1
                sl_config:
                  predefined: 0x02
        \x00\x00\x00\x00: s=         8 (0x00000008), o=     42569 (0x0000a649)
    chan: s=       144 (0x00000090), o=     42577 (0x0000a651)
      version: 0
      flags: 0x000000
      channel_layout_tag: 0x007b0006 ((123<<16) | 6)
      channel_bitmap: 0x00000000
      channel_descriptions (         6):
             i  channel_label  channel_flags          coordinates
          0000              1     0x00000000   0.00,  0.00,  0.00
          0001              3     0x00000000   0.00,  0.00,  0.00
          0002              2     0x00000000   0.00,  0.00,  0.00
          0003              5     0x00000000   0.00,  0.00,  0.00
          0004              6     0x00000000   0.00,  0.00,  0.00
          0005              4     0x00000000   0.00,  0.00,  0.00

[Philip de Nier]

Could you change the 2 x skip_bytes in dump_stbl_soun_v2 with dump_bytes? It's useful to see these bytes because they may contain actual data (e.g. if the file or parser is faulty) or not have the required data. Other than that it looks good to me.

[Alexey Kharkevich]

@philipn,

Makes sense.

The QuickTime format spec defines these values as integer fields: always3, always16, etc. Would it be more appropriate to dump them as separate named fields or dump_bytes is preferred?

[Philip de Nier]

I think seperate fields if the spec. defines them as such. This is similar to the reserved field in a number of places.

[Alexey Kharkevich]

Updated dump of "always" fields as hex integers:

sample_descriptions (0x00000001):
  size: 00000133
  data_format: mp4a (6d 70 34 61)
  reserved: (size 6)  00 00 00 00 00 00  |......|
  data_ref_index: 0x0001
  version: 2
  revision: 0x0000
  vendor: .... (00 00 00 00)
  always3: 0x0003
  always16: 0x0010
  alwaysMinus2: 0xfffe
  always0: 0x0000
  always65536: 0x00010000
  size_of_struct_only: 72
  audio_sample_rate: 48000.00
  num_audio_channels: 6
  always7F000000: 0x7f000000

[Alexey Kharkevich]

And another change to fix handling of "negative" char values in atom types:

Ensure that atom type characters are within range supported by isprint(), which accepts unsigned char or EOF. If char is signed it may fall outside the allowed range when passed as int to isprint(). Specific case is U+00A9 that triggers assertion violation in Visual Studio debug runtime.

Similarly, ensure that printf() outputs a 2-character hexadecimal representation of "negative" char rather than an 8-character representation.

Before:

\xffffffa9mod: s=        21 (0x00000015), o=  14017216 (0x00d5e2c0)

After:

\xa9mod: s=        21 (0x00000015), o=  14017216 (0x00d5e2c0)

[Philip de Nier]

Commits pushed, thanks.

I added a commit to change some of the naming, e.g. always3 -> always_3, ...LPCM... -> ...lpcm... to keep it consistent. On linux I get a build warning about strict aliasing rules which I fixed by using memcpy for the floating point convertion.