Affected versions

• Fx 68.0a1
• Fx 67.0b5
• Fx 66.0.1
• Fx 60.6.1esr

Affected platforms

• Windows 10 x64
• macOS 10.12

Steps to reproduce

1. Launch Firefox.
2. Open in one tab this link: https://www.imdb.com/title/tt2390361/videoplayer/vi3339102489?ref_=vi_nxt_ap .
3. Open in the next tab this link: https://www.imdb.com/title/tt2316801/videoplayer/vi3400709913?ref_=vi_nxt_ap
4. Skip ahead the video a few times then pause the video.
5. Set in focus the firs tab.

Expected result

• The video renders accordingly.

Actual result

• The image of the video is freezed.

Regression range

• Will return with the regression range as soon as possible.

Additional notes

• Make sure the video is fully loaded before skipping ahead(bug 1481496)
• Please note the screen cast: http://tinyurl.com/y38h5jef

Reproduces also with 66.0b14 for Linux.
Need to "Clear Data" from "Cookies and Site Data" about:preferences to reproduce again in the same instance.

I've used mozregression in order to find a regression window. Here are my findings:

Last good revision: 8bf380faae74e4921be6000496ca09d4a2c44e8d (2018-03-22)
First bad revision: d7b0d0e7228da9d690df6f105b865db973789c34 (2018-03-23)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8bf380faae74e4921be6000496ca09d4a2c44e8d&tochange=d7b0d0e7
228da9d690df6f105b865db973789c34

Thank you, Stefan!

Hi Nils, another one for you. Is this still a P2? (When do you think it will be fixed?)

Reproducible in Mac OS 10.12 on latest Nightly 69.0a1 (2019-06-10)
Build ID 20190610214846
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:69.0) Gecko/20100101 Firefox/69.0

I can reproduce this bug, will take a look.

This issue can be reproduced by simply seeking the video [1]. However, I think this issue is caused by bad muxed file. In the h264 bitstream, all key frames are contained in a non-I frame NALU, so we would mark those frames as non-key frames [2]. Then, as we can't find any iframe, seeking would fail and the video playback would be ended.

[1] https://bit.ly/31GoeVe
[2] https://searchfox.org/mozilla-central/rev/b3b401254229f0a26f7ee625ef5f09c6c31e3949/dom/media/mp4/MP4Demuxer.cpp#446

NI jya for a further confirmation. My opinion is to report this bad muxed file to IMDB.

(In reply to Alastor Wu [:alwu] from comment #7)

This issue can be reproduced by simply seeking the video [1]. However, I think this issue is caused by bad muxed file. In the h264 bitstream, all key frames are contained in a non-I frame NALU, so we would mark those frames as non-key frames [2]. Then, as we can't find any iframe, seeking would fail and the video playback would be ended.

[1] https://bit.ly/31GoeVe
[2] https://searchfox.org/mozilla-central/rev/b3b401254229f0a26f7ee625ef5f09c6c31e3949/dom/media/mp4/MP4Demuxer.cpp#446

---

NI jya for a further confirmation. My opinion is to report this bad muxed file to IMDB.

Normally I would agree.

However, you can seek just fine with Edge and Chrome on that file where they would normally fail just the same.

If we comment out the line in MP4Demuxer.cpp that override the keyframe flag, we can seek in the video just fine.

So maybe it's the key frame type detection that isn't detecting that those frames can be used with the decoder.

Sometime iframes might be put in non-IDR NALU if the file didn't be muxed well, instead of marking those frame as non-iframe, we could check whether these frames contain SEI, which is used to assists a decoder in determining whether decoder can produce correct or approximately correct frame in the given position, to decide whether they are real or fake iframes.

However, this method would have some visual artifact (video freezes for a short period) sometime, when you seek to the place where iframe doens't contain the SEI payload. However, it's still better than Chrome. On Chrome, evey time you seek, the video would be frozen until the playback end.

This is P2 and assigned, so I'm removing it from weekly regression triage by marking it fix-optional.
Happy to take a patch for 70 or in future.

When we play samples from start, even if samples are marked as key frame incorrectly, it won't cause any effect.

However, the correction of the keyframe flag is really important when we do seeking, so we acutally only need to do the keyframe correction during seeking.

As it's close to the merge day and this patch would affect all h264 video, I will land this patch on 71 after the merge day.

https://hg.mozilla.org/mozilla-central/rev/b51b4dcd9a8a

I’ve managed to reproduce this issue on an affected Nightly from 2019-03-26 using Windows 10x64 by following the STR from comment 0.
This is verified fixed on Firefox 71.0b7 using macOS 10.14, Windows 10x64, Windows 7x32 and Ubuntu 18.04x64.