This past weekend, at the SXSW conference, a new initiative was launched to "get video on Wikipedia", http://videoonwikipedia.org/
That sounds like a great idea.
(I wasn't there, but I was told.)
But among the first videos to be uploaded since the announcement are two that show some construction equipment and both break my browser every time I try to watch them. How can this be possible with a fully updated Mozilla Firefox 3.5.8 on Ubuntu Linux?
I suppose something went wrong in the OGG encoding, but still, browsers should not be fooled by this, and/or Wikimedia Commons needs to make sure videos are correctly encoded so they can be safely watched.
I have asked that these two broken videos be removed, http://commons.wikimedia.org/wiki/File:6hpPowerTrowel.ogv http://commons.wikimedia.org/wiki/File:13hpBoren.ogv
We discussed for a long time why OpenOffice documents can't be uploaded to Wikimedia Commons because the ZIP encoding wasn't safe and could explode in the face of the user. Well, maybe OGG isn't safe either?
Should we just ban video all together?
On Tue, Mar 16, 2010 at 9:29 AM, Lars Aronsson lars@aronsson.se wrote:
This past weekend, at the SXSW conference, a new initiative was launched to "get video on Wikipedia", http://videoonwikipedia.org/
That sounds like a great idea.
(I wasn't there, but I was told.)
But among the first videos to be uploaded since the announcement are two that show some construction equipment and both break my browser every time I try to watch them. How can this be possible with a fully updated Mozilla Firefox 3.5.8 on Ubuntu Linux?
I suppose something went wrong in the OGG encoding, but still, browsers should not be fooled by this, and/or Wikimedia Commons needs to make sure videos are correctly encoded so they can be safely watched.
I have asked that these two broken videos be removed, http://commons.wikimedia.org/wiki/File:6hpPowerTrowel.ogv http://commons.wikimedia.org/wiki/File:13hpBoren.ogv
We discussed for a long time why OpenOffice documents can't be uploaded to Wikimedia Commons because the ZIP encoding wasn't safe and could explode in the face of the user. Well, maybe OGG isn't safe either?
Should we just ban video all together?
You mean like you marked them as "speedy-delete" because your browser doesn't like them?
They work fine for me, and probably for most other people, but so what?
Magnus Manske wrote:
You mean like you marked them as "speedy-delete" because your browser doesn't like them?
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.
On Tue, Mar 16, 2010 at 11:15 AM, Lars Aronsson lars@aronsson.se wrote:
Magnus Manske wrote:
You mean like you marked them as "speedy-delete" because your browser doesn't like them?
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.
Checking on Ubuntu 9.10, I can confirm that the video (tested only one) has some issues in Firefox. It stops after 5 sec, but doesn't kill the browser; it just doesn't proceed.
It stops in MediaPlayer after ca. 8 sec when played from the net, but runs nicely when played from local disk. Same for VLC.
So, it's the network/streaming component, not the file.
Cheers, Magnus
On Tue, Mar 16, 2010 at 9:18 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Checking on Ubuntu 9.10, I can confirm that the video (tested only one) has some issues in Firefox. It stops after 5 sec, but doesn't kill the browser; it just doesn't proceed.
It stops in MediaPlayer after ca. 8 sec when played from the net, but runs nicely when played from local disk. Same for VLC.
So, it's the network/streaming component, not the file.
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.
In addition to firefox getting a new release out that works better with linux audio we should try and review and deploy the transcoding addition to oggHandler. This way high res videos won't get directly embed in articles: http://prototype.wikimedia.org/sandbox.2/Transcode_Test
In the mean time if user "used firefogg" we supply some good default encode settings.
Also sorry for the somewhat surprise mention of http://videoonwikipedia.org/ We are still trying to iron out a few bugs before we more make wider calls for feedback and start publicizing it more ( video thumbnails for example ) .. I will follow up with more details especially around getting input on: http://en.wikipedia.org/wiki/Wikipedia:Lights_Camera_Wiki
peace, --michael
Gregory Maxwell wrote:
On Tue, Mar 16, 2010 at 9:18 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Checking on Ubuntu 9.10, I can confirm that the video (tested only one) has some issues in Firefox. It stops after 5 sec, but doesn't kill the browser; it just doesn't proceed.
It stops in MediaPlayer after ca. 8 sec when played from the net, but runs nicely when played from local disk. Same for VLC.
So, it's the network/streaming component, not the file.
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.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Gregory Maxwell wrote:
Firefox buffering (and some other applications, no doubt) doesn't interact well with short high bit-rate videos.
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.
On Wed, Mar 17, 2010 at 1:08 PM, Lars Aronsson lars@aronsson.se wrote:
Gregory Maxwell wrote:
Firefox buffering (and some other applications, no doubt) doesn't interact well with short high bit-rate videos.
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.
Yes, but the browser isn't psychic. It doesn't know how long its going to take to download the file. Before it starts it doesn't know how quickly the buffer is going to drain. Waiting for the whole file to load is not generally acceptable. (Nor is consuming unbounded amounts of memory ... what happens if you hit a gallery page with 100 of those 52 mbyte files on it, should the browser download and store 5GBytes of data?)
So the browser takes a best effort guess. On very high bitrate files it gets it wrong. The consequence is a stutter or stall, and on short enough files on Ubuntu (or, I expect, 3.5 on any alsa-pulseaudio-wrapper GNU/Linux system) it looks like it can also trigger the waiting-for-audio-after-pause bug.
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
Why don't you test it? Firefox 3.6 has been out for half a year. FWIW, It doesn't fail in 3.5 for me, but I'm not using ubuntu.
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.
Multi-megabit/sec files are not going to stream for most users regardless of the player technology... that isn't something that improved client software is going to fix.
It appears that you've hit a case where it fails worse than it should or could, but your configuration isn't one of the most popular and the consequence of the failure is (primarily) that the video doesn't work. It seems to If you're unhappy with the video performance of your client software, upgrade your client software, or switch to using the cortado player option. The site should remember your preferences.
Gregory Maxwell wrote:
Yes, but the browser isn't psychic. It doesn't know how long its going to take to download the file. Before it starts it doesn't know how
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.
On 17 March 2010 23:26, Lars Aronsson lars@aronsson.se wrote:
Gregory Maxwell wrote:
Yes, but the browser isn't psychic. It doesn't know how long its going to take to download the file. Before it starts it doesn't know how
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.
That requires more processing power. Might be possible to automatically add a warning that a video is unlikely to work properly for most people.
On Wed, Mar 17, 2010 at 7:26 PM, Lars Aronsson lars@aronsson.se wrote: [snip]
This is not the browser development list, and I'm not interested in developing or upgrading
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]
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.
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. :)
Can we determine what today's browsers are ready for? Will 2 megabit/second videos work?
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.
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.
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@gmail.com wrote:
If the problem lies with bugs in packages or drivers in the user's system, how can we do anything about it?
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.
On Wed, Mar 17, 2010 at 12:47 AM, Gregory Maxwell gmaxwell@gmail.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.
The problem is only replicated on Linux though, the videos work fine for Firefox on Windows (going only by the responses in this thread - more testing?).
On Wed, Mar 17, 2010 at 1:04 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
Otherwise, it's pretty likely you're hitting https://bugzilla.mozilla.org/show_bug.cgi?id=496147 (or another on of several closely related linux audio specific bugs which are various degrees of fixed in the latest firefox development). I believe that disabling pulseaudio will work around this collection of issues on ubuntu.
If the problem lies with bugs in packages or drivers in the user's system, how can we do anything about it?