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

2011-06-03 Thread Aryeh Gregor
2011/6/3 Jon Harald Søby :
> The only reason I can see for not allowing embedding is that
> embedding would be promoting YouTube

Embedding YouTube videos in Wikimedia content would send IP addresses
and other information about Wikimedia users to Google.  This is
against Wikimedia's privacy policy, as I understand it, and it would
certainly upset a lot of people.  I think it's extremely unlikely to
happen.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

2011-06-03 Thread OQ
On Fri, Jun 3, 2011 at 5:24 PM, Aryeh Gregor
 wrote:
> Embedding YouTube videos in Wikimedia content would send IP addresses
> and other information about Wikimedia users to Google.  This is
> against Wikimedia's privacy policy, as I understand it, and it would
> certainly upset a lot of people.  I think it's extremely unlikely to
> happen.

If it's disabled by default, and users must click something to
actually display/load the video container how would it be any
different then how we allow external links?

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

2011-06-03 Thread aude
On Fri, Jun 3, 2011 at 6:24 PM, Aryeh Gregor
wrote:

> 2011/6/3 Jon Harald Søby :
> > The only reason I can see for not allowing embedding is that
> > embedding would be promoting YouTube
>
> Embedding YouTube videos in Wikimedia content would send IP addresses
> and other information about Wikimedia users to Google.  This is
> against Wikimedia's privacy policy, as I understand it, and it would
> certainly upset a lot of people.  I think it's extremely unlikely to
> happen.
>

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, but the big hindrance
is the 100 MB upload limit on Commons.  What are the plans (if any) to
increase this? or help facilitate us (e.g. via the api, from the toolserver,
...) in uploading video and files that exceed the limit?

Cheers,
Katie





>
> ___
> foundation-l mailing list
> foundatio...@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


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

2011-06-03 Thread Brion Vibber
(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  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, but the big hindrance
> is the 100 MB upload limit on Commons.  What are the plans (if any) to
> increase this? or help facilitate us (e.g. via the api, from the
> toolserver,
> ...) in uploading video and files that exceed the limit?
>

There's been some ongoing work on TimedMediaHandler extension which will
replace the older OggHandler (this provides the nicer video player we've got
hacked in on Commons, and some automatic transcoding for different
resolutions in the free Theora & WebM formats). This still needs a little
more work, and probably some improvements on the actual transcoding
management and such, but this will help a bit in supporting larger files (eg
by transcoding high-res files to lower-res they're more easily viewable).
This isn't ready to go just yet though, and there's still the issue of
actually uploading the files.

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.

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.

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


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

2011-06-03 Thread Russell N. Nelson - rnnelson
SwiftMedia might be a key piece in the puzzle. It should scale well beyond a 
petabyte. Of course, first we have to get it working and serving up the first 
12GB (thumbs + originals). Getting very close ...
-russ

From: wikitech-l-boun...@lists.wikimedia.org 
[wikitech-l-boun...@lists.wikimedia.org] on behalf of aude [aude.w...@gmail.com]
Sent: Friday, June 03, 2011 7:42 PM
To: Wikimedia Foundation Mailing List
Cc: wikitech-l@lists.wikimedia.org
Subject: Re: [Wikitech-l] [Foundation-l] YouTube and Creative Commons

A youtube2commons script is pretty easy to implement, but the big hindrance
is the 100 MB upload limit on Commons.  What are the plans (if any) to
increase this? or help facilitate us (e.g. via the api, from the toolserver,
...) in uploading video and files that exceed the limit?

Cheers,
Katie

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


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

2011-06-04 Thread Michael Dale
Comments inline:

On Fri, Jun 3, 2011 at 4:51 PM, Brion Vibber  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  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/56.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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


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

2011-06-04 Thread emijrp
A nice script to download YouTube videos is youtube-dl[1]. Link that with a
flv/mp4 -> ogg converter and an uploader to Commons is trivial.

[1] http://rg3.github.com/youtube-dl/

2011/6/4 Michael Dale 

> Comments inline:
>
> On Fri, Jun 3, 2011 at 4:51 PM, Brion Vibber  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  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/56.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
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


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

2011-06-04 Thread David Gerard
On 4 June 2011 17:47, Michael Dale  wrote:
> On Fri, Jun 3, 2011 at 4:51 PM, Brion Vibber  wrote:

>> 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 :)


A question that wasn't clear from reading the bug: why is reading a
file format (WebM) blocked on the entire Timed Media Handler?


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


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

2011-06-07 Thread Michael Dale
On 06/04/2011 06:43 PM, David Gerard wrote:
> A question that wasn't clear from reading the bug: why is reading a
> file format (WebM) blocked on the entire Timed Media Handler?

It would be complicated to support WebM without an improved player and
transcoding support. All the IE users for example can only decode ogg
with cortado, if we don't use TMH WebM files when embed in articles
would not play for those users. Likewise older versions of firefox only
playback ogg.  Additionally, issues around HD files embedded into
articles is already an issue with users uploading variable bit-rate HD
oggs, giving a far from ideal experience on most Internet connections
and most in-browser playback engines. This would be an issue for
variable bitrate webm files as well ( without the transcoding support of
TMH )

Other features that have been living in the mwEmbed gadget for a long
time like timed text, remote embedding / video sharing, and temporal
media references / embeds are all better supported in TMH as an
extension, so we would be good to move those features over.

--michael

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l