Closed Bug 594937 Opened 14 years ago Closed 14 years ago

The Wilderness Downtown Chrome Experiment is making us look bad

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dmandelin, Unassigned)

References

(
URL
)

Details

(Whiteboard: [chromeexperiments])

Attachments

(1 file)

Shark profile
836.88 KB, text/plain
Details 
When I enter an address, the progress indicator goes up to 88% or 91% and then never advances (for several minutes, at least). This happens in current betas and also in JM builds. Disabling JITs has no effect.

Safari has the same behavior.

Chrome starts at 75%, gets jerky for a second or two, then rapidly progresses to 100%. It takes about 5 seconds total to set up.
Attached file Shark profile — 
This is a profile made from 10 seconds of sampling during the "stuck at 88%" phase. It doesn't seem terribly informative. No single function shows up very big. It looks like about 21% is in paint, and maybe 30% or so in JS.

I forgot to mention in comment 0 that both Fx and Safari max out a core while waiting. (So it seems not to be a case where we hit an error and then stop.) I also don't see any errors in the JS console.
hmm, it worked when the site debuted. I watched it in a JM tinderbox build.
I did get it to work once this morning with a beta build, but not since then.
More info on what's happening: The % loading indicator measures progress loading up 32 "Content" objects of different kinds. We get stuck at 88%, meaning 4 are left unloaded. Those 4 seem to be consistently:

  #5   new VideoContent(650, 234, "http://media.thewildernessdowntown.com/04.ogv", "http://media.thewildernessdowntown.com/04.mp4")
 #17   new VideoMachine(320, 240, "http://media.thewildernessdowntown.com/55.ogv", "http://media.thewildernessdowntown.com/55.mp4")
 #18   new VideoMachine(320, 240, "http://media.thewildernessdowntown.com/52.ogv", "http://media.thewildernessdowntown.com/52.mp4")
 #28   new VideoContent(900, 510, "http://media.thewildernessdowntown.com/attack_04.ogv", "http://media.thewildernessdowntown.com/attack_04.mp4")

There is a "load failed" condition that is supposed to be set if any loads fail. That doesn't seem to happen.
OK, I think I have this figured out. The VideoContent object creates a video element with 2 source elements. It then sets the src attributes using the 2 URLs given. Finally, it starts a polling loop on video.readystate.

In our case, video.readystate never gets past 0. The reason is that:

 - we get a 404 trying to load the ogg file (try one of the links above to see)
 - we can't play mp4 files.

So clearly we're not going to be able to play that media. It still seems like there is bug: a shouldn't we produce some kind of error condition?

Anyway, the real problem is the missing ogg files. I poked around the front page of the site, but I see no contact info. The terms (see TERMS link at bottom right) refer to "@radical.media LLC". The contact page on their website is:

    http://www.radicalmedia.com/Contact

Does somebody want to call them up?
Assignee: general → nobody
Component: JavaScript Engine → Video/Audio
QA Contact: general → video.audio
Aside: we should consider this situation super-annoying, because the error behavior in Fx and Safari maxes out the CPU with a progress meter stuck at 88%, thus making it look like the problem is that those browsers are slow.
Summary: The Wilderness Downtown Chrome Experiment doesn't work → The Wilderness Downtown Chrome Experiment is missing some Ogg format videos and making us look bad
(In reply to comment #0)
> When I enter an address, the progress indicator goes up to 88% or 91% and then
> never advances (for several minutes, at least). This happens in current betas
> and also in JM builds. Disabling JITs has no effect.

This is caused by an error in our buffering logic, I've got a patch in bug 589626 which fixes this. That bug is blocking2.0, and basically ready to land, it just needs me to get a patch which fixes some test failures reviewed.

With the patches from bug 589626, the wilderness works, but is still slow compared to Chrome.
We do fire error events when loads fail due to network errors.  Where are they
handling the events?

We did load a large change to the media load algorithm on 2nd September (bug
485288 comment 33) which may have caused regressions or just broken the site by
having unexpected behaviour.
cc'ing Ricardo (@mrdoob), who was one of the main people who built this demo.
(In reply to comment #7)
> (In reply to comment #0)
> > When I enter an address, the progress indicator goes up to 88% or 91% and then
> > never advances (for several minutes, at least). This happens in current betas
> > and also in JM builds. Disabling JITs has no effect.
> 
> This is caused by an error in our buffering logic, I've got a patch in bug
> 589626 which fixes this. That bug is blocking2.0, and basically ready to land,
> it just needs me to get a patch which fixes some test failures reviewed.
> 
> With the patches from bug 589626, the wilderness works, but is still slow
> compared to Chrome.

Hmmm. How is it able to work? AFAICT our video element won't play the mp4 files, and the ogv files are missing (as of today).
Unless I'm missing something, the site only listens for error events on images, not for video/audio.  If it's relying on the video's readyState it's never going to notice errors, because on error readyState won't advance beyond HAVE_NOTHING (0).
(In reply to comment #8)
> We do fire error events when loads fail due to network errors.  Where are they
> handling the events?
> 
> We did load a large change to the media load algorithm on 2nd September (bug
> 485288 comment 33) which may have caused regressions or just broken the site by
> having unexpected behaviour.

FWIF With the new load algorithm, we'll fire an error event when we try to load unsupported MP4 source child. If they're not listening on error events this shouldn't be a problem.

(In reply to comment #10)
> Hmmm. How is it able to work? AFAICT our video element won't play the mp4
> files, and the ogv files are missing (as of today).

Hmmm, it's not working with my latest revision of my patches form bug 589626, and I remember changing an older version of my patches there to make this work.

FWIW those links you posted in comment 4 are all 301s (for me at least), not 404, and we can play them with FF trunk.
(In reply to comment #12)
> (In reply to comment #10)
> > Hmmm. How is it able to work? AFAICT our video element won't play the mp4
> > files, and the ogv files are missing (as of today).
> 
> Hmmm, it's not working with my latest revision of my patches form bug 589626,
> and I remember changing an older version of my patches there to make this work.
> 
> FWIW those links you posted in comment 4 are all 301s (for me at least), not
> 404, and we can play them with FF trunk.

For me it's a 301 and from there to a 404. Is this some kind of CDN misconfiguration that only affects certain locations?

$ wget http://media.thewildernessdowntown.com/04.ogv
--17:17:59--  http://media.thewildernessdowntown.com/04.ogv
           => `04.ogv'
Resolving media.thewildernessdowntown.com... 69.89.78.104
Connecting to media.thewildernessdowntown.com|69.89.78.104|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://cdn.thewildernessdowntown.com/media/04.ogv [following]
--17:17:59--  http://cdn.thewildernessdowntown.com/media/04.ogv
           => `04.ogv'
Resolving cdn.thewildernessdowntown.com... 72.21.81.133
Connecting to cdn.thewildernessdowntown.com|72.21.81.133|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
17:17:59 ERROR 404: Not Found.

I also get a 404 in the browser, both 3.6 and 4.0.
Hmm, WFM here:

$ wget http://media.thewildernessdowntown.com/04.ogv
--12:22:08--  http://media.thewildernessdowntown.com/04.ogv
           => `04.ogv'
Resolving media.thewildernessdowntown.com... 69.89.78.104
Connecting to media.thewildernessdowntown.com|69.89.78.104|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://cdn.thewildernessdowntown.com/media/04.ogv [following]
--12:22:08--  http://cdn.thewildernessdowntown.com/media/04.ogv
           => `04.ogv'
Resolving cdn.thewildernessdowntown.com... 93.184.221.133
Connecting to cdn.thewildernessdowntown.com|93.184.221.133|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 473,239 (462K) [video/ogg]

100%[========================================================>] 473,239      128.78K/s    ETA 00:00

12:22:12 (128.55 KB/s) - `04.ogv' saved [473239/473239]
So,

  for dmandelin, cdn.thewildernessdowntown.com -> 72. 21. 81.133
  for cpearce,   cdn.thewildernessdowntown.com -> 93.184.221.133

Seems like there must be a problem with the CDN.
Worked here... where are you based David?


$ wget http://media.thewildernessdowntown.com/04.ogv
--2010-09-10 01:39:13--  http://media.thewildernessdowntown.com/04.ogv
Resolving media.thewildernessdowntown.com... 69.89.78.104
Connecting to media.thewildernessdowntown.com|69.89.78.104|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://cdn.thewildernessdowntown.com/media/04.ogv [following]
--2010-09-10 01:39:13--  http://cdn.thewildernessdowntown.com/media/04.ogv
Resolving cdn.thewildernessdowntown.com... 93.184.221.133
Connecting to cdn.thewildernessdowntown.com|93.184.221.133|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 473239 (462K) [video/ogg]
Saving to: `04.ogv'

100%[======================================>] 473,239      962K/s   in 0.5s    

2010-09-10 01:39:14 (962 KB/s) - `04.ogv' saved [473239/473239]
(In reply to comment #16)
> Worked here... where are you based David?

I'm in Mountain View.
(In reply to comment #17)
> (In reply to comment #16)
> > Worked here... where are you based David?
> 
> I'm in Mountain View.

Do you also get 404 with the *.mp4?
Does the demo work in Chrome for you?
(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > Worked here... where are you based David?
> > 
> > I'm in Mountain View.
> 
> Do you also get 404 with the *.mp4?

The .mp4 versions load fine.

> Does the demo work in Chrome for you?

Yes. But the .ogv files listed above do not load in Chrome. So my guess is that the Chrome video element does support the .mp4 files, while Fx/Safari do not. But I don't know the details of Chrome video.
(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #17)
> > > (In reply to comment #16)
> > > > Worked here... where are you based David?
> > > 
> > > I'm in Mountain View.
> > 
> > Do you also get 404 with the *.mp4?
> 
> The .mp4 versions load fine.

And... with wget, do you also get 72.21.81.133 with the *.mp4?
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > (In reply to comment #17)
> > > > (In reply to comment #16)
> > > > > Worked here... where are you based David?
> > > > 
> > > > I'm in Mountain View.
> > > 
> > > Do you also get 404 with the *.mp4?
> > 
> > The .mp4 versions load fine.
> 
> And... with wget, do you also get 72.21.81.133 with the *.mp4?

Yes:

$ wget http://media.thewildernessdowntown.com/04.mp4
--18:03:41--  http://media.thewildernessdowntown.com/04.mp4
           => `04.mp4'
Resolving media.thewildernessdowntown.com... 69.89.78.104
Connecting to media.thewildernessdowntown.com|69.89.78.104|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://cdn.thewildernessdowntown.com/media/04.mp4 [following]
--18:03:41--  http://cdn.thewildernessdowntown.com/media/04.mp4
           => `04.mp4'
Resolving cdn.thewildernessdowntown.com... 72.21.81.133
Connecting to cdn.thewildernessdowntown.com|72.21.81.133|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 576,388 (563K) [video/mp4]

100%[=========================================>] 576,388       --.--K/s

18:03:41 (7.97 MB/s) - `04.mp4' saved [576388/576388]
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > (In reply to comment #18)
> > > > (In reply to comment #17)
> > > > > (In reply to comment #16)
> > > > > > Worked here... where are you based David?
> > > > > 
> > > > > I'm in Mountain View.
> > > > 
> > > > Do you also get 404 with the *.mp4?
> > > 
> > > The .mp4 versions load fine.
> > 
> > And... with wget, do you also get 72.21.81.133 with the *.mp4?
> 
> Yes

Ok, I'll follow this conversation to the server guys. Sorry about that.

Maybe if you manage you get another IP you would get forwarded to another cdn that serves the .ogv without problems and continue from there?
(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #20)
> > > (In reply to comment #19)
> > > > (In reply to comment #18)
> > > > > (In reply to comment #17)
> > > > > > (In reply to comment #16)
> > > > > > > Worked here... where are you based David?
> > > > > > 
> > > > > > I'm in Mountain View.
> > > > > 
> > > > > Do you also get 404 with the *.mp4?
> > > > 
> > > > The .mp4 versions load fine.
> > > 
> > > And... with wget, do you also get 72.21.81.133 with the *.mp4?
> > 
> > Yes
> 
> Ok, I'll follow this conversation to the server guys. Sorry about that.
> 
> Maybe if you manage you get another IP you would get forwarded to another cdn
> that serves the .ogv without problems and continue from there?

Sure, but I'd rather have it just work everywhere. I'll try it again at home tonight to see what happens, but it was behaving about the same last night and it's nearby so I expect to see the same thing.
I just tried to load the .ogv files at home with the same result (404). It's pretty nearby but at least it's not just at MoCo.
Brandon Burton from Reliam here, we are the hosting provider for www.thewildernessdowntown.com. 

Ricardo pointed me to this thread earlier and I found one of the web servers that are serving the origin was not correctly serving up requests for /media/ 

I've fixed this and this will resolve the 404 issue

David, if you can try the wget again and if you still see an issue, send us an email with the output, that'd be awesome

Thanks,

Brandon
(In reply to comment #25)
> Brandon Burton from Reliam here, we are the hosting provider for
> www.thewildernessdowntown.com. 
> 
> Ricardo pointed me to this thread earlier and I found one of the web servers
> that are serving the origin was not correctly serving up requests for /media/ 
> 
> I've fixed this and this will resolve the 404 issue

Thanks very much! The wget now goes through, and it works great in browsers as well.

> David, if you can try the wget again and if you still see an issue, send us an
> email with the output, that'd be awesome

Will do (if anything goes wrong, which it probably won't).
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Ah, I've figured this out! The problem is that the audio element which is loading wutc.ogg has its 'preload' attribute set to 'metadata', but the page's script is waiting for the audio element to load further (I think to HAVE_FUTURE_DATA readyState) but we never do that, since the audio element asked for preload="metadata", we're suspending the load after loading metadata, and not advancing the readyState past HAVE_CURRENT_DATA.

They really shouldn't assume we'll load more than just the metadata if they set preload="metadata"... I guess Chrome does...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: The Wilderness Downtown Chrome Experiment is missing some Ogg format videos and making us look bad → The Wilderness Downtown Chrome Experiment is making us look bad
(In reply to comment #27)
> They really shouldn't assume we'll load more than just the metadata if they set
> preload="metadata"... I guess Chrome does...

Then again, loading only to metadata is also the default, perhaps they're not even setting the preload attribute...
Ricardo/drdoob: Could you do us a favour and change thewildernessdowntown to use set the preload attribute to "auto" on the audio element which is loading wutw.ogg?

Firefox will not go into readyState HAVE_FUTURE_DATA unless we've got 300ms or more audio data decoded, which we won't reach if we're loading a non preload="auto" media. By default, we treat all media elements as preload="metadata", as per the spec, and so we'll pause the load after loading the first frame.
Whiteboard: [chromeexperiments]
Done. Let me know if it still doesn't work.
(In reply to comment #30)
> Done. Let me know if it still doesn't work.

Thanks Ricardo, I had a look, but it's still not working. It looks like you've set the preload attribute on the <audio>'s child <source> elements, not on the audio element itself? The preload attribute is only recognized on the <audio> element itself, not on its <source> children. Would you be able to set the preload attribute on the <audio> element instead? Thanks very much!
Uops, should be fixed now...
Awesome! It loads now in FF4 nightlies. Sometimes I got stuck at 97% loading, but I think that's my crappy hotel WiFi. Thanks for making that change Mr Doob! 

At least it loads now, but it still performs better for me in Chrome. :(
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Unless the problem with the site I pointed out in comment 11 is fixed, any time a video or audio file fails to load the site is going to get stuck during the loading phase.  Mr. Doob, any chance you can fix that problem as well?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: