Magnus Manske wrote: I'm still convinced there is something strange with these two videos. I can watch all other videos on Commons. The only ones I ever had a problem with, were taken down, recoded and worked fine after that. So how do I tell what's wrong? I have a laptop that is less than half a year old, a clean Ubuntu Linux 9.10 install and the included Firefox 3.5.8 browser. This should work, but these two videos never play more than two seconds and after a while my CPU fan spins up, firefox runs 100%, and all I can do is a "kill -9", which kills any other work I had going in other browser windows and tabs. I downloaded the video. I can watch it fine in VLC. But when I try to play it with file:// in my browser, it stops after two seconds and nothing more happens. This time I can use the BACK button; I don't have to kill the browser. VLC does give the error message: [0x99c9fb8] main input error: ES_OUT_RESET_PCR called I have no idea what that means. Maybe it doesn't mean anything at all. Having to kill my browser is sooo 2002. If the solution is to switch to Chrome or Windows 7, then we better postpone any video projects another 6 to 12 months. I thought the time was right, and was so excited about this new initiative, but perhaps I was just wrong. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

On Tue, Mar 16, 2010 at 9:18 AM, Magnus Manske <magnusmanske(a)googlemail.com> wrote: Firefox buffering (and some other applications, no doubt) doesn't interact well with short high bit-rate videos. As this are both almost 5mbit/sec, this is probably the cause of the problems here. What happens is that it video begins downloading. Some portion is buffered ahead. The videos starts playing, but the buffer is quickly exhausted. The timer isn't stopped when the buffer underruns (either by design because its less disruptive, or because everything is timed from the audio and you didn't run out of audio) and by the time the buffer refills the video is over. The first way that this should be addressed is by providing lower bitrate variants... it's not reasonable to expect users to be able to stream a 5mbit/sec file. High rate files are good for editing, not so good for streaming. The second way this should be address is by making the lower bitrate variants strictly buffering constrained: A non-constrained video will easily have its instantaneous bitrate jump to 20x or more above the nominal, which would necessitate very large buffers in order to prevent underflow. The encoder can impose a constraint on these bursts, but the negative impact on quality is pretty significant. (In one pass rate controlled mode libtheora 1.1 imposes such a limit by default) For HTML5 video this can be addressed somewhat by adding the video element in a paused (non-autoplay) state with the prebuffer attribute.... then JS code, after a short fixed time (or after querying the browser buffering state), play is initiated. (Or it can be left for the user to hit play). Unfortunately, ubuntu firefox has some stupid bug where sometimes videos refuse to play if they've been paused until the page is reloaded.

Gregory Maxwell wrote: The video "6hpPowerTrowel.ogv" is 91 seconds long and 52 megabytes (415 megabits) large, streaming an average 4.6 megabits per second. My laptop has 2048 megabytes of RAM, so buffer space should not be a hardware issue. Downloading the file over my 10 megabit/second broadband takes 41 seconds, less than half the play time, so no buffering should be necessary. The only possible problem is the browser software. VLC plays the downloaded video without problems. But trying to view the downloaded file in Firefox using a file:// URL doesn't work at all. It stops after a few seconds and the browser doesn't give up, but continues to "wait". We can hope that Firefox 3.6 (or 3.7 or 3.8) will solve such problems, but still we can't expect everybody to use the latest version. Wikipedia should be useful in libraries and schools, where users aren't able to upgrade the browser. It will be another year or two before video can be a mature medium (without the kind of Flash player that made Youtube possible). In the mean time, we might have to restrict videos to 1 or 2 mbit/s, or some other arbitrary limitation that make them work. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

Gregory Maxwell wrote: This is not the browser development list, and I'm not interested in developing or upgrading my browser. I'm interested in video on Wikipedia and making it work for large numbers of users, using their existing browsers and versions. I can to upgrade my own browser, but I can't upgrade the browser for large numbers of other users. All I can do here and now is to note that today's browsers aren't ready for this. Can we determine what today's browsers are ready for? Will 2 megabit/second videos work? If so, let's set that limit for the coming year, and reevaluate the limit in early 2011. Wikimedia Commons generates thumbnails for still pictures, so it could generate reduced bandwidth versions of videos. But is it really the video bandwidth that sets the limit? I can watch videos with 2.3 and 3.4 megabit/seconds without any problems. It's really odd that 4.6 megabits should fail so utterly when 3.4 works so smooth. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

On Wed, Mar 17, 2010 at 7:26 PM, Lars Aronsson <lars(a)aronsson.se> wrote: [snip] Indeed, its not. So I'm not sure why you think we should be worrying about some niche browser bug. I would like to point out that the same kind of see-no-evil/hear-no-evil attitude is precisely why bugs like this were able to slip through in release versions. As someone who obviously seems to take some personal care in how well our website works, you ought to realize that its in your own interest to periodically test upcoming browser software in order to avoid being stuck with undesirable behaviour later. (http://lists.wikimedia.org/pipermail/commons-l/2008-July/003999.html) [snip] Fortunately the problem you experienced appears to be limited to a relatively small subset of users on a subset of files. I'm confident that there are far more significant usability impediments. In particular, and I'm repeating myself because you don't seem to have noticed it the first time, multi-megabit files are _not_ going to reliably stream for a very broad swath of people regardless of how snazzy their software is. With your continued points about upgrading browsers I'm getting this impression that someone dumped a ton of toxic waste in the town square, and you're fussing about the colors clashing with the decorations on city hall. :) Who knows. The software has a bug. There is no speed that I can guarantee will work, only that based on what I know high rate files and files without instantaneous bitrate constraints are more likely to cause problems. Without triggering it with instrumented code I can't be absolutely sure that I know the cause. ... if you'd been willing to try the most recent version of firefox I'd have a better idea, but you're not even willing to do that. If its the behaviour that I think it is then the trigger condition is that the buffer runs dry for audio ahead of video while the player is getting a slog of enormous video frames, the player pauses waiting for the buffering to fill but ends with the audio output thread hung waiting for more audio data which it never gets because the audio output is blocking the unpause. But, as you said, this isn't the browser development list. I don't think that "Limits" make sense... we allow people to upload gigapixel PNGs and SVGs which would bring viewing clients to a halt. Life goes on. Simetrical's suggestion of a high bitrate warning might be helpful. Thumnailing is important because you simply can't expect most users have many megabits/sec of reliable connectivity back to Wikimedia. That smaller files are less problematic for some users with older browser versions is just a bonus. On Wed, Mar 17, 2010 at 8:27 PM, Stephen Bain <stephen.bain(a)gmail.com> wrote: We can only hope to be aware of it, be reasonably sensitive to it (don't make essential features of the site depend on things that fail for many people), determine that upgrading fixes it and encourage people to upgrade when they can.