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.