For some videos in IMDb, if you skip to a time via the progress bar, you'll get 'Sorry, an error has occurred while attempting video playback. Please try again later'

RESOLVED FIXED in Firefox -esr52

Status

()

defect
P1
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: rick3162, Assigned: jya)

Tracking

({regression, testcase-wanted})

51 Branch
mozilla55
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(platform-rel +, firefox-esr52 fixed, firefox53 wontfix, firefox54+ fixed, firefox55+ fixed)

Details

(Whiteboard: [platform-rel-Amazon][platform-rel-IMDb], )

Attachments

(6 attachments, 2 obsolete attachments)

For some videos in IMDb if you skip to a time via the progress bar, you'll get 'Sorry, an error has occurred while attempting video playback. Please try again later' every single time.

STR
- in a fresh FF53 x64 profile in win10 x64, open either of these trailer video links:
http://www.imdb.com/video/imdb/vi4030179609?playlistId=tt2390361
http://www.imdb.com/title/tt2017020/videoplayer/vi2897651993
http://www.imdb.com/title/tt2316801/videoplayer/vi2080616217
(these videos)
- as the video starts to play, click anywhere on the progress bar to skip to any time: after a few secs you'll get 'Sorry, an error has occurred while attempting video playback. Please try again later'.
- try to refresh the page (F5 or Ctrl+F5) and repeat: it occurs every single time.
- there's no error in Web Console while this occurs.
- On the other hand, if you just let the video play (i.e.) without skipping) instead, 
then playback completes ok.

Also, this, doesn't occur in Chrome 58, Edge 38 or IE 11.
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0

Hi and thanks for the report!

Following the STR from comment 0, I was able to reproduce the issue on all Firefox channels, using Windows 10, Ubuntu 16.04 LTS and MAC OS X.
On the Nightly channel, there are a couple of warnings displayed on the Web console (please see the attachment).
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: General → Audio/Video: Playback
Ever confirmed: true
Product: Firefox → Core
Version: 53 Branch → Trunk
> thanks for the report!
You're welcome!

> On the Nightly channel, there are a couple of warnings displayed on the Web console (please see the attachment).

I was mistaken: these warnings on Web Console appear on FF 53 stable too:
> Media resource hxxp://video-http.media-imdb.com/... could not be decoded.
(It's just that they appear right after the "Sorry, an error has occurred" appears, 
not a few seconds earlier, i.e. when the big yellow circle in the video area still spins, so it missed my attention).
Got tons of errors like:

[17705] WARNING: Frame incorrectly marked as non-keyframe @ pts:81623000 dur:42000 dts:81623000: file /media/jwwang/DATA/codebase/mozilla-central/firefox/dom/media/fmp4/MP4Demuxer.cpp, line 467
[17705] WARNING: Frame incorrectly marked as non-keyframe @ pts:84960000 dur:42000 dts:84960000: file /media/jwwang/DATA/codebase/mozilla-central/firefox/dom/media/fmp4/MP4Demuxer.cpp, line 467
[17705] WARNING: Frame incorrectly marked as non-keyframe @ pts:88547000 dur:42000 dts:88547000: file /media/jwwang/DATA/codebase/mozilla-central/firefox/dom/media/fmp4/MP4Demuxer.cpp, line 467
[17705] WARNING: Frame incorrectly marked as non-keyframe @ pts:90174000 dur:41000 dts:90174000: file /media/jwwang/DATA/codebase/mozilla-central/firefox/dom/media/fmp4/MP4Demuxer.cpp, line 467

and then the seek promise is rejected with:

$2 = (const mozilla::SeekRejectValue &) @0x7f63d049e6b8: {
  mType = mozilla::MediaData::VIDEO_DATA,
  mError = {
    mCode = NS_ERROR_DOM_MEDIA_END_OF_STREAM,
    mMessage = {
      <nsACString> = {
        <mozilla::detail::nsCStringRepr> = {
          mData = 0x7f640fdb4a54 <gNullChar> "",
          mLength = 0,
          mFlags = 1
        },
        members of nsACString:
        static kMaxCapacity = 2147483637
      }, <No data fields>}
  }
}
Flags: needinfo?(jyavenard)
sounds similar to bug 1347538, but for MP4...

We attempt to seek, but there's no more keyframe after the seek point. So we reach EOS while seeking.
Assignee: nobody → jyavenard
Flags: needinfo?(jyavenard)
Would it be possible that we can add some test or enhance our current tests?
Priority: -- → P1
Once again, the issue is about the MDSM not handling EOS when seeking. I can make a workaround (again) in the MP4 demuxer instead, but it will be just that a workaround...

The MDSM should properly handle EOS when seeking and not treat it as error.
Comment on attachment 8861739 [details]
Bug 1359058 - handle EOS during seeking.

https://reviewboard.mozilla.org/r/133718/#review136696
Attachment #8861739 - Flags: review?(jyavenard) → review+
That will prevent the error for being shown.. However seeking will still not work.

I don't see how we could check the stream to properly identify the keyframe without scanning the entire content first.

We could remove the check in MP4TrackDemuxer::Seek the looks for a keyframe... But then we would likely get a decoding error later anyway...

Though, on those particular videos, it works just fine...
Somehow, seeking in http://www.imdb.com/video/imdb/vi4030179609?playlistId=tt2390361 works fine on Chrome. Chrome doesn't seem to scan the whole file to find a key frame since seek is very fast on Chrome.
yes.. somehow, even when those keyframe aren't ones... they decode well anyway...

need to check what's going on...
Those are very peculiar files...

For once, the muxing is correct, in that the keyframe flags are properly setup. So prior bug 1300296, seeking would have worked.

however, the H264 binary stream is wrong.
All frames' NAL have the type 1 (Coded slice of a non-IDR picture) and the nal_ref_idc of each NAL unit is set to 1. That's clearly wrong...

We would have to do a much deeper stream analysis to detect IDR frames (and I'm not sure it's even possible inner the NAL).

:cpeterson, do we know anyone inside IMDB to get them to correct their stream?
Blocks: 1300296
Flags: needinfo?(cpeterson)
Keywords: regression
Comment on attachment 8861969 [details]
Bug 1359058: P1. handle EOS during seeking.

https://reviewboard.mozilla.org/r/133968/#review136870
Attachment #8861969 - Flags: review?(jyavenard) → review+
Version: Trunk → 51 Branch
(In reply to Jean-Yves Avenard [:jya] from comment #14)
> :cpeterson, do we know anyone inside IMDB to get them to correct their
> stream?

Yes. I will send email to our Amazon contacts about this bug.
Flags: needinfo?(cpeterson)
platform-rel: --- → ?
Whiteboard: [platform-rel-Amazon][platform-rel-IMDb]
Is this a new regression for 53 or was it also broken in 52?
it was also broken in 52...

it is a regression though.
platform-rel: ? → +
Anthony? can you please review this patch?
Flags: needinfo?(ajones)
Attachment #8861970 - Flags: review?(ajones) → review?(gsquelart)
Comment on attachment 8861970 [details]
Bug 1359058: P2. Rely on container flags when seeking in plain MP4.

https://reviewboard.mozilla.org/r/133970/#review139350
Attachment #8861970 - Flags: review?(gsquelart) → review+
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a39a98ffb29b
P1. handle EOS during seeking. r=jya
https://hg.mozilla.org/integration/autoland/rev/fe9ac1176159
P2. Rely on container flags when seeking in plain MP4. r=gerald
Backed out for failing mochitest dom/canvas/test/webgl-conf/generated/test_conformance__textures__misc__texture-npot-video.html and T(g4) on Windows:

https://hg.mozilla.org/integration/autoland/rev/833e53da0e82242faa11ab1e672de2cd83fb1979
https://hg.mozilla.org/integration/autoland/rev/895836bd8d07e4086dcd02e5b392dfac8ad8d3e4

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=fe9ac117615975149ba6f33a6e68593e0396f863&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=96726620&repo=autoland

14:43:18     INFO - TEST-PASS | dom/canvas/test/webgl-conf/generated/test_conformance__textures__misc__texture-npot-video.html | A valid string reason is expected 
14:43:18     INFO - TEST-PASS | dom/canvas/test/webgl-conf/generated/test_conformance__textures__misc__texture-npot-video.html | Reason cannot be empty 
14:43:18     INFO - Buffered messages finished
14:43:18     INFO - TEST-UNEXPECTED-FAIL | dom/canvas/test/webgl-conf/generated/test_conformance__textures__misc__texture-npot-video.html | Test timed out. 
14:43:18     INFO -     reportError@SimpleTest/TestRunner.js:121:7
14:43:18     INFO -     TestRunner._checkForHangs@SimpleTest/TestRunner.js:142:7
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     TestRunner.runTests@SimpleTest/TestRunner.js:380:5
14:43:18     INFO -     RunSet.runtests@SimpleTest/setup.js:194:3
14:43:18     INFO -     RunSet.runall@SimpleTest/setup.js:173:5
14:43:18     INFO -     hookupTests@SimpleTest/setup.js:266:5
14:43:18     INFO - parseTestManifest@http://mochi.test:8888/manifestLibrary.js:36:5
14:43:18     INFO - getTestManifest/req.onload@http://mochi.test:8888/manifestLibrary.js:49:11
14:43:18     INFO - EventHandlerNonNull*getTestManifest@http://mochi.test:8888/manifestLibrary.js:45:3
14:43:18     INFO -     hookup@SimpleTest/setup.js:246:5
14:43:18     INFO - EventHandlerNonNull*@http://mochi.test:8888/tests?autorun=1&closeWhenDone=1&consoleLevel=INFO&hideResultsTable=1&manifestFile=tests.json&dumpOutputDirectory=c%3A%5Cusers%5Ccltbld%5Cappdata%5Clocal%5Ctemp&cleanupCrashes=true:11:1
Flags: needinfo?(jyavenard)
That makes no sense. 

WebGl is untouched, and it doesn't seek in MP4. 

I get heaps of webgl error on try even without those changes.
Flags: needinfo?(jyavenard)
Regression window provided in comment 21.
Flags: needinfo?(ajones)
Too late to fix for 53 but we could likely still take a patch for 54.
It looks like IMDB has fixed their videos.. frames are properly tagged now.
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0cf76b87767d
P1. handle EOS during seeking. r=jya
https://hg.mozilla.org/integration/autoland/rev/40d98a26598e
P2. Rely on container flags when seeking in plain MP4. r=gerald
Please request uplift on this, if you think it's appropriate, when you get a chance.
Flags: needinfo?(jyavenard)
Comment on attachment 8861969 [details]
Bug 1359058: P1. handle EOS during seeking.

Approval Request Comment
[Feature/Bug causing the regression]:1300296
[User impact if declined]: error when seeking in file
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: no
[Needs manual test from QE? If yes, steps to reproduce]: difficult to say, apparently, IMDB has fixed their encoding. 
[List of other uplifts needed for the feature/fix]: both P1 and P2 to uplift
[Is the change risky?]: no
[Why is the change risky/not risky?]: partial revert, we do not error anymore, instead we go back to simply reaching the end of the file.
[String changes made/needed]: none
Flags: needinfo?(jyavenard)
Attachment #8861969 - Flags: approval-mozilla-beta?
(In reply to Jean-Yves Avenard [:jya] from comment #35)
> Comment on attachment 8861969 [details]
> Bug 1359058: P1. handle EOS during seeking.
> 
> Approval Request Comment
> [Feature/Bug causing the regression]:1300296
> [User impact if declined]: error when seeking in file
> [Is this code covered by automated tests?]: yes
You mean we have a test case to seek to some point that there is no keyframe after it?
Comment on attachment 8861970 [details]
Bug 1359058: P2. Rely on container flags when seeking in plain MP4.

https://reviewboard.mozilla.org/r/133970/#review148716

::: dom/media/fmp4/MP4Demuxer.cpp:500
(Diff revision 2)
>      MOZ_ASSERT(mQueuedSample->mKeyframe,
>                 "mQueuedSample must be a keyframe");

@jya, 

We'll hit this assertion due to the change in this patch.


MP4TrackDemuxer::GetNextSample() might flip the `smaple->mKeyframe` so that the chcek won't pass.

We can either (1) remove this assertion or (2) remove the logics in MP4TrackDemuxer::GetNextSample() which recheck a sync frame is an IDR frame or not and flips the `sample->mKeyframe` variable.

The 2nd solution also resolves the issue of bug 1366999. WDYT?
Flags: needinfo?(jyavenard)
See Also: → 1366999
The file that caused this failure had no IDR NAL at all but the first sample.
Checking that a sample is an actual IDR is required due to all the bad data provided in MSE and all the side issues they cause. so (2) is unacceptable.

Please open a new bug for the assertion.
Flags: needinfo?(jyavenard)
Above I'm referring to the IMDB files which had all frames marked a P-Frame.
Depends on: 1369382
Hi Kostas, could you please verify that this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(rick3162)
Comment on attachment 8861969 [details]
Bug 1359058: P1. handle EOS during seeking.

This is a core scenario, Beta54+
Attachment #8861969 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8861970 - Flags: approval-mozilla-beta+
(In reply to Jean-Yves Avenard [:jya] from comment #35)
> [Is this code covered by automated tests?]: yes
> [Has the fix been verified in Nightly?]: no
> [Needs manual test from QE? If yes, steps to reproduce]: difficult to say,
> apparently, IMDB has fixed their encoding. 

Setting qe-verify- based on the nature of this bug and the fact that this fix has automated coverage.
Flags: qe-verify-
(In reply to Ritu Kothari (:ritu) from comment #40)
> Hi Kostas, could you please verify that this issue is fixed as expected on a
> latest Nightly build? Thanks!

Yes, of course: I confirm it's fixed in latest Nightly, 55.0a1 (2017-06-02) (64-bit).
Flags: needinfo?(rick3162)
Is this worth trying to rebase for ESR52?
Flags: needinfo?(jyavenard)
MozReview-Commit-ID: DPT3t1pi6o1
This reverts part of bug 1300296. In the worse case we'll get a decoding error. But we're only trading a bad behaviour for another.

MozReview-Commit-ID: H0gF3FqZsU6
MozReview-Commit-ID: DPT3t1pi6o1
This reverts part of bug 1300296. In the worse case we'll get a decoding error. But we're only trading a bad behaviour for another.

MozReview-Commit-ID: H0gF3FqZsU6
Attachment #8889568 - Attachment is obsolete: true
Flags: needinfo?(jyavenard)
Attachment #8889569 - Attachment is obsolete: true
Comment on attachment 8889570 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

:jw , the MDSM has changed significantly since 52, so I'm not 100% confident this rebase is all it needs.
Attachment #8889570 - Flags: review?(jwwang)
Let me download ESR52 to refresh the memories.
Comment on attachment 8889570 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

Review of attachment 8889570 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM.
Attachment #8889570 - Flags: review?(jwwang) → review+
Comment on attachment 8889570 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

Based on comment 35, the fact that it impacts a high-traffic site (IMDB), the small size of the patches, and considering we've already shipped this fix in Fx54 with no known regressions, I'm nominating this for ESR52 approval now too.
Attachment #8889570 - Flags: approval-mozilla-esr52?
Comment on attachment 8889570 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

This will impact a known site and has been baked. Let's uplift it to ESR52.3.
Attachment #8889570 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+
Depends on: 1416799
You need to log in before you can comment on or make changes to this bug.