qtdemux: Find mp4a esds atoms in protected streams sample description tables.
authorCharlie Turner <cturner@igalia.com>
Thu, 7 Feb 2019 11:58:19 +0000 (11:58 +0000)
committerThibault Saunier <tsaunier@gnome.org>
Fri, 15 Mar 2019 12:41:33 +0000 (12:41 +0000)
commit39d32b239490bd13bd58548d16f7df881a282771
tree92b83952756e92694413a6f9a8419ac0f496e84e
parent3160713abf3b216870054cc4e09791f09f9b3140
qtdemux: Find mp4a esds atoms in protected streams sample description tables.

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 an incorrect codec_data field being sent
into aacparse. The advertisement of stereo audio @ 44.1kHz for the
mp4a (unprotected) stream was incorrect. As usual, the esds contained
the real values here which were mono at 22050 Hz.

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] https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/398
gst/isomp4/qtdemux.c