Multiplexed ts to mp4 loses audio track when seeking backwards
theodab opened this issue · comments
Shaka Player uses mux.js to convert ts media into mp4. We have noticed an odd bug on some content; if the user performs an unbuffered seek backwards, the mp4-formatted data the transmuxer outputs suddenly stats having an empty audio track, which causes playback to freeze due to it not being registered as a buffered range by MediaSource. This might have to do with transmuxing the segments out of order or something? If we tear down the transmuxer and re-create it after every operation, the content plays without issue, which seems to suggest that mux.js is retaining some internal state that it shouldn't be. Calling the clear method doesn't seem to help.
The asset that triggers this problem is multiplexed TS content with both video and audio. We haven't seen this issue with any other sort of asset, thus far.
I have created a repro page for this bug, using the latest version of mux.js from npm:
https://storage.googleapis.com/shaka-demo-assets/_bugs/muxjs_state_bug/index.html
This page starts at a point late in the content, plays for a few seconds, then tries to seek back to an earlier point. If you press the "PLAY NORMALLY" button, it will use mux.js in a normal way, and the playback will freeze upon seek. If you press the "PLAY, REMAKING AFTER EVERY TRANSMUX" button, it will re-make the transmuxer after every operation, and will successfully seek back.
I also have a single segment of the asset, transmuxed both ways.
Here is the segment transmuxed in the normal way: https://storage.googleapis.com/shaka-demo-assets/_bugs/muxjs_state_bug/preFix218s.mp4
Here is the segment transmuxed, clearing the transmuxer after every operation: https://storage.googleapis.com/shaka-demo-assets/_bugs/muxjs_state_bug/postFix218s.mp4
In the failing sample, the audio track is empty, according to MP4Box.js.
I cannot reproduce it on 5.6.4.