The behaviour appears to be worse when the mediasource isn't in ended state. For example: http://people.mozilla.org/~jyavenard/tests/mse_mp4/bipbop.html?eos=1&eosat=-1&duration=-1&init=0 will play 296 frames. while http://people.mozilla.org/~jyavenard/tests/mse_mp4/bipbop.html?eos=0&eosat=-1&duration=-1&init=0 will play 292 frames. This is not an issue related to the decoder being used: both Apple VT, ffmpeg and WMF provide the same results (though WMF without EndOfStream being called will only display 269 frames). In bug 1136138, the provided video will never play the last 4s, stopping at 141s even though we have 145s of buffered audio and video available.
this is the output of about:media http://www.dash-player.com/demo/4k/ mediasource:http://www.dash-player.com/64929df4-937d-6f43-8064-763b94fb3c63 currentTime: 141.546666 SourceBuffer 0 start=93.95833300000001 end=104.08333300000001 start=110.625 end=124.541667 start=124.58333300000001 end=144.666667 SourceBuffer 1 start=0 end=144.618666 Internal Data: Dumping data for reader 1378a1400: Dumping Audio Track Decoders: - mLastAudioTime: 141.546666 Reader 1: 12f84c800 ranges=[(134.976000, 144.618666)] active=true size=99836 Reader 0: 120d89000 ranges=[(0.000000, 141.546666)] active=false size=2860472 Dumping Video Track Decoders - mLastVideoTime: 141.958333 Reader 5: 130240000 ranges=[(134.958333, 144.666667)] active=true size=1623722 Reader 4: 12fd3c800 ranges=[(134.958333, 144.666667)] active=false size=3677905 Reader 3: 1306cd000 ranges=[(124.583333, 134.958333)] active=false size=17087051 Reader 2: 11ef90000 ranges=[(110.625000, 124.541667)] active=false size=23835477 Reader 1: 12d0dd800 ranges=[(99.250000, 104.083333)] active=false size=8235381 Reader 0: 1210a5000 ranges=[(93.958333, 99.291667)] active=false size=10070535 we have 144.66 worth of data, but we stop playback at 141.5466
Ok for that 4K video, the problem is elsewhere. The moof indicates that we have the data, but mdat missing those. Both chrome and IE stops at 141s too. so back to bipbop
With the 2nd stream; we don't call EOS ; as we don't call drain() (and we shouldn't) playback doesn't end nd instead is in "waiting" mode
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.