1173792 - 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

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Kostas]

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.

Comment 1

[Kostas]

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.

Comment 2

[jen strickland :jenstrickland]

Tracking enabled for 40 and 41.

Comment 3

[Alice0775 White]

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8b550071a56c&tochange=5a745cf431cb

Comment 4

[Jean-Yves Avenard [:jya]]

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

Comment 5

[Jean-Yves Avenard [:jya]]

(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.

Comment 6

[Jean-Yves Avenard [:jya]]

Are you sure about this regression window?

Comment 7

[Jean-Yves Avenard [:jya]]

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

Comment 8

[Alice0775 White]

Sure, I tried again just now. And I got a same range.

Comment 9

[Jean-Yves Avenard [:jya]]

Yes... it's this change: https://hg.mozilla.org/integration/mozilla-inbound/rev/59213406ccda

Comment 10

[Jean-Yves Avenard [:jya]]

Attachment: P1. Seek to original seeking position should video seeked time not found.

Comment 11

[Jean-Yves Avenard [:jya]]

Attachment: 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.

Comment 12

[Jean-Yves Avenard [:jya]]

[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.

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/24a1a6c8cb85
https://hg.mozilla.org/integration/mozilla-inbound/rev/c99d0c402d00

Comment 14

[Jean-Yves Avenard [:jya]]

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

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4aa1e726ea00

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/5fecfbec2e3c

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/24a1a6c8cb85
https://hg.mozilla.org/mozilla-central/rev/c99d0c402d00

Comment 19

[Ada [:adalucinet]]

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.