Status Update
No update yet.
Comments
si...@defenderrazor.com
[Comment Deleted]
aj...@chromium.org
Able to reproduce this on across all the platforms on the latest M-43(43.0.2338.2) as well.This is regression issue, broken in M-42.
Change log:
================
https://chromium.googlesource.com/chromium/src/+log/42.0.2296.0..42.0.2297.0?pretty=fuller&n=10000
Blink change log:
===================
https://chromium.googlesource.com/chromium/blink/+log/4b9569f905d2973e999040a512d83840d53359c4..2fb8a571a5355c27bb1b257281c5a2c386331a4e?pretty=fuller&n=10000
On inspecting the blink change, seeinghttps://chromium.googlesource.com/chromium/blink/+/aa4fece4ef2ba82ad2a38d52510dc70a964e7bcb to be the Preload video related change. Marking this as RB-Stable for M-42.
@Dale: Could you please take a look at this if the change is related.
Thanks in advance!
Change log:
================
Blink change log:
===================
On inspecting the blink change, seeing
@Dale: Could you please take a look at this if the change is related.
Thanks in advance!
da...@chromium.org
Not sure we can do anything about this. It's not really a regression, it's https://crbug.com/chromium/162627 . The only reason this worked previously is that the clips in this case are small enough to download completely instead of partially.
preload=metadata explicitly only downloads enough data for metadata and then suspends the connection. You should use preload=none in this case.
-RBS, +xhwang for additional thoughts. In terms of quick patches, at best we could timeout preload=metadata connections after a few seconds in the deferred state.
preload=metadata explicitly only downloads enough data for metadata and then suspends the connection. You should use preload=none in this case.
-RBS, +xhwang for additional thoughts. In terms of quick patches, at best we could timeout preload=metadata connections after a few seconds in the deferred state.
da...@chromium.org
(also note it only previously works if you had a high bandwidth connection, low bandwidth users would have hit this issue).
si...@defenderrazor.com
At the absolute minimum this issue should be fixed with a simple heuristic
"If there are 2 or more connections still available for a domain (when encountering preload='metadata' then download metadata and suspend connection. If there is only 1 connection available then download the metadata and release the connection immediately."
The current behavior is absolutely not what somebody writing HTML should be expected to know about or have to work around. It is also open to abuse where a website could be completely locked up due to a badly behaved page requesting the same video from the same domain as the original host.
W3C says the following :
"metadata": Hints to the UA that the user is not expected to need the video, but that fetching its metadata (dimensions, first frame, track list, duration, and so on) is desirable.
If the UA cannot load the metadata without locking all connections then it should not be keeping the connection open.
It is this statement that is most concerning :
"preload=metadata explicitly only downloads enough data for metadata and then suspends the connection. You should use preload=none in this case."
That's not my responsibility to make a decision like that. That's what browser should be doing.
Thx
"If there are 2 or more connections still available for a domain (when encountering preload='metadata' then download metadata and suspend connection. If there is only 1 connection available then download the metadata and release the connection immediately."
The current behavior is absolutely not what somebody writing HTML should be expected to know about or have to work around. It is also open to abuse where a website could be completely locked up due to a badly behaved page requesting the same video from the same domain as the original host.
W3C says the following :
"metadata": Hints to the UA that the user is not expected to need the video, but that fetching its metadata (dimensions, first frame, track list, duration, and so on) is desirable.
If the UA cannot load the metadata without locking all connections then it should not be keeping the connection open.
It is this statement that is most concerning :
"preload=metadata explicitly only downloads enough data for metadata and then suspends the connection. You should use preload=none in this case."
That's not my responsibility to make a decision like that. That's what browser should be doing.
Thx
da...@chromium.org
+network folk; the media layer doesn't know if we're hitting the 6 connection cap ahead of time. The net/ layer could terminate deferred connections if it's approaching the 6 connection cap.
We could try and bake in some knowledge of this cap to the media layer, but I'm not sure that's desirable.
We could try and bake in some knowledge of this cap to the media layer, but I'm not sure that's desirable.
mm...@chromium.org
Media requests hitting this limit when there are a bunch of paused media elements on a page is a longstanding issue, and I'd love to see it fixed.
That having been said, having the network stack randomly close connections that no one's reading from sounds like a really bad idea. The network stack has no visibility into what's going on elsewhere. Perhaps the renderer process is busy. Perhaps the consumer of the request really wants the result and is doing file IO. That just sounds like a recipe for a huge number of issues.
Even moving this logic into a higher layer, like the ResourceScheduler or ResourceDispatcherHost, seems problematic to me. If your solution is to add some sort of browser-side global media request tracker which tracks requests with ResourceThrottles, just for this purpose, I could live with it, but it still seems like the wrong approach to me.
I don't think we want knowledge of the exact cap. Could we just not keep more than one hung media request in a renderer process?
That having been said, having the network stack randomly close connections that no one's reading from sounds like a really bad idea. The network stack has no visibility into what's going on elsewhere. Perhaps the renderer process is busy. Perhaps the consumer of the request really wants the result and is doing file IO. That just sounds like a recipe for a huge number of issues.
Even moving this logic into a higher layer, like the ResourceScheduler or ResourceDispatcherHost, seems problematic to me. If your solution is to add some sort of browser-side global media request tracker which tracks requests with ResourceThrottles, just for this purpose, I could live with it, but it still seems like the wrong approach to me.
I don't think we want knowledge of the exact cap. Could we just not keep more than one hung media request in a renderer process?
da...@chromium.org
Is the 6 connection limit per render process or global to the browser process? If per-render we could probably put something in temporarily until we can get a proper cache oracle in.
mm...@chromium.org
It's global to the browser process.
si...@gmail.com
OP: looks good in Canary now. Thanks for everyone's help
[Deleted User] <[Deleted User]>
STILL BROKEN in 62.0.3202.94 It's 5+ years later, but this bug STILL lingers! :o Pages work just fine in FF and even in IE 11, but not in Chrome!! Bugs like this one are a serious tarnish on Chrome... and indeed it confirms my long-standing preference for FF. It's just a shame that a giant like Google lets serious issues like these slip by.
On my page, I have 30 HTML5 videos with preload='metadata'. The first 6 or so connections try to get the metadata and then THEY ALL STALL. At that point, not only is no more metadata fetched, but all the videos on the page become unplayable. As people were pointing out YEARS ago, Chrome seems to fail to release the connections it uses to fetch the metadata.
On my website, I'll have to change the preload to 'none' and do a lot of work to make the pages more presentable with posters, all to pander to Chrome users. Thanks a lot, Chrome :(
On my page, I have 30 HTML5 videos with preload='metadata'. The first 6 or so connections try to get the metadata and then THEY ALL STALL. At that point, not only is no more metadata fetched, but all the videos on the page become unplayable. As people were pointing out YEARS ago, Chrome seems to fail to release the connections it uses to fetch the metadata.
On my website, I'll have to change the preload to 'none' and do a lot of work to make the pages more presentable with posters, all to pander to Chrome users. Thanks a lot, Chrome :(
is...@google.com
This issue was migrated from crbug.com/chromium/468930?no_tracker_redirect=1
[Multiple monorail components: Internals>Media, Internals>Network]
[Monorail mergedinto:crbug.com/chromium/162627 ]
[Monorail components added to Component Tags custom field.]
[Multiple monorail components: Internals>Media, Internals>Network]
[Monorail mergedinto:
[Monorail components added to Component Tags custom field.]
Description
Example URL:
Steps to reproduce the problem:
See attached video
Chrome 41 - OK
Chrome 42 - FAIL
Chrome 43 - FAIL
1. Create 10 MP4 videos on a page with PRELOAD='METADATA'
2. Only 6 will load. Last 4 are stuck in 'pending' no matter how long you wait. HTTP 206 request (partial content)
3. Restart Chrome
4. Switch PRELOAD='AUTO'
5. All videos will load (HTTP 200)
If domain sharding is not used then the HTML page itself can lock up rendering the browser useless for that domain.
What is the expected behavior?
Should be able to put many videos on a page without the entire browser locking up!
Videos should not get stuck after metadata is loaded.
See attached video
What went wrong?
See attached video
Chrome 41 - OK
Chrome 42 - FAIL
Chrome 43 - FAIL
Videos get stuck in pending state after 6 requests are made to load metadata from the same domain. This max requests 'lock' is not released to allow 7, 8, 9th request to that domain to proceed.
Did this work before? Yes v42
Is it a problem with Flash or HTML5? HTML5
Does this work in other browsers? Yes
Chrome version: 41.0.2272.89 Channel: stable
OS Version: 6.3
Flash Version: Shockwave Flash 17.0 r0
See attached video
Chrome 41 - OK
Chrome 42 - FAIL
Chrome 43 - FAIL
Videos get stuck in pending state after 6 requests are made to load metadata from the same domain. This max requests 'lock' is not released to allow 7, 8, 9th request to that domain to proceed.