2011/6/3 Jon Harald Søby jhsoby@gmail.com:
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.
On Fri, Jun 3, 2011 at 5:24 PM, Aryeh Gregor Simetrical+wikilist@gmail.com 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?
On Fri, Jun 3, 2011 at 6:24 PM, Aryeh Gregor Simetrical+wikilist@gmail.comwrote:
2011/6/3 Jon Harald Søby jhsoby@gmail.com:
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 foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
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-bounces@lists.wikimedia.org [wikitech-l-bounces@lists.wikimedia.org] on behalf of aude [aude.wiki@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
(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@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, 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
Comments inline:
On Fri, Jun 3, 2011 at 4:51 PM, Brion Vibber brion@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@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
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 mdale@wikimedia.org
Comments inline:
On Fri, Jun 3, 2011 at 4:51 PM, Brion Vibber brion@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@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 4 June 2011 17:47, Michael Dale mdale@wikimedia.org wrote:
On Fri, Jun 3, 2011 at 4:51 PM, Brion Vibber brion@pobox.com 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.
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@lists.wikimedia.org