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

Status: RESOLVED FIXED

(Core :: Audio/Video, defect, P1)

Description

[Sotaro Ikeda [:sotaro]]

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"

Comment 1

[Sotaro Ikeda [:sotaro]]

Anthony, is there a similar bug already?

Comment 2

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Chrome reads different files - webm/vp9. Can you compare with IE?

Comment 3

[Sotaro Ikeda [:sotaro]]

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

Comment 4

[Sotaro Ikeda [:sotaro]]

In Firefox, there were a case that it took very very long time and short time until start playback.

Comment 5

[Sotaro Ikeda [:sotaro]]

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

Comment 6

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Possibly related to bug 1137511.

Comment 7

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

How does it compare to Flash?

Comment 8

[Sotaro Ikeda [:sotaro]]

(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

[Jet Villegas (inactive)]

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

Comment 10

[Sotaro Ikeda [:sotaro]]

It seems like dup of Bug 1131426.

Comment 11

[Sotaro Ikeda [:sotaro]]

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

Network condition might just increase the delay.

Comment 12

[Sotaro Ikeda [:sotaro]]

Anthony, do we set this bug as invalid because of comment 10?

Comment 13

[Sotaro Ikeda [:sotaro]]

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

I confirmed CORS error in console log.

Comment 14

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

I'm following up with YouTube. We'll leave it open for now just to track it.

Comment 15

[Jet Villegas (inactive)]

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 :)

Comment 16

[Sotaro Ikeda [:sotaro]]

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

Comment 17

[Sotaro Ikeda [:sotaro]]

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

Comment 18

[Sotaro Ikeda [:sotaro]]

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

Comment 19

[Sotaro Ikeda [:sotaro]]

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.

Comment 20

[Sotaro Ikeda [:sotaro]]

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

Comment 21

[Sotaro Ikeda [:sotaro]]

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

Comment 22

[Sotaro Ikeda [:sotaro]]

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

Comment 23

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

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

Comment 25

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Can you get some logs through wireshark for the different browsers?

Comment 26

[Sotaro Ikeda [:sotaro]]

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

Comment 27

[Sotaro Ikeda [:sotaro]]

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

Comment 28

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 29

[Chris Peterson [:cpeterson]]

Sotaro, are you using IPv6?

Comment 30

[Sotaro Ikeda [:sotaro]]

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

Comment 31

[Chris Peterson [:cpeterson]]

I am reaching out to our YouTube contacts now.

Comment 32

[Sotaro Ikeda [:sotaro]]

Attachment: Wireshark log - youtube video playback via ie

Comment 33

[Sotaro Ikeda [:sotaro]]

Attachment: Wireshark log - youtube video playback via firefox

Comment 34

[Richard Leider]

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

Comment 35

[Jeff Muizelaar [:jrmuizel]]

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

[Richard Leider]

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

[Justin L.]

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.

Comment 38

[Dragana Damjanovic [:dragana]]

Can make  http log:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Comment 39

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking 37+ as this is important for MSE.

Comment 40

[Jason Duell]

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

Comment 41

[Jeff Muizelaar [:jrmuizel]]

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)"}

Comment 42

[Jeff Muizelaar [:jrmuizel]]

I'm not getting the same CORS issue anymore right now either.

Comment 43

[Jeff Muizelaar [:jrmuizel]]

I can however still reproduce the hangs when trying to connect to the original r1---sn-gxuxapu-hm2e.googlevideo.com host

Comment 44

[Dragana Damjanovic [:dragana]]

Jeff, can you also send a http log when it hangs?

Comment 45

[Sotaro Ikeda [:sotaro]]

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

Comment 46

[Sotaro Ikeda [:sotaro]]

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

Comment 47

[Justin L.]

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?

Comment 48

[Dragana Damjanovic [:dragana]]

Justin, you can e-mail it to me.

Comment 49

[Justin L.]

What's your email? Is it the dd.mozilla@gmail?

Comment 50

[Dragana Damjanovic [:dragana]]

Yes, thank you.

Comment 51

[Justin L.]

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.

Comment 52

[Dragana Damjanovic [:dragana]]

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

Comment 54

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

Untracking this since it's a duplicate; tracking 1136484 instead.

Comment 55

[Dragana Damjanovic [:dragana]]

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.

Comment 56

[Ralph Giles (:rillian)]

How serious do you think the remaining issue is? Should this still be a top-priority bug?

Comment 57

[Dragana Damjanovic [:dragana]]

Justin's http log (comment #51) and Jeff's

Comment 58

[Dragana Damjanovic [:dragana]]

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)

Comment 59

[Patrick McManus [: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)

Comment 60

[Chris Peterson [:cpeterson]]

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

Comment 61

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

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

Comment 62

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Dragana - is there an easy way to pref-off ipv6 to test/prove a user has an ipv6 problem?

Comment 63

[Dragana Damjanovic [:dragana]]

there is a pref network.dns.disableIPv6 in about:config you can set it to true.

Comment 64

[Dragana Damjanovic [:dragana]]

According o comment #59 both problems are fixed, so closing this bug.

Comment 66

[Aissen]

Just got this CORS issue with a YouTube video loading a https://r1---sn-cg07luez.googlevideo.com/videoplayback?... video.

Comment 67

[Chris Peterson [:cpeterson]]

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

[Aissen]

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.

Comment 69

[Chris Peterson [:cpeterson]]

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

[Aissen]

The video did not play at all, but as I said it now works in Firefox 42; you can ignore this report.