Just curious as to the state of video ingestion in MediaWiki - I know we were planning to do something such that video users could upload whatever comes out of their phone or camera, and of course WebM was released two years ago and support in MediaWiki has apparently been waiting just on this.
So what's the state of play?
- d.
On Mon, Jun 18, 2012 at 2:32 PM, David Gerard dgerard@gmail.com wrote:
Just curious as to the state of video ingestion in MediaWiki - I know we were planning to do something such that video users could upload whatever comes out of their phone or camera, and of course WebM was released two years ago and support in MediaWiki has apparently been waiting just on this.
So what's the state of play?
Roughly: this is waiting on TimedMediaHandler extension to make it through sufficient review, testing, and deployment.
TimedMediaHandler replaces the inline player from our more limited OggHandler extension, and adds in transcoding abilities -- that's what you want for being able to take arbitrary input and get Ogg/WebM/whatever out "hands-off".
There are probably still things to fix in it, but it needs some actual WMF resources assigned to it for that to happen; Erik can probably shed more light on this.
<warning: patent politics question may lead to offtopic bikeshedding> Additionally there's the question of adding H.264 transcode *output*, which would let us serve video to mobile devices and to Safari and IE 9 without any custom codec or Java installations. As far as I know that's not a huge technical difficulty but still needs to be decided politically, either before or after an initial rollout of TMH. </warning>
-- brion
On 19 June 2012 00:30, Brion Vibber brion@pobox.com wrote:
<warning: patent politics question may lead to offtopic bikeshedding> Additionally there's the question of adding H.264 transcode *output*, which would let us serve video to mobile devices and to Safari and IE 9 without any custom codec or Java installations. As far as I know that's not a huge technical difficulty but still needs to be decided politically, either before or after an initial rollout of TMH.
</warning>
It's entirely unclear to me that this is intrinsically related. Just because we can doesn't say anything about whether we should. e.g. we could easily allow H.264 uploads now, but we don't.
- d.
On Mon, Jun 18, 2012 at 4:44 PM, David Gerard dgerard@gmail.com wrote:
On 19 June 2012 00:30, Brion Vibber brion@pobox.com wrote:
<warning: patent politics question may lead to offtopic bikeshedding> Additionally there's the question of adding H.264 transcode *output*,
which
would let us serve video to mobile devices and to Safari and IE 9 without any custom codec or Java installations. As far as I know that's not a
huge
technical difficulty but still needs to be decided politically, either before or after an initial rollout of TMH.
</warning>
It's entirely unclear to me that this is intrinsically related.
They're intrinsically related because one depends on the other to be possible. This is a one-way dependency: H.264 output depends on TimedMediaHandler support. TimedMediaHandler in general doesn't depend on H.264 output, and should not be confused with it.
-- brion
On 06/18/2012 04:52 PM, Brion Vibber wrote:
On Mon, Jun 18, 2012 at 4:44 PM, David Gerard dgerard@gmail.com wrote:
On 19 June 2012 00:30, Brion Vibber brion@pobox.com wrote:
<warning: patent politics question may lead to offtopic bikeshedding> Additionally there's the question of adding H.264 transcode *output*,
which
would let us serve video to mobile devices and to Safari and IE 9 without any custom codec or Java installations. As far as I know that's not a
huge
technical difficulty but still needs to be decided politically, either before or after an initial rollout of TMH.
</warning>
It's entirely unclear to me that this is intrinsically related.
They're intrinsically related because one depends on the other to be possible. This is a one-way dependency: H.264 output depends on TimedMediaHandler support. TimedMediaHandler in general doesn't depend on H.264 output, and should not be confused with it.
-- brion
I think what we should do here is go ahead and add support for ingestion and output and then we can just adjust the settings file based on what we /decide politically/ do going forward.
Since both the deployment review pipeline as well as the political decision pipeline can be ~quite long~ probably best to have it all supported so we can just adjust a configuration file once we decide one way or another.
--michael
Since both the deployment review pipeline as well as the political decision
pipeline can be ~quite long~ probably best to have it all supported so we can just adjust a configuration file once we decide one way or another.
I agree with this idea. Not only does it make the political process of deciding what's best a little less painful (because it supports everything), but it also allows non-WMF projects to make the decision for themselves. By including not only the features needed by WMF projects we don't limit third parties, which although not 100% necessary, it's a nice boon.
Thank you, Derric Atzrott Computer Specialist Alizee Pathology
On 19 June 2012 21:19, Derric Atzrott datzrott@alizeepathology.com wrote:
Since both the deployment review pipeline as well as the political decision
pipeline can be ~quite long~ probably best to have it all supported so we can just adjust a configuration file once we decide one way or another.
I agree with this idea. Not only does it make the political process of deciding what's best a little less painful (because it supports everything), but it also allows non-WMF projects to make the decision for themselves. By including not only the features needed by WMF projects we don't limit third parties, which although not 100% necessary, it's a nice boon.
Hmm, yes. I concur.
- d.
semi-offtopic comment:
ffmpeg is awesome, somebody should send a cake to these people, or something.
*sends love his way*
wikitech-l@lists.wikimedia.org