Commit 39d32b23 authored by Committed by Thibault Saunier
qtdemux: Find mp4a esds atoms in protected streams sample description tables.
This problem was found in Test. 2 of the YouTube 2018 EME tests. 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, they also noted the asymmetry with mp4v and mp4a.  https://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2018.html?test_type=encryptedmedia-test  gstreamer/gst-plugins-good#398
Showing with 12 additions and 18 deletions