[Commons-l] Broken videos

[Michael Dale]

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 at 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 at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/commons-l
>