MediaSource failures with certain language settings #1696
Comments
|
Additional clues:
|
|
Now I'm getting failures on the WebM-only version, too. Is this a race condition somewhere? Using ";play" in the URL fragment and reloading the page, I got 19 failures out of 20 test runs. |
|
The first commit in which this bug appears in 6b1ca2d, but it is still unclear how that could have caused this. |
|
More specifically, this happens for me in Chrome/70.0.3538.110 on Linux, and with any of the Sintel assets on the first try, but not on the second try, and not with Angel One. This is not happening for @TheModMaker on the same version of Chrome. |
|
The log from |
|
@wolenetz, any ideas on how we should debug this perplexing Chrome media error that only happens on this one machine, but not on an identical version of Chrome on the same OS on a teammate's machine? |
|
@joeyparrish I have the same error:
My useragent is "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36" (Ubuntu 18.04) |
joeyparrish
changed the title
|
This is still happening for me. This will block v2.5 if we can't solve it. |
joeyparrish
added
the
flag: Why didn't we catch this sooner
|
I think I found the root cause, and I can explain why it doesn't happen for my teammates. @avelad, I notice that your language is set to |
|
I'll try building a debug chrome and get more detailed logs from a repro (assuming I can get a repro first...) |
|
No repro on Chrome Linux 70.3538.110, though language is 'en'. |
|
The limited amount if info in chrome://media-internals for a repro suggests to me that this error occurs before reaching HAVE_METADATA. I'll dig into local repro logs next. |
|
I couldn't get a local tip-of-tree Chrome release build to repro this. I noticed also that even if I picked a specific "Text language" different from that in the URL and then click Load a second time that the chosen text language is not used. Is that a known issue, perhaps related? |
|
Ah I have a successful local repro now from tip-of-tree. Analyzing logs... |
|
Relevant portion of a repro log: |
|
Requirements for repro:
These conditions will cause StreamingEngine's setup phase to be completed after only text is initialized, which then causes a MediaSource failure for audio or video when streaming begins. Effectively, this is a race between two different triggers to StreamingEngine initialization. |
|
@wolenetz, thank you for the assistance! We have found the root cause now within Shaka Player. |
joeyparrish
changed the title
|
To answer the "Why didn't we catch this sooner?" label:
Lessons learned: When your colleague with an identical OS & browser can't repro, check your preferences! |
|
@joeyparrish Glad I could help - sorry about the delay. Of note, the path to error I found in my repro looks like mediaSource.endOfStream() was called before HAVE_METADATA readyState on the attached HTMLMediaElement was reached. I'll look into adding an informative error log message of some kind for that condition in Chrome in addition to the existing basic "DEMUXER_ERROR_COULD_NOT_OPEN" pipeline error message for this case. |
|
This is the related MSE spec issue that was hit by the repro: w3c/media-source#212 |
…ages If WebSourceBufferImpl::endOfStream() occurs prior to reaching HAVE_METADATA (whether explicitly by application or as consequence of other error condition spec's error), previously a generic "DEMUXER_ERROR_COULD_NOT_OPEN" pipeline status error message might be the only error message in chrome://media-internals for the player. This change adds an extra error message to media-internals to assist application debugging. This change also adds more debug logging to Blink's MediaSource and SourceBuffer implementations. See also the known MSE spec issue around treatment of endOfStream() when not yet having reached HAVE_METADATA: w3c/media-source#212 TEST=Manual verification of the new MEDIA_LOG mentioned in the first paragraph of this description (via repro of shaka-project/shaka-player#1696), updated ChunkDemuxerTests Change-Id: I2044fc2484160a02506210eedeee7bf794da1da0 Reviewed-on: https://chromium-review.googlesource.com/c/1361936 Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org> Reviewed-by: Dan Sanders <sandersd@chromium.org> Cr-Commit-Position: refs/heads/master@{#614046}
Vaguely relates to the investigation into issue #1696 Change-Id: I5d16f5cbdabf72361598e28bff196a5be7030967
This is fairly tricky to reproduce. First, we must trigger the auto-display of subtitles. We didn't have any tests that covered this before, so we needed this anyway. This is triggered by careful choice of content language and language preferences, which required us to add language information to our simulated test content. I also added tests for the cases where we should *not* trigger auto-display of subtitles. Second, the setup phase for text must complete more quickly than the setup for audio & video. In real life, this happens when text is non-segmented VTT and audio & video use DASH's SegmentBase. In the test, this is accomplished by delaying createSegmentIndex() of audio and video in our simulated content. This will cause auto-display of subtitles to trigger a setup race in StreamingEngine. When text wins the race, MediaSource errors follow for audio and video. Issue #1696 Change-Id: I1c22089925486da642368bec269a55d8556900d1
Have you read the FAQ and checked for duplicate open issues?:
Yes
What version of Shaka Player are you using?:
master / nightly
Can you reproduce the issue with our latest release version?:
No
Can you reproduce the issue with the latest code from
master?:Yes
Are you using the demo app or your own custom app?:
Demo
What browser and OS are you using?:
Chrome on Linux
What are the manifest and license server URIs?:
"Sintel 4k multicodec" from the asset list
What did you do?
Click load.
What did you expect to happen?
The content will load.
What actually happened?
A MediaSource error occurred: "Shaka Error MEDIA.VIDEO_ERROR (4,,DEMUXER_ERROR_COULD_NOT_OPEN)"
If you click load a second time, the content loads correctly.
https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=https://storage.googleapis.com/shaka-demo-assets/sintel/dash.mpd
The text was updated successfully, but these errors were encountered: