Last modified: 2013-05-13 09:39:33 UTC
Using Opera I'm not able to play videos for some weeks now. This was confirmed by others on the village pump of de.wikipedia. After start playing the video it stops immediately (after playing a part of a second). I don't really know what's the exact reason, but after some analyzing it seems to be a loading error. If I start watching a video with the mediawiki player, I'm even not able to play it afterwards in Opera (same problem with the internal player). But if I play the video first using Opera (and let Opera load the whole video), I can play it using the mediawiki player afterwards without any problems. Other sites (YouTube, WebM test pages) don't have this error.
Maybe this has to do with the following code used by the player: this.bufferedPercent = (vid.buffered.end(0) / vid.duration); This isn't a good solution. It presumes that the whole video is loaded in one block starting at time zero. "buffered" is of type TimeRanges (see http://dev.w3.org/html5/spec-author-view/video.html#timeranges). If the client for example loads two parts in parallel (e.g. seconds 0-30 and 30-60 of a 60 second video), buffered.length would be >1 and buffered.end(0) could be 30 even if the whole video is loaded. It's not defined if these ranges should be merged. I saw this behavior once in Opera, so maybe there is a relationship. At least it would be better not to use "bufferedPercent" but to really show which parts are loaded like in this demo: http://people.mozilla.com/~cpearce/buffered-demo.html
dont see this on my local setup, but can confirm that i.e. http://commons.wikimedia.org/wiki/File:Spawning_Pocillopora_meandrina_-_pone.0050847.s002.ogv does not play in opera here. however it also does not play the videos opening video urls directly. both the uploaded ogv and webm fail: http://upload.wikimedia.org/wikipedia/commons/6/68/Spawning_Pocillopora_meandrina_-_pone.0050847.s002.ogv http://upload.wikimedia.org/wikipedia/commons/thumb/6/68/Spawning_Pocillopora_meandrina_-_pone.0050847.s002.ogv/Spawning_Pocillopora_meandrina_-_pone.0050847.s002.ogv.360p.webm a simple html page just loading a video element with the webm also stops playing, so i dont think this is related to bufferedPrecent. since playing it as a static file from apache works, this is most likely related to squid/varnish/swift and range requests.
(In reply to comment #2) > however it also does not play the videos opening video urls directly. > http://upload.wikimedia.org/wikipedia/commons/thumb/6/68/ > Spawning_Pocillopora_meandrina_-_pone.0050847.s002.ogv/ > Spawning_Pocillopora_meandrina_-_pone.0050847.s002.ogv.360p.webm For me this works with two limitations: I have to pause and re-start the playing and I only hear the sound and do not see any video (because they are served as audio/webm, which let opera use the audio html element to show it; reported in bug 43476). It seems, that you're right about the squid/range thing. I had a look at the request headers and compared them to what is happening in Firefox: In Firefox the request looks relatively normal: The request for the webm file is a range request: "Range: bytes=0-". The answer is "HTTP/1.0 206 Partial Content" with "Content-Range: bytes 0-2408692/2408693" (this is for File:0GLOBO.ogv on commons). With Opera this looks a bit strange: At first there is a request which is nearly the same as the firefox request. But immediately after the first request (Range: bytes=0-), a second request is sent to the server (Range: bytes=2400193-2408692; If-Range: 0a7703c116193f8057eb330718428963). So the end of the file is requested (maybe to get the duration like for ogg videos, but normally this isn't needed for webm), but until this second request I didn't see any answer from the server - how does Opera know the content length and the ETag (for If-Range)? At least there is only one answer to this request and it's not a 206 but a 200 (although both request are range requests). It seems to me, that Opera thinks the file which is sent altogether is the answer to the last range request. When trying to reload this video directly in opera, always the second range request is made (the end of the file) - that's why it didn't even work directly in Opera after trying to watch it using the mediawiki player. The question is: Why does the servers answer with 200 instead of 206 to a range request from opera but with 206 to a range request from firefox? Is it because of the If-Range thing?
[mr.heat: This is not a blocker by definition - resetting.]
(In reply to comment #3) > (In reply to comment #2) > > > however it also does not play the videos opening video urls directly. > > > http://upload.wikimedia.org/wikipedia/commons/thumb/6/68/ > > Spawning_Pocillopora_meandrina_-_pone.0050847.s002.ogv/ > > Spawning_Pocillopora_meandrina_-_pone.0050847.s002.ogv.360p.webm > > For me this works with two limitations: I have to pause and re-start the > playing and I only hear the sound and do not see any video (because they are > served as audio/webm, which let opera use the audio html element to show it; > reported in bug 43476). > > It seems, that you're right about the squid/range thing. I had a look at the > request headers and compared them to what is happening in Firefox: > > In Firefox the request looks relatively normal: The request for the webm file > is a range request: "Range: bytes=0-". The answer is "HTTP/1.0 206 Partial > Content" with "Content-Range: bytes 0-2408692/2408693" (this is for > File:0GLOBO.ogv on commons). > > With Opera this looks a bit strange: At first there is a request which is > nearly the same as the firefox request. But immediately after the first > request > (Range: bytes=0-), a second request is sent to the server (Range: > bytes=2400193-2408692; If-Range: 0a7703c116193f8057eb330718428963). So the > end > of the file is requested (maybe to get the duration like for ogg videos, but > normally this isn't needed for webm), but until this second request I didn't > see any answer from the server - how does Opera know the content length and > the > ETag (for If-Range)? At least there is only one answer to this request and > it's > not a 206 but a 200 (although both request are range requests). It seems to > me, > that Opera thinks the file which is sent altogether is the answer to the last > range request. When trying to reload this video directly in opera, always the > second range request is made (the end of the file) - that's why it didn't > even > work directly in Opera after trying to watch it using the mediawiki player. > > The question is: Why does the servers answer with 200 instead of 206 to a > range > request from opera but with 206 to a range request from firefox? Is it > because > of the If-Range thing? I just did a bit of testing, but haven't been able to reproduce this yet. Could you please do another packet capture and post the full request and response, so I can exactly replicate the request? What I did notice so far is that Varnish seems to ignore If-Range completely. A quick grep through the source indicates that it's not evaluating that header at all.
indeed, i am no longer able to reproduce this issue, opera also plays all videos i try to open now. Did anything change since this was reported or could it be that response times are better now and so the issue does not show up anymore?
Nothing changed for me and at least two other uses complaining at de.wikipedia.org - it's not possible to play videos using Opera. Just open http://commons.wikimedia.org/wiki/File:0DROP.ogv (as an example) and try to play. It plays some parts of a second and then stops. But I guess it doesn't make sense to invest a lot of time in this, since Opera will switch to WebKit in 2013, so some some day this bug could be closed ;)
(In reply to comment #7) > Open http://commons.wikimedia.org/wiki/File:0DROP.ogv (as an example) and > try to play. It plays some parts of a second and then stops. I can confirm this with Opera 12.13.
Just one more data point: Opera 12.14/Linux plays http://commons.wikimedia.org/wiki/File:0DROP.ogv without problems.
Updated to Opera 12.14 Build 1738 on Fedora: Problem is FIXED now. Not sure how to proceed: WONTFIX/INVALID on our end, or is some Opera version detection wanted?
My Opera 12.14 on Windows XP doesn't play the video at all.
Created attachment 12016 [details] Requests Opera sent and responses it received for me. (In reply to comment #3) > For me this works with two limitations: I have to pause and re-start the > playing and I only hear the sound and do not see any video (because they are > served as audio/webm, which let opera use the audio html element to show it; > reported in bug 43476). > > It seems, that you're right about the squid/range thing. > > [...] > > The question is: Why does the servers answer with 200 instead of 206 to a > range > request from opera but with 206 to a range request from firefox? Is it > because > of the If-Range thing? I was able to reproduce this behavior (although the video linked above, http://commons.wikimedia.org/wiki/File:0DROP.ogv , doesn't play at all for me). For the requests Opera sent and responses it received after I loaded the page in a private tab and clicked the play button, see attachment (captured using Fiddler).
Also - the responses to both requests were byte-for-byte identical (also having the same Content-Length in headers). It seems like the Range header on the second one was completely ignored.
It's really not reproducible - I tried it on three different machines (all Opera 12.14 on Windows 7) and had different results (two not working, one working). I thought about the differences of the systems and thought about the connection (the two not working were connected using WiFi whereas the working one was connected using LAN) - then I connected the LAN to one of the PCs formerly connected using WiFi: and playing videos worked. But the strange thing is: after removing LAN and re-enabling WiFi it still worked (for different videos, so no caching thing).
Opera 12.15, same machine, the video works perfectly now. Was this fixed or is this accidental?
I don't know if something was changed, but now it works for me, too.
Closing for the time being as nobody can reproduce anymore. Please reopen if this reappears.
