3.00 KB, patch
|Details | Diff | Splinter Review|
1010 bytes, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150605094246 Steps to reproduce: In a clean Firefox 38.0.5 profile (win8.1 x64) with Flash version 188.8.131.52: - click this URL: https://www.youtube.com/watch?t=61&v=ktbGjjzSKao - wait 5 sec, then click "Skip Ad". Actual results: The video doesn't play: the rotating icon in the center of the video just keeps spinning endlessly. Pressing F5 or Ctrl+F5 doesn't help. The only way to make the video play is by moving the seekbar. The same happened in FF Beta 39 x64, 40dev x64 and Nightly 41 x64. On the other hand, in IE and Chrome the problem never occurs. Expected results: Thee video should play, as expected.
Summary: If you try to open this specific Youtube URL(which includes timecode), the video doesn't play, and pressing F5 or Ctrl+F5 doesn't help (you have to move the position handle in order the video to start playing ) → If you try to open this specific Youtube URL(which contains timestamp) the video doesn't play. Pressing F5 or Ctrl+F5 doesn't help. You have to move the seekbar for the video to start playing
Other use cases: https://www.youtube.com/watch?t=61&v=5m5harNeUd8 https://www.youtube.com/watch?t=61&v=IaH2C2Qe97Y On the other hand, other videos play ok. Examples: https://www.youtube.com/watch?t=61&v=MsBBUvdIxgY https://www.youtube.com/watch?t=61&v=L0pjVcIsU6A And, by mistake I mentioned the installed Flash version in my OP. That info is irrelevant(YouTube only uses the HTML5 player). Sorry.
Status: UNCONFIRMED → NEW
status-firefox38: --- → affected
status-firefox38.0.5: --- → affected
status-firefox39: --- → affected
status-firefox40: --- → affected
status-firefox41: --- → affected
status-firefox-esr31: --- → unaffected
status-firefox-esr38: --- → affected
tracking-firefox40: --- → ?
tracking-firefox41: --- → ?
Ever confirmed: true
Tracking enabled for 40 and 41.
tracking-firefox40: ? → +
tracking-firefox41: ? → +
Assignee: nobody → jyavenard
Interestingly, I'm seeing the exact same behaviour with the new MSE, even it doesn't share a single line of code...
(In reply to Alice0775 White from comment #3) > Pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=8b550071a56c&tochange=5a745cf431cb I can't see how any of those changes could have any impact on the problem at hand. The code path of those is only entered once we start evicting data. At no time are we hitting this here.
Are you sure about this regression window?
Not sure how we could handle the situation: We have video buffered range 58.725333 to 65.331933 And audio buffered range 60.000362 to 64.040634. The player attempts to seek to 61s, the keyframe is at 58.725333s. After seeking to video, we seek to 58s in the audio stream in order to get good A/V sync, but we don't have audio at 58.72s so we enter waiting_mode: playback will never start as no audio never comes. We need to handle seeking in mediasource / mp4 differently and have the MDSM handle dropping video frames so we can keep good a/v sync
Sure, I tried again just now. And I got a same range.
Yes... it's this change: https://hg.mozilla.org/integration/mozilla-inbound/rev/59213406ccda
Created attachment 8623639 [details] [diff] [review] P1. Seek to original seeking position should video seeked time not found.
Attachment #8623639 - Flags: review?(matt.woodrow)
Created attachment 8624158 [details] [diff] [review] P2. Always seek audio to original seeking position. There's no guarantee that the audio stream will have the same buffered ranges as the video track; which could lead to a stall. It is up to the MediaDecoderStateMachine to ensure proper A/V sync following a sync. I have seen the A/V sync issue first talked in bug 1105066. However I believe those changes simply hid the actual problem in the MDSM. So I will start working on fixing that. I have some ideas there.
Attachment #8624158 - Flags: review?(matt.woodrow)
[Tracking Requested - why for this release]: This is a YouTube regression over 38. It can cause playback to stall. This is serious enough that the fix should be uplifted to 39 ASAP.
tracking-firefox39: --- → ?
Attachment #8623639 - Flags: review?(matt.woodrow) → review+
Attachment #8624158 - Flags: review?(matt.woodrow) → review+
Comment on attachment 8623639 [details] [diff] [review] P1. Seek to original seeking position should video seeked time not found. Request is for bug #1 only. Approval Request Comment [Feature/regressing bug #]:1134064 [User impact if declined]: YouTube playback regression [Describe test coverage new/current, TreeHerder]: Try test, checking all YouTube MSE conformance tests, Manual testing, breathing MSE for the past 11 months. [Risks and why]: Low, this is restoring the earlier code behaviour [String/UUID change made/needed]:None
status-firefox38: affected → wontfix
status-firefox38.0.5: affected → wontfix
Comment on attachment 8623639 [details] [diff] [review] P1. Seek to original seeking position should video seeked time not found. Approved for uplift to beta and aurora. This is a bad regression we don't want to ship in 39.
tracking-firefox39: ? → +
status-firefox40: affected → fixed
status-firefox39: affected → fixed
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox41: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Reproduced with 38.0.5 under Windows 7 64-bit using the provided samples. Verified fixed with 39.0 RC build 3 (Build ID: 20150622181234), latest 40.0a2 and 41.0a1 (both from 2015-06-22), under Windows 7 64-bit and windows 8.1 64-bit.
Status: RESOLVED → VERIFIED
status-firefox39: fixed → verified
status-firefox40: fixed → verified
status-firefox41: fixed → verified
You need to log in before you can comment on or make changes to this bug.