Skip to content

qtdemux: Find mp4a esds atoms in protected streams sample description tables.

Charlie Turner requested to merge chturne/gst-plugins-good:fix-undiscovered-esds-in-protected-mp4a-streams into master

This problem was found in Test. 2 of the YouTube 2018 EME tests[1]. The code was accidentally not finding an mp4a's esds atom in the sample description table when the stream was encrypted. It assumed that if the stream is protected, then only an enca atom will be found here. What happens with YouTube is they often provide protected content with a few seconds of clear content, and then switch to the encrypted stream.

The failure case here was no codec_data being sent into aacparse since it wasn't found in the esds atom.

Here's what the MP4 tree looks like for these types of files, demonstrating why the code was making a wrong assumption (or maybe YouTube is being unusual),

[ftyp] size=8+16
...
[moov] size=8+1571
...
  [trak] size=8+559
...
          [stsd] size=12+234
            entry-count = 2
            [enca] size=8+147
              channel_count = 2
              sample_size = 16
              sample_rate = 44100
              [esds] size=12+27
                ...
            ...
            [mp4a] size=8+67
              channel_count = 2
              sample_size = 16
              sample_rate = 44100
              [esds] size=12+27
                ...

In addition to fixing this, the checks for esds atoms in mp4a and mp4v have been made symmetrical. While I haven't seen a test case for video with the same problem, it seemed better to make the same checks. This also fixes a crash reported from another user[2], they also noted the asymmetry with mp4v and mp4a.

[1] https://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2018.html?test_type=encryptedmedia-test

[2] #398 (closed)

Edited by Charlie Turner

Merge request reports