[Foundation-l] [Wikitech-l] YouTube and Creative Commons

Sat Jun 4 16:47:41 UTC 2011

Comments inline:

On Fri, Jun 3, 2011 at 4:51 PM, Brion Vibber <brion at pobox.com> wrote:

> (I'm not sure offhand if I'm set up to cross-post to Foundation-l; if this
> doesn't make it, somebody please CC a mention if necessary. Thanks!)
>
> On Fri, Jun 3, 2011 at 4:42 PM, aude <aude.wiki at gmail.com> wrote:
>
> > Aside from the very real privacy issue, YouTube videos can disappear at
> any
> > time.  I would much rather we host them on Commons.
> >
> > A youtube2commons script is pretty easy to implement,
>

yes a basic youtube2commons script was posted by Jan on wikivideo-l list
recently:
http://lists.wikimedia.org/pipermail/wikivideo-l/2011-May/000056.html But as
you point out we really need to work on increasing the upload size limit.

>
> There's been some ongoing work on TimedMediaHandler extension which will
> replace the older OggHandler
>

Yes, been hammering away on associated bugs. People can help by testing and
filing bugs :) thedj has helped file a lot of bugs, and Brion too recently
has been taking a look at the transcoding side of things and Roan did a good
first pass review and thous suggestions have since been integrated.  I hope
to have a new version up prototype soon that integrates all the known
requested features / bugs listed in bugzilla some time next week. (with the
exception of features tagged for version 1.1 like server side srt parsing
and timed wikitext -> html -> srt text with html tag removal )  Once I get
this update out to prototype I will try and do a blog post at that point to
invite people to put test it out.

> Basic uploads by URL work in theory, but I'm not sure the deployment
> status.
> Background large-file downloads are currently disabled in the latest code
> and needs to be reimplemented if that's to be used.
>

Yea we have bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=20512tracking
re-enabling copy by url. Once we have webm TMH deployed it would
make for simple youtube cc content with importing without conversion :)

>
> For straight uploads, regular uploads of large files are a bit problematic
> in general (they hit memory limits and such and have to make it through
> caching proxies and whatnot), but there's also been some new work on
> improved chunked uploads for FireFogg (and perhaps for general modern
> browsers that can do fancier uploads). Michael Dale can probably give some
> updates on this, but it'll be a bit yet before it's ready to go.
>

Yes we are reimplementing the firefogg chunk uploading as ResumableUpload (
name of new extension ) in a way that allows both HTML5 XHR browsers to use
the chunk protocol in addition to firefogg ( if your converting video from a
proprietary source ). In addition we had disscutions at the Berlin
Hack-a-ton that cleared up some confusion about the concerns with the
firefogg protocol and modified it to explicitly state the byte ranges of
chunks in requests and server responses. Also had a brief chat with Russell
on IRC, so that we can support this append chunks system as we move to the
swiftMedia back end.

--michael