The default bug view has changed. See this FAQ.

YouTube video playback start is very slow compared to Chrome with ipv6

RESOLVED FIXED

Status

()

Core
Audio/Video
P1
normal
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: sotaro, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
x86_64
Windows 8.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox36 unaffected, firefox37 affected, firefox38 affected, firefox39 affected, firefox-esr31 unaffected)

Details

Attachments

(4 attachments)

(Reporter)

Description

2 years ago
When MSE is enabled for youtube video playback. It takes a long time(more than one minute) until youtube video playback start. Toronto office's WLAN connection is not good. Therefore I always face this problem. I strongly feel it during debugging bug 1128357.

STR
[1] Start Firefox nightly
[2] Start youtube video playback like the following.
     https://www.youtube.com/watch?v=09R8_2nJtjg


On the same machine and same network, Chrome browser's youtube video playback start quickly.

- Firefox nightly browser's youtube playback Mime Type: video/mp4; codecs="avc1.4d401e"

- chrome browser's youtube playback Mime Type: video/webm; codecs="vp9"
(Reporter)

Comment 1

2 years ago
Anthony, is there a similar bug already?
Flags: needinfo?(ajones)
Chrome reads different files - webm/vp9. Can you compare with IE?
Flags: needinfo?(ajones)
Blocks: 778617
(Reporter)

Comment 3

2 years ago
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #2)
> Chrome reads different files - webm/vp9. Can you compare with IE?

IE takes longer time(around 10 sec) until starting youtube videos than chrome(around 3sec). But it is shorter than Firefox youtube with MES.

IE used same mime.as firefox.
type video/mp4; codecs="avc1.4d401e"
(Reporter)

Comment 4

2 years ago
In Firefox, there were a case that it took very very long time and short time until start playback.
(Reporter)

Comment 5

2 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #4)
> In Firefox, there were a case that it took very very long time and short
> time until start playback.

Once, the playback start became quick, other video's playbacks also seemed to become quick until the firefox shutdown.
Possibly related to bug 1137511.

Updated

2 years ago
Priority: -- → P2
How does it compare to Flash?
(Reporter)

Comment 8

2 years ago
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #7)
> How does it compare to Flash?

On Flash, the PC failed to start video playback in majority cases. Just show "An error occurred, please try again later".

Comment 9

2 years ago
Sanity-check: how does it behave when FF uses the Chrome UA string? It would be good to know if we're getting the same code/files as Chrome. It would also be good to know if Chrome is pre-fetching* here (test using a sniffing proxy like Charles.)

* https://developers.google.com/chrome/whitepapers/prerender?csw=1
(Reporter)

Comment 10

2 years ago
It seems like dup of Bug 1131426.
(Reporter)

Comment 11

2 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> It seems like dup of Bug 1131426.

Network condition might just increase the delay.
(Reporter)

Comment 12

2 years ago
Anthony, do we set this bug as invalid because of comment 10?
Flags: needinfo?(ajones)
(Reporter)

Comment 13

2 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> It seems like dup of Bug 1131426.

I confirmed CORS error in console log.
I'm following up with YouTube. We'll leave it open for now just to track it.
Flags: needinfo?(ajones)
Blocks: 1083588

Comment 15

2 years ago
Sotaro: if you have a reliable repro case for this, please try setting security.turn_off_all_security_so_that_viruses_can_take_over_this_computer == true to see if CORS issues are actually to blame here. 

Of course, do not leave that flag set outside of this test :)
Flags: needinfo?(sotaro.ikeda.g)
(Reporter)

Comment 16

2 years ago
(In reply to Jet Villegas (:jet) from comment #15)
> Sotaro: if you have a reliable repro case for this, please try setting
> security.turn_off_all_security_so_that_viruses_can_take_over_this_computer
> == true to see if CORS issues are actually to blame here. 

I tried the pref, but it seems not work to disable CORS. The CORS error messages were still exist. From Bug 1039678, we might not have a way to disable CORS by pref/setting.
Flags: needinfo?(sotaro.ikeda.g)
(Reporter)

Comment 17

2 years ago
Created attachment 8574007 [details]
ie's netowork log when starting youtube video playback with MES

When youtube video playback is started with IE, I always saw that fist XHR for audio data and first XHR for video data were failed, another XHRs seemed to receive actual data.
(Reporter)

Comment 18

2 years ago
I am not sure how to disable CORS locally. From the source, modifying nsCORSListenerProxy::CheckRequestApproved() seems do it. By modifying CheckRequestApproved(), I did not see the CORS error logs.

https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCORSListenerProxy.cpp#528
(Reporter)

Comment 19

2 years ago
When I tried to playback same video several times, youtube video playback seems to becomes very quick. In this case, I did not see the CORS error nor XHR without data receive.
(Reporter)

Comment 20

2 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #17)
> Created attachment 8574007 [details]
> ie's netowork log when starting youtube video playback with MES
> 
> When youtube video playback is started with IE, I always saw that fist XHR
> for audio data and first XHR for video data were failed, another XHRs seemed
> to receive actual data.

On Firefox, first 7 XHRs for audio and 7 XHRs for video seems aborted when the problem happens.
(Reporter)

Comment 21

2 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #20)
> (In reply to Sotaro Ikeda [:sotaro] from comment #17)
> > Created attachment 8574007 [details]
> > ie's netowork log when starting youtube video playback with MES
> > 
> > When youtube video playback is started with IE, I always saw that fist XHR
> > for audio data and first XHR for video data were failed, another XHRs seemed
> > to receive actual data.
> 
> On Firefox, first 7 XHRs for audio and 7 XHRs for video seems aborted when
> the problem happens.

The number of XHR abort seems different each time on firefox. first 3 XHRs for audio and 3 XHRs abort seems also common.
(Reporter)

Comment 22

2 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #18)
> I am not sure how to disable CORS locally. From the source, modifying
> nsCORSListenerProxy::CheckRequestApproved() seems do it. By modifying
> CheckRequestApproved(), I did not see the CORS error logs.
> 
> https://dxr.mozilla.org/mozilla-central/source/dom/security/
> nsCORSListenerProxy.cpp#528

I am not sure the above check actually disable CORS, because even after changing the CheckRequestApproved(), the XHRs aborts happened same way.
(In reply to Sotaro Ikeda [:sotaro] from comment #22)
> I am not sure the above check actually disable CORS, because even after
> changing the CheckRequestApproved(), the XHRs aborts happened same way.

I'm told that the issue is that the CORS headers are only missing from other errors and not from real content. That doesn't seem to be the case for me. However I'm getting CORS errors a few times an hour. I only get this from the office Internet which has a funny idea of what country it is in and that is apparently part of the issue. How big a part, I don't know.

Do you experience this issue only at the office or can you reproduce the problem from your home?
Duplicate of this bug: 1131426
Can you get some logs through wireshark for the different browsers?
(Reporter)

Comment 26

2 years ago
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #23)
> 
> Do you experience this issue only at the office or can you reproduce the
> problem from your home?

No, I experience it only from Toronto office.
(Reporter)

Comment 27

2 years ago
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #25)
> Can you get some logs through wireshark for the different browsers?

I will try it tomorrow.
Flags: needinfo?(sotaro.ikeda.g)
I had a look at this and it looks like it is caused by ipv6.

The following command hangs:

curl -6 'https://r1---sn-gxuxapu-hm2e.googlevideo.com/videoplayback?key=yt5&ip=2001%3A450%3A1f%3A224%3Aad0e%3Af3f2%3A1b90%3A1d3&mm=31&signature=B309F1278B3E598B2F34D2FB4745107DAB7292EE.8917C6D467EFFC7C4D90EEA2D7ECA3350F444FD0&mv=u&mt=1426001559&ms=au&id=o-AMK3FzCiH_aN6N2sMtJxPqys2HJ8i8P1pTGHOQXFfSQI&lmt=1417129991745982&source=youtube&sver=3&dur=124.853&itag=140&sparams=clen%2Cdur%2Cgir%2Cid%2Cip%2Cipbits%2Citag%2Clmt%2Cmm%2Cms%2Cmv%2Cpl%2Crequiressl%2Csource%2Cupn%2Cexpire&requiressl=yes&clen=1505649&ipbits=0&expire=1426023298&fexp=900225%2C904844%2C907263%2C913444%2C924630%2C927622%2C934952%2C934953%2C934954%2C936120%2C9405634%2C9406012%2C9406282%2C943917%2C948124%2C951703%2C952302%2C952612%2C952901%2C955301%2C957201%2C959701&gir=yes&upn=rTwIU7yHZXQ&pl=48&cpn=lEFD4CDK6iZ31ulW&alr=yes&keepalive=yes&ratebypass=yes&mime=audio%2Fmp4&c=web&cver=html5&range=0-65535' -H 'Host: r1---sn-gxuxapu-hm2e.googlevideo.com' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:39.0) Gecko/20100101 Firefox/39.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Referer: https://www.youtube.com/embed/ZuTQR6xSbNM?autoplay=1&wmode=transparent&origin=https://video.search.yahoo.com&html5=1' -H 'Origin: https://www.youtube.com' -H 'Connection: keep-alive'

If you take away the -6 it works fine.

We seem to eventually timeout and switch to ipv4. We should tell google to fix this.
Summary: Youtube video playback start is very slow compared to chrome browser when network connection is not good → Youtube video playback start is very slow compared to chrome browser with ipv6
Sotaro, are you using IPv6?
(Reporter)

Comment 30

2 years ago
(In reply to Chris Peterson [:cpeterson] from comment #29)
> Sotaro, are you using IPv6?

Yes, I confirmed IPv6 usage for youtube site by using Wireshark.
Flags: needinfo?(sotaro.ikeda.g)
I am reaching out to our YouTube contacts now.
Summary: Youtube video playback start is very slow compared to chrome browser with ipv6 → YouTube video playback start is very slow compared to Chrome with ipv6
(Reporter)

Comment 32

2 years ago
Created attachment 8575423 [details]
Wireshark log - youtube video playback via ie
(Reporter)

Comment 33

2 years ago
Created attachment 8575425 [details]
Wireshark log - youtube video playback via firefox

Comment 34

2 years ago
Would it be possible to get a tcpdump from someone who can reproduce this problem?

Updated

2 years ago
Priority: P2 → P1
Created attachment 8576263 [details]
out.cap

I sent this to Richard by email. But here it is for anyone else who's interested. The server does not respond to any of our syn packets.

Comment 36

2 years ago
Thanks so much for the examples.  Jeff, could I ask you for an additional bit of info? Could you right click on the player, select Copy Debug Info and paste the result here for a Firefox IPv6 playback that demonstrates this issue?  

The tcpdump shows some potentially interesting behavior but doesn't show what the application level player code is doing.  The Debug Info can sometimes makes that easier to infer.

Comment 37

2 years ago
I'm also having this problem, or one that seems to be the same. I created an account here just to help out. I'm not sure when it started, but it's recent, in the past few days. When I try to load any youtube video, I'm greeted with the buffer wheel for anywhere from 10-30 seconds. Then, either I'm met with the youtube error message or the video loads but on a low resolution, and the higher resolutions are greyed out and unable to select. Usually in this case I refresh the page once or twice, and then the video finally loads. In comparison, Chrome loads all these videos immediately with no wait.

Things I've tried:

Uninstall and reinstall firefox flash player
Disable/Delete all extensions
Uninstall Firefox, reinstall current version (36.0.1)
Complete clean uninstall (even removing the mozilla folder from appdata/roaming)

Nothing seems to work. Let me know if I can be of any help and send you any info.
Can make  http log:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Tracking 37+ as this is important for MSE.
status-firefox36: --- → unaffected
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox39: --- → affected
status-firefox-esr31: --- → unaffected
tracking-firefox37: --- → +
tracking-firefox38: --- → +
tracking-firefox39: --- → +
Sotaro: can you follow comment 38 and get an HTTP log for this while it's happening?  

[Note that HTTP logs can possibly contain cookies, so if this is a real profile you use regularly, either look over the log to make sure there's no confidential info in it before you attach it here Or you can just email it directly to Dragana.]
Flags: needinfo?(sotaro.ikeda.g)
Here's the debug info from a session. It didn't seem to hang as long though and didn't seem to have the same ipv6 problem.

{"ns":"yt","el":"embedded","cpn":"8Wno7-FzUv16p46o","docid":"ZuTQR6xSbNM","ver":2,"referrer":null,"cmt":"6.42","plid":"AAURHt-cqHnD1Jyh","ei":"jRICVfS6LYbMqAOo1oKwBQ","fmt":"133","fs":"0","rt":"9.849","of":"T_k3IsmKkcxGOR81mofITw","adformat":null,"content_v":null,"euri":"","subscribed":null,"lact":1,"live":null,"cl":"88303760","mos":0,"osid":null,"state":null,"vm":null,"volume":59,"c":"web","cver":"html5","cplayer":"UNIPLAYER","cbr":"Firefox","cbrver":"39.0","cos":"Macintosh","cosver":"10.9","autoplay":"1","hl":"en_US","cr":"CA","len":"124","fexp":"900225,904844,907263,913444,924630,927622,934952,934953,934954,936120,9405634,9406012,9406938,9407103,9407793,943917,947243,948124,951511,951703,952302,952612,952901,955301,957201,959701","afmt":"140","vct":"6.420","vd":"124.000","vpl":"0.000-6.420,","vbu":"0.000-59.999,","vpa":false,"vsk":false,"vpr":1,"vrs":3,"vns":2,"vec":null,"lct":"6.177","lsk":false,"lmf":false,"lbw":"472686.320","lhd":"0.250","ltd":"16.234","laa":"itag=140,seg=5,range=603666-724055,time=50.0,60.0","lva":"itag=133,seg=13,range=1990181-2144478,time=65.0,70.0","lar":"itag=140,seg=5,range=603666-724055,time=50.0,60.0","lvr":"itag=133,seg=13,range=1990181-2144478,time=65.0,70.0","lvh":"r13---sn-p5qlsnlr","lab":"0.000-59.999,","lvb":"0.000-70.000,","debug_videoId":"ZuTQR6xSbNM","debug_playbackQuality":"small","debug_date":"Thu Mar 12 2015 18:26:32 GMT-0400 (EDT)"}
I'm not getting the same CORS issue anymore right now either.
I can however still reproduce the hangs when trying to connect to the original r1---sn-gxuxapu-hm2e.googlevideo.com host
Jeff, can you also send a http log when it hangs?
Flags: needinfo?(jmuizelaar)
(Reporter)

Comment 45

2 years ago
(In reply to Jason Duell [:jduell] (needinfo? me) from comment #40)
> Sotaro: can you follow comment 38 and get an HTTP log for this while it's
> happening?  
> 
> [Note that HTTP logs can possibly contain cookies, so if this is a real
> profile you use regularly, either look over the log to make sure there's no
> confidential info in it before you attach it here Or you can just email it
> directly to Dragana.]

Today, I tried several times, but the hang did not happen.
Flags: needinfo?(sotaro.ikeda.g) → needinfo?(sotaro.ikeda.g)
(Reporter)

Comment 46

2 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #45)
> (In reply to Jason Duell [:jduell] (needinfo? me) from comment #40)
> > Sotaro: can you follow comment 38 and get an HTTP log for this while it's
> > happening?  
> > 
> > [Note that HTTP logs can possibly contain cookies, so if this is a real
> > profile you use regularly, either look over the log to make sure there's no
> > confidential info in it before you attach it here Or you can just email it
> > directly to Dragana.]
> 
> Today, I tried several times, but the hang did not happen.

It means youtube playback did not hang today.
Flags: needinfo?(sotaro.ikeda.g)

Comment 47

2 years ago
I made and HTTP log while youtube was lagging to help you out, but I cannot post it, because it is too long. I also cannot attach it because the file is too big. How do I post the log file? Can I email it to someone?
Justin, you can e-mail it to me.

Comment 49

2 years ago
What's your email? Is it the dd.mozilla@gmail?
Yes, thank you.

Comment 51

2 years ago
Okay, sending it now. I hope this will help you guys figure it out. I use youtube every day and having each video take several tries to load is very annoying. Let me know if I can help in any other way.
Assignee: nobody → dd.mozilla
Flags: needinfo?(jmuizelaar)
The problem is that happy-eyeballs is not working properly....

I made a patcha nd than figure out that there is another bug already salving this.

so it is dup of 1136484
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1136484
Untracking this since it's a duplicate; tracking 1136484 instead.
tracking-firefox37: + → ---
tracking-firefox38: + → ---
tracking-firefox39: + → ---

Nick (https://bugzilla.mozilla.org/show_bug.cgi?id=1136484#c28) is right there are two problems here 

The tcpdump from Jeff is a happy eyeballs problem and http log is a happy-eyeball problem as well.

but the tcpdump from Sotaro is different:
we start connection to r1.sn-nx57ynes.googlevideo.com (2607:f8b0:400a:a::6) (send tls handshake)
and than we abort connection, sending Encrypted Alert and a FIN.

so one part is duplicate of 1136484 and the other not.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee: dd.mozilla → nobody
How serious do you think the remaining issue is? Should this still be a top-priority bug?
Flags: needinfo?(dd.mozilla)
Justin's http log (comment #51) and Jeff's
Flags: needinfo?(dd.mozilla)
Sorry accidentally posted the comment....

Sotaro could not reproduce the problem - comment #45, it seems that youtube fixed it.
The same problem is reported in bug 1131426.

But I will ask Patrick.. I am not sure who is the right person to ask. (note: some comment on the tcpdump is in comment #55)
Flags: needinfo?(mcmanus)
So, as I understand this there were 2 sources of problems:

1] is bug 1131426, which is recently fixed on 38 and 39 and wontfix 37

2] is a yt side CORS problem that seems to have been fixed around 3/12

looking at the logs that seems right.

one question I had about 1131426 was why it was linked to eme and that was never justified in the bug - that was part of why we wontfix'd it for 37 given the short timeline. however, I think I understand now - without eme the video is retrieved via flash using a separate stack that does not run into 1131426. Is it correct that eme is a 37 feature?

I can't assess how painful this is now that the cors issue is resolved. If someone can still repro on 37 and wants to try and quantify how big of an issue it is then that show be good feedback to lawrence on revisiting his decision to wontfix it on 37.

The yt test itself from tor is probably the best directed testing that could be done (on 38/39)
Flags: needinfo?(mcmanus)
(In reply to Patrick McManus [:mcmanus] from comment #59)
> one question I had about 1131426 was why it was linked to eme and that was
> never justified in the bug - that was part of why we wontfix'd it for 37
> given the short timeline. however, I think I understand now - without eme
> the video is retrieved via flash using a separate stack that does not run
> into 1131426. Is it correct that eme is a 37 feature?

Small correction: bug 1131426 was using MSE, not EME (DRM). We have asked YouTube to only serve HTML5 video to Firefox versions that support MSE.
(In reply to Patrick McManus [:mcmanus] from comment #59)
> 2] is a yt side CORS problem that seems to have been fixed around 3/12

This is us generating a CORS error when YouTube calls abort() on a hung request.
See Also: → bug 1150622
Dragana - is there an easy way to pref-off ipv6 to test/prove a user has an ipv6 problem?
Flags: needinfo?(dd.mozilla)
there is a pref network.dns.disableIPv6 in about:config you can set it to true.
Flags: needinfo?(dd.mozilla)
According o comment #59 both problems are fixed, so closing this bug.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
See Also: → bug 1154753
Duplicate of this bug: 1140085

Comment 66

a year ago
Just got this CORS issue with a YouTube video loading a https://r1---sn-cg07luez.googlevideo.com/videoplayback?... video.
Aissen, that's very interesting. Are you using IPv6? Have you seen this CORS issue more than once? If you have can, you please share the YouTube page URL and your Firefox's about:support information?

Instructions:

https://support.mozilla.org/en-US/kb/use-troubleshooting-information-page-fix-firefox

Comment 68

a year ago
YouTube URL: https://www.youtube.com/watch?v=sHHoQX87xsg
AFAIK, I have no IPv6 enabled (can't ping6 gogole, have only an fe80:: link local adress on the interface)

I disabled my ad blocker, but the issue is still here.

I can't reproduce it after upgrading from firefox 41.0.2 to firefox 42.
If the video still played after you saw the CORS message, I think you might have seen bug 1152574, which was fixed in Firefox 42. The CORS message was incorrectly shown when a website was aborting XHR requests (such as when you skip ahead in a YouTube video).

Comment 70

a year ago
The video did not play at all, but as I said it now works in Firefox 42; you can ignore this report.
You need to log in before you can comment on or make changes to this bug.