I am definitely not opposed to adding in that functionality as I have
mentioned in the past:
see thread:
http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg00888.html
You should take a look at the work Mike Baynton did back in summer of
code 07.
The issue that we have is both the Bottlenecks you mentioned. Where
possible we want to crowd source the transcoding costs and we have a
working firefogg support which we can more aggressively push out once
firefox 3.5 lands.
Essentially wikimedia commons is not designed to support hosting the raw
footage. Other like-minded organizations like archive.org that have
peta-bytes of storage across thousands of storage nodes are better
positioned to act as a host for raw footage and its derivatives.
Additional commons is a "strict" archive where files not licensed
properly often get removed where archive.org can act as a more permanent
storage space while license issues are sorted out.
Since wikimedia projects will shortly be supporting linline searching
time segment grabbing from archive.org material its maybe not so
critical that we create and host the transcoding infrastructure ourselves.
Although as you mention it would be nice to support transocoding on
wikimedias servers for uploading short clips from cell-phone type cases.
--michael
David Gerard wrote:
> [cc'd back to wikitech-l]
>
> 2009/6/8 Tim Starling <tstarling@wikimedia.org>:
>
>
>> It's been discussed since OggHandler was invented in 2007, and I've
>> always been in favour of it. But the code hasn't materialised, despite
>> a Google Summer of Code project come and gone that was meant to
>> implement a transcoding queue. The transcoding queue project was meant
>> to allow transformations in quality and size, but it would also allow
>> format changes without much trouble.
>>
>
>
> Ahhh, that's fantastic, so it is just a Simple Matter of Programming :-D
>
> (I'm tempted to bodge something together myself, despite my low
> opinion of my own coding abilities ;-) )
>
> Start simple. "Upload your phone and camera video files! We'll
> transcode them into Theora and store them." Pick suitable (tweakable)
> defaults. Get it doing that one job. Then we can think about
> size/quality transformations later. Sound like a vague plan?
>
> Bottlenecks: 1. CPU to transcode with. 2. Disk space for queued video.
>
>
> - d.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
mentioned in the past:
see thread:
http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg00888.html
You should take a look at the work Mike Baynton did back in summer of
code 07.
The issue that we have is both the Bottlenecks you mentioned. Where
possible we want to crowd source the transcoding costs and we have a
working firefogg support which we can more aggressively push out once
firefox 3.5 lands.
Essentially wikimedia commons is not designed to support hosting the raw
footage. Other like-minded organizations like archive.org that have
peta-bytes of storage across thousands of storage nodes are better
positioned to act as a host for raw footage and its derivatives.
Additional commons is a "strict" archive where files not licensed
properly often get removed where archive.org can act as a more permanent
storage space while license issues are sorted out.
Since wikimedia projects will shortly be supporting linline searching
time segment grabbing from archive.org material its maybe not so
critical that we create and host the transcoding infrastructure ourselves.
Although as you mention it would be nice to support transocoding on
wikimedias servers for uploading short clips from cell-phone type cases.
--michael
David Gerard wrote:
> [cc'd back to wikitech-l]
>
> 2009/6/8 Tim Starling <tstarling@wikimedia.org>:
>
>
>> It's been discussed since OggHandler was invented in 2007, and I've
>> always been in favour of it. But the code hasn't materialised, despite
>> a Google Summer of Code project come and gone that was meant to
>> implement a transcoding queue. The transcoding queue project was meant
>> to allow transformations in quality and size, but it would also allow
>> format changes without much trouble.
>>
>
>
> Ahhh, that's fantastic, so it is just a Simple Matter of Programming :-D
>
> (I'm tempted to bodge something together myself, despite my low
> opinion of my own coding abilities ;-) )
>
> Start simple. "Upload your phone and camera video files! We'll
> transcode them into Theora and store them." Pick suitable (tweakable)
> defaults. Get it doing that one job. Then we can think about
> size/quality transformations later. Sound like a vague plan?
>
> Bottlenecks: 1. CPU to transcode with. 2. Disk space for queued video.
>
>
> - d.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l