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 03/16/2010 10:29 AM, Lars Aronsson 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
Does not "break" my browser here. What do you mean with breaks your browser?
j
On 16 March 2010 10:29, Lars Aronsson lars@aronsson.se wrote:
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.oghttp://commons.wikimedia.org/wiki/File:13hpBoren.ogv
Nothing wrong with it here. Windows 7, Chrome / Firefox / IE8
Michel Vuijlsteke
On 16 March 2010 10:29, 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.
Uh.. binary content in a wiki.
Well.. the other option are Youtube, that can't be trusted, as videos are removed often. Or the archive.org [1], that seems his mission.
[1] http://www.archive.org/details/movies
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?
Uh.. buffer overflow errors, complex file format loaders in programming languages like C.... Or false assumptions about memory management with poor detection error and fatal consecuences. Maybe even bad program intercomunication. ... The internet was built on text based protocols to avoid these problems or help debug then.
On Tue, Mar 16, 2010 at 7:15 AM, Lars Aronsson lars@aronsson.se wrote:
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.
You aren't running in a virtual machine are you? Linux+VM is known as a source of playback problems for firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=526080
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.
On Tue, Mar 16, 2010 at 6:52 AM, Tei oscar.vives@gmail.com wrote:
Uh.. buffer overflow errors, complex file format loaders in programming languages like C.... Or false assumptions about memory management with poor detection error and fatal consecuences. Maybe even bad program intercomunication. ... The internet was built on text based protocols to avoid these problems or help debug then.
Ironic that you say that... the variable length null terminated string is probably the worst thing to ever happen to computer security. Text does imply a degree of transparency, but it's not security cure-all.
In any case, video and audio are in the same boat as Jpeg/png, +/- some differences in software maturity. There aren't any known or expected malware vectors for them.
On 16 March 2010 15:04, Gregory Maxwell gmaxwell@gmail.com wrote: ..
On Tue, Mar 16, 2010 at 6:52 AM, Tei oscar.vives@gmail.com wrote:
Uh.. buffer overflow errors, complex file format loaders in programming languages like C.... Or false assumptions about memory management with poor detection error and fatal consecuences. Maybe even bad program intercomunication. ... The internet was built on text based protocols to avoid these problems or help debug then.
Ironic that you say that... the variable length null terminated string is probably the worst thing to ever happen to computer security. Text does imply a degree of transparency, but it's not security cure-all.
Nothing is, but transparency is the next cool thing.
In any case, video and audio are in the same boat as Jpeg/png, +/- some differences in software maturity. There aren't any known or expected malware vectors for them.
Agreed. But seems possible to generate streams of video that crash the browser. So.. probably autoplay is evil. (is already evil because is NSFW since distract coworkers )
On Tue, Mar 16, 2010 at 12:27 PM, Tei oscar.vives@gmail.com wrote:
In any case, video and audio are in the same boat as Jpeg/png, +/- some differences in software maturity. There aren't any known or expected malware vectors for them.
Agreed. But seems possible to generate streams of video that crash the browser. So.. probably autoplay is evil. (is already evil because is NSFW since distract coworkers )
Pegging the CPU on a fairly less than very common platform with a copy of firefox which is soon to be outdated is probably not an enormous worry. Growing pains. Of course, it's useful to submit bug reports on this stuff where ones don't already exist.
If you encounter files that break Firefox, Opera, Chrome, Safari(+xiphqt) please let me know and I'll make sure that a bug gets reported. I'm also happy to fix cortado (The java fallback for clients without proper video support) bugs, — but Wikimedia is using a copy of cortado so enormously old that it's not unlikely that any problems encountered have already been fixed.
In any case, none of the video on wikimedia sits is "autoplay" in the sense that it starts on its own. The video tag itself is set to autoplay, but the tag doesn't get inserted into the page until the user clicks. No video surprises. (Unfortunately this process doesn't give the video tag any chance to pre-buffer the video).
Gregory Maxwell wrote:
In any case, none of the video on wikimedia sits is "autoplay" in the sense that it starts on its own. The video tag itself is set to autoplay, but the tag doesn't get inserted into the page until the user clicks. No video surprises. (Unfortunately this process doesn't give the video tag any chance to pre-buffer the video).
Would it help adding a <link rel="prefetch"> to the first video in the page?
BTW, the current video handling doesn't work without javascript. I thought we provided a link in such case. Now there's just an useless button.
On Wed, Mar 17, 2010 at 10:39 AM, Platonides Platonides@gmail.com wrote:
Would it help adding a <link rel="prefetch"> to the first video in the page?
In Firefox, yes. Does anyone else implement that? If it's only Firefox, we could just as well replace Cortado with <video autobuffer> to begin with as soon as the page loads. In Chrome and Safari, we don't even need the autobuffer, since they don't implement it. (Actually, <video autobuffer preload=auto> would be the current way to do it, given recent spec changes.)
BTW, the current video handling doesn't work without javascript. I thought we provided a link in such case. Now there's just an useless button.
There's always a link on the File: page itself, no?
Aryeh Gregor wrote:
BTW, the current video handling doesn't work without javascript. I thought we provided a link in such case. Now there's just an useless button.
There's always a link on the File: page itself, no?
Yes, there's an info image which leads you to the File: page. Where you also have the useless button. I don't think it's trivial to know that you can download [view in browser] by clicking the filename when you just want to view the video on wikipedia article Foo.
On Wed, Mar 17, 2010 at 5:37 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Wed, Mar 17, 2010 at 10:39 AM, Platonides Platonides@gmail.com wrote:
Would it help adding a <link rel="prefetch"> to the first video in the page?
In Firefox, yes. Does anyone else implement that? If it's only Firefox, we could just as well replace Cortado with <video autobuffer> to begin with as soon as the page loads. In Chrome and Safari, we don't even need the autobuffer, since they don't implement it. (Actually, <video autobuffer preload=auto> would be the current way to do it, given recent spec changes.)
I hope no one is ever insane enough to use this. Imagine those people with cellphones and no data transfer flat (~70% of mobile internet users) - their bills will skyrocket when even a single video is set to auto-preload.
Marco
On 3/17/10 1:02 PM, Marco Schuster wrote:
On Wed, Mar 17, 2010 at 5:37 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Wed, Mar 17, 2010 at 10:39 AM, PlatonidesPlatonides@gmail.com wrote:
Would it help adding a<link rel="prefetch"> to the first video in the page?
In Firefox, yes. Does anyone else implement that? If it's only Firefox, we could just as well replace Cortado with<video autobuffer> to begin with as soon as the page loads. In Chrome and Safari, we don't even need the autobuffer, since they don't implement it. (Actually,<video autobuffer preload=auto> would be the current way to do it, given recent spec changes.)
I hope no one is ever insane enough to use this. Imagine those people with cellphones and no data transfer flat (~70% of mobile internet users) - their bills will skyrocket when even a single video is set to auto-preload.
Marco
Hopefully browsers on phones and low-bandwidth devices could just ignore this attribute.
- Trevor
On Wed, Mar 17, 2010 at 9:11 PM, Trevor Parscal tparscal@wikimedia.org wrote:
On 3/17/10 1:02 PM, Marco Schuster wrote:
On Wed, Mar 17, 2010 at 5:37 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Wed, Mar 17, 2010 at 10:39 AM, PlatonidesPlatonides@gmail.com wrote:
Would it help adding a<link rel="prefetch"> to the first video in the page?
In Firefox, yes. Does anyone else implement that? If it's only Firefox, we could just as well replace Cortado with<video autobuffer> to begin with as soon as the page loads. In Chrome and Safari, we don't even need the autobuffer, since they don't implement it. (Actually,<video autobuffer preload=auto> would be the current way to do it, given recent spec changes.)
I hope no one is ever insane enough to use this. Imagine those people with cellphones and no data transfer flat (~70% of mobile internet users) - their bills will skyrocket when even a single video is set to auto-preload.
Marco
Hopefully browsers on phones and low-bandwidth devices could just ignore this attribute.
What about people who use tethering? A browser can't determine if he connects via a flatrate connection (DSL, company network) or via tethering and a mobile connection.
Marco
On Wed, Mar 17, 2010 at 4:02 PM, Marco Schuster marco@harddisk.is-a-geek.org wrote:
I hope no one is ever insane enough to use this. Imagine those people with cellphones and no data transfer flat (~70% of mobile internet users) - their bills will skyrocket when even a single video is set to auto-preload.
On Wed, Mar 17, 2010 at 4:40 PM, Marco Schuster marco@harddisk.is-a-geek.org wrote:
What about people who use tethering? A browser can't determine if he connects via a flatrate connection (DSL, company network) or via tethering and a mobile connection.
The attribute is a hint, which user agents can respect or ignore as they choose. Mobile user agents will probably buffer much more conservatively than desktop UAs -- that's up to them. Other users who don't like auto-buffering might be able to turn it off in their browser options, or switch to a browser that allows them to do that (as with any other feature they want). Or use a browser that doesn't autobuffer at all by default.
On top of that, browsers can feel free to autobuffer only the first few seconds, up to the point where they think they can play through the whole video -- not the whole thing. Ten seconds of video now and again is not going to exhaust anyone's bandwidth budget.
In real life, the vast majority of people who aren't using cell phones aren't going to use up any bandwidth limit they might have by occasional video downloads, even downloading the whole thing. They would prefer faster video startup via autobuffering (if they're likely to play the video). This is evidenced by the fact that video sites actually do this -- if users were harmed more than helped by autobuffering (or thought they were), popular video sites would avoid it. We should use it for the same reason, wherever we think the user is likely to watch the video -- e.g., on the video page itself.
The fact that one can imagine a small minority of users who might hypothetically be harmed by autobuffering does not mean that it's insane.
2010/3/16 Lars Aronsson lars@aronsson.se:
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?
There's a difference between an OGG not playing on your browser and an OpenOffice file really being a .jar with malicious Java code. It's not so much about stuff exploding in the user's face as it is about stuff compromising the user's security.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org