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

VERIFIED FIXED in Firefox 39

Status

()

VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: rick3162, Assigned: jya)

Tracking

(Blocks: 1 bug, {regression})

38 Branch
mozilla41
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox38 wontfix, firefox39+ verified, firefox38.0.5 wontfix, firefox40+ verified, firefox41+ verified, firefox-esr31 unaffected, firefox-esr38 affected)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
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 17.0.0.188:
- 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.
(Reporter)

Updated

4 years ago
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
(Reporter)

Comment 1

4 years ago
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.

Updated

4 years ago
Component: Untriaged → Video/Audio
Product: Firefox → Core

Updated

4 years ago
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: ? → +

Updated

4 years ago
Blocks: 1134064
(Assignee)

Updated

4 years ago
Assignee: nobody → jyavenard
Flags: needinfo?(jyavenard)
(Assignee)

Comment 4

4 years ago
Interestingly, I'm seeing the exact same behaviour with the new MSE, even it doesn't share a single line of code...
(Assignee)

Comment 5

4 years ago
(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.
(Assignee)

Comment 6

4 years ago
Are you sure about this regression window?
Flags: needinfo?(alice0775)
(Assignee)

Comment 7

4 years ago
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
(Assignee)

Updated

4 years ago
Flags: needinfo?(alice0775)

Comment 8

4 years ago
Sure, I tried again just now. And I got a same range.
(Assignee)

Comment 11

4 years ago
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)
(Assignee)

Updated

4 years ago
See Also: → bug 1105066
(Assignee)

Comment 12

4 years ago
[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+
(Assignee)

Comment 14

4 years ago
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
Attachment #8623639 - Flags: approval-mozilla-beta?
Attachment #8623639 - Flags: approval-mozilla-aurora?
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.
Attachment #8623639 - Flags: approval-mozilla-beta?
Attachment #8623639 - Flags: approval-mozilla-beta+
Attachment #8623639 - Flags: approval-mozilla-aurora?
Attachment #8623639 - Flags: approval-mozilla-aurora+
tracking-firefox39: ? → +
Flags: qe-verify+
https://hg.mozilla.org/mozilla-central/rev/24a1a6c8cb85
https://hg.mozilla.org/mozilla-central/rev/c99d0c402d00
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
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.