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