[Commons-l] Broken videos

[Gregory Maxwell]

On Wed, Mar 17, 2010 at 7:26 PM, Lars Aronsson <lars at 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 at 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.