It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis. It would greatly add to how much stuff we get, as it would save the user the trouble of re-encoding, or installing Firefogg, or whatever.
So why don't we do this? Has it been officially assessed as a legal risk * (and I mean more than people saying it might be on a mailing list **), has no-one really bothered, or what?
* until the Supreme Court uses in re Bilski to drive the software patents into the ocean, cross fingers. ** though I fully expect people will now do so anyway
- d.
David Gerard wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis. It would greatly add to how much stuff we get, as it would save the user the trouble of re-encoding, or installing Firefogg, or whatever.
So why don't we do this? Has it been officially assessed as a legal risk * (and I mean more than people saying it might be on a mailing list **), has no-one really bothered, or what?
- until the Supreme Court uses in re Bilski to drive the software
patents into the ocean, cross fingers. ** though I fully expect people will now do so anyway
- d.
Isn't Firefogg good enough? That's the solution being developed.
IANAL but I have heard concerns that there would be problems if the reencoding is done server side instead of at the client.
2009/6/7 Platonides Platonides@gmail.com:
David Gerard wrote:
Isn't Firefogg good enough? That's the solution being developed.
Installing software is an extra step for the user, therefore bad.
** though I fully expect people will now do so anyway
IANAL but
See, told you!
Does anyone have an informed, official opinion on this matter?
- d.
How many people at WMF consider their opinion's to be "official" ? :)
I think there are two issues for a proprietary -> non-proprietary converter:
1. The conversion software itself must be FLOSS. 2. The format being converted must have an open specification (Flash being a good example of one that might be allowed to be converted).
On Sun, Jun 7, 2009 at 10:41 AM, David Gerard dgerard@gmail.com wrote:
2009/6/7 Platonides Platonides@gmail.com:
David Gerard wrote:
Isn't Firefogg good enough? That's the solution being developed.
Installing software is an extra step for the user, therefore bad.
** though I fully expect people will now do so anyway
IANAL but
See, told you!
Does anyone have an informed, official opinion on this matter?
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
2009/6/7 Brian Brian.Mingus@colorado.edu:
I think there are two issues for a proprietary -> non-proprietary converter:
- The conversion software itself must be FLOSS.
- The format being converted must have an open specification (Flash being a
good example of one that might be allowed to be converted).
The first is easy: ffmpeg. It converts pretty much anything to pretty much anything. This is what I mean when I say that the technical side of such a thing would verge on the trivial. (Modulo a sufficiently CPU-endowed box for transcoding.)
The second - if ffmpeg have worked out the format, it's hardly any sort of secret any more.
I think it's something that would be worth doing to get more educational material into free formats and in a repository (Commons) that could spread them to the world, even if they did start in an encumbered format.
- d.
We should do this (reencode all major formats to ogg). It would absolutely make more educational material available to commons.
We can make the service available at a reasonable rate now without worrying about what happens when thousands of uploaders use it every day, and deal with issues as they arise. As for legal concerns, Dailymotion is managing bulk conversion just fine. We can ask them if they have to jump through any hoops.
SJ
On Sun, Jun 7, 2009 at 1:25 PM, David Gerarddgerard@gmail.com wrote:
2009/6/7 Brian Brian.Mingus@colorado.edu:
I think there are two issues for a proprietary -> non-proprietary converter:
- The conversion software itself must be FLOSS.
- The format being converted must have an open specification (Flash being a
good example of one that might be allowed to be converted).
The first is easy: ffmpeg. It converts pretty much anything to pretty much anything. This is what I mean when I say that the technical side of such a thing would verge on the trivial. (Modulo a sufficiently CPU-endowed box for transcoding.)
The second - if ffmpeg have worked out the format, it's hardly any sort of secret any more.
I think it's something that would be worth doing to get more educational material into free formats and in a repository (Commons) that could spread them to the world, even if they did start in an encumbered format.
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Archive.org do this and I know the tech team at least have previously had meetings/discussions with them.
Regards
Mark
On Sun, Jun 7, 2009 at 11:02 PM, Samuel Klein meta.sj@gmail.com wrote:
We should do this (reencode all major formats to ogg). It would absolutely make more educational material available to commons.
We can make the service available at a reasonable rate now without worrying about what happens when thousands of uploaders use it every day, and deal with issues as they arise. As for legal concerns, Dailymotion is managing bulk conversion just fine. We can ask them if they have to jump through any hoops.
SJ
On Sun, Jun 7, 2009 at 1:25 PM, David Gerarddgerard@gmail.com wrote:
2009/6/7 Brian Brian.Mingus@colorado.edu:
I think there are two issues for a proprietary -> non-proprietary
converter:
- The conversion software itself must be FLOSS.
- The format being converted must have an open specification (Flash
being a
good example of one that might be allowed to be converted).
The first is easy: ffmpeg. It converts pretty much anything to pretty much anything. This is what I mean when I say that the technical side of such a thing would verge on the trivial. (Modulo a sufficiently CPU-endowed box for transcoding.)
The second - if ffmpeg have worked out the format, it's hardly any sort of secret any more.
I think it's something that would be worth doing to get more educational material into free formats and in a repository (Commons) that could spread them to the world, even if they did start in an encumbered format.
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
2009/6/7 Mark (Markie) newsmarkie@googlemail.com:
Archive.org do this and I know the tech team at least have previously had meetings/discussions with them.
Archive.org is of course a charity too. Does anyone know the arrangement allowing them to do this?
- d.
On Sun, Jun 7, 2009 at 8:26 AM, David Gerarddgerard@gmail.com wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis. It would greatly add to how much stuff we get, as it would save the user the trouble of re-encoding, or installing Firefogg, or whatever.
So why don't we do this? Has it been officially assessed as a legal risk * (and I mean more than people saying it might be on a mailing list **), has no-one really bothered, or what?
Patent encumbered formats often have licensing fees when you perform encoding / decoding at commercial scale. For example, the MPEG licensing association expects a fee from anyone distributing more than 100,000 MPEG encoded files per year, and those fees can run hundreds of thousands of dollars. The WMF has a big enough budget that they could probably consider paying such fees (and enough clout they might negotiate a better than average rate), but even so it is still likely that paying the MPEG tax would require forgoing one or more staff hires. It's not inconceivable, but such projects would require looking carefully at the trade-offs involved, and I think in many cases avoiding proprietary formats makes sense.
That said, in my ideal fantasy world the educational value of the free encyclopedia would be maximized by accepting all mainstream formats, performing automatic conversions and providing users with any mainstream format of their choice in return. But such thinking seems to be pie in the sky at the moment.
-Robert Rohde
On Sun, Jun 7, 2009 at 12:00 PM, Robert Rohderarohde@gmail.com wrote:
On Sun, Jun 7, 2009 at 8:26 AM, David Gerarddgerard@gmail.com wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis. It would greatly add to how much stuff we get, as it would save the user the trouble of re-encoding, or installing Firefogg, or whatever.
So why don't we do this? Has it been officially assessed as a legal risk * (and I mean more than people saying it might be on a mailing list **), has no-one really bothered, or what?
Patent encumbered formats often have licensing fees when you perform encoding / decoding at commercial scale. Â For example, the MPEG licensing association expects a fee from anyone distributing more than 100,000 MPEG encoded files per year, and those fees can run hundreds of thousands of dollars. Â The WMF has a big enough budget that they could probably consider paying such fees (and enough clout they might negotiate a better than average rate), but even so it is still likely that paying the MPEG tax would require forgoing one or more staff hires. Â It's not inconceivable, but such projects would require looking carefully at the trade-offs involved, and I think in many cases avoiding proprietary formats makes sense.
Just to be clear, there are potential fees along all the food chain, i.e. encoding, decoding, and distribution. I picked on distribution because it was the one I knew off-hand. Since David is talking about decoding and re-encoding as Ogg, there would be a different set of fees to consider which I haven't looked at.
-Robert Rohde
2009/6/7 Robert Rohde rarohde@gmail.com:
On Sun, Jun 7, 2009 at 12:00 PM, Robert Rohderarohde@gmail.com wrote:
Patent encumbered formats often have licensing fees when you perform encoding / decoding at commercial scale. Â For example, the MPEG licensing association expects a fee from anyone distributing more than 100,000 MPEG encoded files per year, and those fees can run hundreds of thousands of dollars. Â The WMF has a big enough budget that they could probably consider paying such fees (and enough clout they might negotiate a better than average rate), but even so it is still likely that paying the MPEG tax would require forgoing one or more staff hires. Â It's not inconceivable, but such projects would require looking carefully at the trade-offs involved, and I think in many cases avoiding proprietary formats makes sense.
Just to be clear, there are potential fees along all the food chain, i.e. encoding, decoding, and distribution. Â I picked on distribution because it was the one I knew off-hand. Â Since David is talking about decoding and re-encoding as Ogg, there would be a different set of fees to consider which I haven't looked at.
I suppose we wait for the Supreme Court to make everything wonderful, then ...
- d.
David Gerard wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis. It would greatly add to how much stuff we get, as it would save the user the trouble of re-encoding, or installing Firefogg, or whatever.
So why don't we do this? Has it been officially assessed as a legal risk * (and I mean more than people saying it might be on a mailing list **), has no-one really bothered, or what?
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.
Personally, I think we should do whatever we need to do to be able to transcode popular video formats, even if that means paying license fees. Others in the organisation might not have the same view, but I'm sure there's space for compromise.
I did a brief review of both MPEG LA and Windows Media license terms a few months ago. Both seemed to exclude web-based content providers from the need to pay patent licensing fees. If we bought commercial transcoding software, there might be a small patent fee embedded in the price, but there's no scheme in place to allow users to pay for FFmpeg. MPEG LA only deals with software distributors, not software users.
Some people in the community take the view that supporting proprietary standards, as an option alongside free standards, weakens the ability of the free standards to compete for mindshare and client support, and thus that it shouldn't be done. We would have to have that discussion, and possibly a vote on the issue, before deployment of any software solution. But the software should come first, at the very least it will be useful to support alternate free formats such as Dirac, Speex and FLAC.
-- Tim Starling
[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.
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
I presume the WMF has a large amount of free disk space. How much?
On Mon, Jun 8, 2009 at 2:28 PM, Michael Dale mdale@wikimedia.org wrote:
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
2009/6/8 Brian Brian.Mingus@colorado.edu:
I presume the WMF has a large amount of free disk space. How much?
Hard drives are cheap, the WMF can just buy more if that is all that is needed.
I don't think that's all that's needed. There will be Wikimedians scouring the Internet for all free video in all of its forms (of which there is quite a lot) and uploading it to Commons. You'll need an entire encoding farm. Hard drives are cheap, its true, but redundant storage is less cheap as a function of reliability.
On Mon, Jun 8, 2009 at 3:17 PM, Thomas Dalton thomas.dalton@gmail.comwrote:
2009/6/8 Brian Brian.Mingus@colorado.edu:
I presume the WMF has a large amount of free disk space. How much?
Hard drives are cheap, the WMF can just buy more if that is all that is needed.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
2009/6/8 Brian Brian.Mingus@colorado.edu:
I don't think that's all that's needed. There will be Wikimedians scouring the Internet for all free video in all of its forms (of which there is quite a lot) and uploading it to Commons. You'll need an entire encoding farm. Hard drives are cheap, its true, but redundant storage is less cheap as a function of reliability.
Yes, that's true - easily re-encoding proprietary formats to an Ogg on Commonsn will lead to people loading Commons with lovely video.
Mind you, the Wikimedians could do that with Firefogg.
OTOH, hands up all those who have FF 3.5? (raises hand) And who's installed Firefogg? (puts hand down)
- d.
Tim Starling wrote:
Some people in the community take the view that supporting proprietary standards, as an option alongside free standards, weakens the ability of the free standards to compete for mindshare and client support, and thus that it shouldn't be done. We would have to have that discussion, and possibly a vote on the issue, before deployment of any software solution. But the software should come first, at the very least it will be useful to support alternate free formats such as Dirac, Speex and FLAC.
I don't know who "Some people in the community" are, but just in case they are anything like myself, who does hold a view not entirely distant from the one you describe...
The one thing I would say is that gettin unencumbered material that was only encumbered by the encoding it was being carried by to formats that are free, is a net plus, no matter if it meant we were also carrying the encumbered format version.
Yours in deep amity;
Jussi-Ville Heiskanen
I hold the same sort of pragmatic view. In the absence of freely licensed content encoded in a free format we should accept free content in any format. I think it would take a revolution within the Foundation staff and the most vocal parts of the community (note that I did not say majority), though. It seems like a lot less work to solve the recoding problem, and anyway, there is a lot of content that has yet to be produced to worry about. Sticking to the ideals no matter what will help more of that free content in free formats be produced in the future when there are more people around to do the creating.
On Mon, Jun 8, 2009 at 10:17 PM, Jussi-Ville Heiskanen <cimonavaro@gmail.com
wrote:
Tim Starling wrote:
Some people in the community take the view that supporting proprietary standards, as an option alongside free standards, weakens the ability of the free standards to compete for mindshare and client support, and thus that it shouldn't be done. We would have to have that discussion, and possibly a vote on the issue, before deployment of any software solution. But the software should come first, at the very least it will be useful to support alternate free formats such as Dirac, Speex and FLAC.
I don't know who "Some people in the community" are, but just in case they are anything like myself, who does hold a view not entirely distant from the one you describe...
The one thing I would say is that gettin unencumbered material that was only encumbered by the encoding it was being carried by to formats that are free, is a net plus, no matter if it meant we were also carrying the encumbered format version.
Yours in deep amity;
Jussi-Ville Heiskanen
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Brian wrote:
I hold the same sort of pragmatic view. In the absence of freely licensed content encoded in a free format we should accept free content in any format. I think it would take a revolution within the Foundation staff and the most vocal parts of the community (note that I did not say majority), though.
I think this is the exact opposite of what I wished to convey.
I do not hold we should accept non-free content. I don't hold that view. Period.
But if there is content that is *only* encumbered by the encoding, we should embrace and liberate it from those bonds.
That is all.
It seems like a lot less work to solve the recoding problem, and anyway, there is a lot of content that has yet to be produced to worry about. Sticking to the ideals no matter what will help more of that free content in free formats be produced in the future when there are more people around to do the creating.
On Mon, Jun 8, 2009 at 10:17 PM, Jussi-Ville Heiskanen <cimonavaro@gmail.com
wrote:
Tim Starling wrote:
Some people in the community take the view that supporting proprietary standards, as an option alongside free standards, weakens the ability of the free standards to compete for mindshare and client support, and thus that it shouldn't be done. We would have to have that discussion, and possibly a vote on the issue, before deployment of any software solution. But the software should come first, at the very least it will be useful to support alternate free formats such as Dirac, Speex and FLAC.
I don't know who "Some people in the community" are, but just in case they are anything like myself, who does hold a view not entirely distant from the one you describe...
The one thing I would say is that gettin unencumbered material that was only encumbered by the encoding it was being carried by to formats that are free, is a net plus, no matter if it meant we were also carrying the encumbered format version.
Yours in deep amity;
Jussi-Ville Heiskanen
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Pretty sure we are saying the same thing - what part of my comment struck the wrong chord with you?
On Tue, Jun 9, 2009 at 12:18 AM, Jussi-Ville Heiskanen <cimonavaro@gmail.com
wrote:
Brian wrote:
I hold the same sort of pragmatic view. In the absence of freely licensed content encoded in a free format we should accept free content in any format. I think it would take a revolution within the Foundation staff
and
the most vocal parts of the community (note that I did not say majority), though.
I think this is the exact opposite of what I wished to convey.
I do not hold we should accept non-free content. I don't hold that view. Period.
But if there is content that is *only* encumbered by the encoding, we should embrace and liberate it from those bonds.
That is all.
It seems like a lot less work to solve the recoding problem, and anyway, there is a lot of content that has yet to be produced to worry about. Sticking to the ideals no matter what will help more of that free content in free formats be produced in the future when there are more people around to do the creating.
On Mon, Jun 8, 2009 at 10:17 PM, Jussi-Ville Heiskanen <
cimonavaro@gmail.com
wrote:
Tim Starling wrote:
Some people in the community take the view that supporting proprietary standards, as an option alongside free standards, weakens the ability of the free standards to compete for mindshare and client support, and thus that it shouldn't be done. We would have to have that discussion, and possibly a vote on the issue, before deployment of any software solution. But the software should come first, at the very least it will be useful to support alternate free formats such as Dirac, Speex and FLAC.
I don't know who "Some people in the community" are, but just in case they are anything like myself, who does hold a view not entirely distant from the one you describe...
The one thing I would say is that gettin unencumbered material that was only encumbered by the encoding it was being carried by to formats that are free, is a net plus, no matter if it meant we were also carrying the encumbered format version.
Yours in deep amity;
Jussi-Ville Heiskanen
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Brian wrote:
Pretty sure we are saying the same thing - what part of my comment struck the wrong chord with you?
I think it is the " we should accept free content in any format." bit. ;-)
On Tue, Jun 9, 2009 at 12:18 AM, Jussi-Ville Heiskanen <cimonavaro@gmail.com
wrote:
Brian wrote:
I hold the same sort of pragmatic view. In the absence of freely licensed content encoded in a free format we should accept free content in any format. I think it would take a revolution within the Foundation staff
and
the most vocal parts of the community (note that I did not say majority), though.
I think this is the exact opposite of what I wished to convey.
I do not hold we should accept non-free content. I don't hold that view. Period.
But if there is content that is *only* encumbered by the encoding, we should embrace and liberate it from those bonds.
That is all.
It seems like a lot less work to solve the recoding problem, and anyway, there is a lot of content that has yet to be produced to worry about. Sticking to the ideals no matter what will help more of that free content in free formats be produced in the future when there are more people around to do the creating.
On Mon, Jun 8, 2009 at 10:17 PM, Jussi-Ville Heiskanen <
cimonavaro@gmail.com
wrote:
Tim Starling wrote:
Some people in the community take the view that supporting proprietary standards, as an option alongside free standards, weakens the ability of the free standards to compete for mindshare and client support, and thus that it shouldn't be done. We would have to have that discussion, and possibly a vote on the issue, before deployment of any software solution. But the software should come first, at the very least it will be useful to support alternate free formats such as Dirac, Speex and FLAC.
I don't know who "Some people in the community" are, but just in case they are anything like myself, who does hold a view not entirely distant from the one you describe...
The one thing I would say is that gettin unencumbered material that was only encumbered by the encoding it was being carried by to formats that are free, is a net plus, no matter if it meant we were also carrying the encumbered format version.
Yours in deep amity;
Jussi-Ville Heiskanen
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
How is that different from: "[...] if there is content that is *only* encumbered by the encoding, we should embrace [...]"
On Tue, Jun 9, 2009 at 12:26 AM, Jussi-Ville Heiskanen <cimonavaro@gmail.com
wrote:
Brian wrote:
Pretty sure we are saying the same thing - what part of my comment struck the wrong chord with you?
I think it is the " we should accept free content in any format." bit. ;-)
On Tue, Jun 9, 2009 at 12:18 AM, Jussi-Ville Heiskanen <
cimonavaro@gmail.com
wrote:
Brian wrote:
I hold the same sort of pragmatic view. In the absence of freely
licensed
content encoded in a free format we should accept free content in any format. I think it would take a revolution within the Foundation staff
and
the most vocal parts of the community (note that I did not say
majority),
though.
I think this is the exact opposite of what I wished to convey.
I do not hold we should accept non-free content. I don't hold that view. Period.
But if there is content that is *only* encumbered by the encoding, we should embrace and liberate it from those bonds.
That is all.
It seems like a lot less work to solve the recoding problem, and anyway, there is a lot of content that has yet to be produced to worry about. Sticking to the ideals no matter what will help more of that free content in free formats be produced in the future when there are more people around to do the creating.
On Mon, Jun 8, 2009 at 10:17 PM, Jussi-Ville Heiskanen <
cimonavaro@gmail.com
wrote:
Tim Starling wrote:
Some people in the community take the view that supporting
proprietary
standards, as an option alongside free standards, weakens the ability of the free standards to compete for mindshare and client support,
and
thus that it shouldn't be done. We would have to have that
discussion,
and possibly a vote on the issue, before deployment of any software solution. But the software should come first, at the very least it will be useful to support alternate free formats such as Dirac, Speex and FLAC.
I don't know who "Some people in the community" are, but just in case they are anything like myself, who does hold a view not entirely distant from the one you describe...
The one thing I would say is that gettin unencumbered material that was only encumbered by the encoding it was being carried by to formats that are free, is a net plus, no matter if it meant we were also carrying the encumbered format version.
Yours in deep amity;
Jussi-Ville Heiskanen
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Brian wrote:
How is that different from: "[...] if there is content that is *only* encumbered by the encoding, we should embrace [...]"
You forgot the bit about liberating it.
On Tue, Jun 9, 2009 at 12:26 AM, Jussi-Ville Heiskanen <cimonavaro@gmail.com
wrote:
Brian wrote:
Pretty sure we are saying the same thing - what part of my comment struck the wrong chord with you?
I think it is the " we should accept free content in any format." bit. ;-)
On Tue, Jun 9, 2009 at 12:18 AM, Jussi-Ville Heiskanen <
cimonavaro@gmail.com
wrote:
Brian wrote:
I hold the same sort of pragmatic view. In the absence of freely
licensed
content encoded in a free format we should accept free content in any format. I think it would take a revolution within the Foundation staff
and
the most vocal parts of the community (note that I did not say
majority),
though.
I think this is the exact opposite of what I wished to convey.
I do not hold we should accept non-free content. I don't hold that view. Period.
But if there is content that is *only* encumbered by the encoding, we should embrace and liberate it from those bonds.
That is all.
It seems like a lot less work to solve the recoding problem, and anyway, there is a lot of content that has yet to be produced to worry about. Sticking to the ideals no matter what will help more of that free content in free formats be produced in the future when there are more people around to do the creating.
On Mon, Jun 8, 2009 at 10:17 PM, Jussi-Ville Heiskanen <
cimonavaro@gmail.com
wrote:
Tim Starling wrote:
> Some people in the community take the view that supporting >
proprietary
> standards, as an option alongside free standards, weakens the ability > of the free standards to compete for mindshare and client support, >
and
> thus that it shouldn't be done. We would have to have that >
discussion,
> and possibly a vote on the issue, before deployment of any software > solution. But the software should come first, at the very least it > will be useful to support alternate free formats such as Dirac, Speex > and FLAC. > > > > I don't know who "Some people in the community" are, but just in case they are anything like myself, who does hold a view not entirely distant from the one you describe...
The one thing I would say is that gettin unencumbered material that was only encumbered by the encoding it was being carried by to formats that are free, is a net plus, no matter if it meant we were also carrying the encumbered format version.
Yours in deep amity;
Jussi-Ville Heiskanen
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Yes, but you also said: "The one thing I would say is that gettin unencumbered material that was only encumbered by the encoding it was being carried by to formats that are free, is a net plus, no matter if it meant we were also carrying the encumbered format version."
I'm quite sure that the net sum of what you've said and i've said is equal.
On Tue, Jun 9, 2009 at 12:30 AM, Jussi-Ville Heiskanen <cimonavaro@gmail.com
wrote:
Brian wrote:
How is that different from: "[...] if there is content that is *only* encumbered by the encoding, we should embrace [...]"
You forgot the bit about liberating it.
On Tue, Jun 9, 2009 at 12:26 AM, Jussi-Ville Heiskanen <
cimonavaro@gmail.com
wrote:
Brian wrote:
Pretty sure we are saying the same thing - what part of my comment
struck
the wrong chord with you?
I think it is the " we should accept free content in any format." bit. ;-)
On Tue, Jun 9, 2009 at 12:18 AM, Jussi-Ville Heiskanen <
cimonavaro@gmail.com
wrote:
Brian wrote:
I hold the same sort of pragmatic view. In the absence of freely
licensed
content encoded in a free format we should accept free content in any format. I think it would take a revolution within the Foundation
staff
and
the most vocal parts of the community (note that I did not say
majority),
though.
I think this is the exact opposite of what I wished to convey.
I do not hold we should accept non-free content. I don't hold that view. Period.
But if there is content that is *only* encumbered by the encoding, we should embrace and liberate it from those bonds.
That is all.
It seems like a lot less work to solve the recoding problem, and anyway, there is a lot of content that has yet to be produced to worry about. Sticking to the ideals no matter what will help more of that free content in free formats be produced in the future when there are more people around to do the creating.
On Mon, Jun 8, 2009 at 10:17 PM, Jussi-Ville Heiskanen <
cimonavaro@gmail.com
> wrote: > > > > Tim Starling wrote: > > > >> Some people in the community take the view that supporting >>
proprietary
>> standards, as an option alongside free standards, weakens the
ability
>> of the free standards to compete for mindshare and client support, >>
and
>> thus that it shouldn't be done. We would have to have that >>
discussion,
>> and possibly a vote on the issue, before deployment of any software >> solution. But the software should come first, at the very least it >> will be useful to support alternate free formats such as Dirac,
Speex
>> and FLAC. >> >> >> >> > I don't know who "Some people in the community" are, > but just in case they are anything like myself, who does > hold a view not entirely distant from the one you describe... > > The one thing I would say is that gettin unencumbered > material that was only encumbered by the encoding it was > being carried by to formats that are free, is a net plus, no > matter if it meant we were also carrying the encumbered > format version. > > > Yours in deep amity; > > Jussi-Ville Heiskanen > > _______________________________________________ > foundation-l mailing list > foundation-l@lists.wikimedia.org > Unsubscribe: >
https://lists.wikimedia.org/mailman/listinfo/foundation-l
> > _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Sun, Jun 7, 2009 at 5:26 PM, David Gerarddgerard@gmail.com wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis. It would greatly add to how much stuff we get, as it would save the user the trouble of re-encoding, or installing Firefogg, or whatever.
So why don't we do this? Has it been officially assessed as a legal risk * (and I mean more than people saying it might be on a mailing list **), has no-one really bothered, or what?
- until the Supreme Court uses in re Bilski to drive the software
patents into the ocean, cross fingers. ** though I fully expect people will now do so anyway
Another option is to treat Internet Archive as external source of media.
On Sun, Jun 7, 2009 at 17:26, David Gerarddgerard@gmail.com wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis.
As a technical sidenote, it should be mentioned that recoding a lossy format to another lossy format results _always_ a worse quality output than the source lossy format. The amount of quality loss depends on countless factors and usually do not render the result useless, but the quality difference may be still audible/visible.
2009/6/8 Peter Gervai grin@grin.hu:
On Sun, Jun 7, 2009 at 17:26, David Gerarddgerard@gmail.com wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis.
As a technical sidenote, it should be mentioned that recoding a lossy format to another lossy format results _always_ a worse quality output than the source lossy format. The amount of quality loss depends on countless factors and usually do not render the result useless, but the quality difference may be still audible/visible.
Well, yeah. But until cameras or phones start recording Ogg Theora natively, we're likely stuck with this.
- d.
On Mon, Jun 8, 2009 at 14:54, David Gerarddgerard@gmail.com wrote:
Well, yeah. But until cameras or phones start recording Ogg Theora natively, we're likely stuck with this.
As another tidbit, I have a music player ("mp3 player") which records and plays ogg (not Theora though). :-)
But you're right, most users haven't even heard about vorbis and theora. And phone recordings won't show any quality loss anyway since, well... erm...
g
Peter Gervai wrote:
On Sun, Jun 7, 2009 at 17:26, David Gerarddgerard@gmail.com wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis.
As a technical sidenote, it should be mentioned that recoding a lossy format to another lossy format results _always_ a worse quality output than the source lossy format. The amount of quality loss depends on countless factors and usually do not render the result useless, but the quality difference may be still audible/visible.
But if we can do resizing and quality conversion post-upload, then we can encourage users to upload their videos with the best possible quality, they won't be forced to upload at a quality suitable for web download. We can store the source video unconverted for archival purposes. When we reduce the quality of a video for a web user, the process will be under server control and can be incrementally improved, instead of using whatever outdated software the user has on their computer. So the net effect of the feature should be a significant improvement in video quality.
-- Tim Starling
On Mon, Jun 8, 2009 at 16:06, Tim Starlingtstarling@wikimedia.org wrote:
As a technical sidenote, it should be mentioned that recoding a lossy format to another lossy format results _always_ a worse quality output than the source lossy format. The amount of quality loss depends on countless factors and usually do not render the result useless, but the quality difference may be still audible/visible.
But if we can do resizing and quality conversion post-upload, then we can encourage users to upload their videos with the best possible quality, they won't be forced to upload at a quality suitable for web download. We can store the source video unconverted for archival purposes. When we reduce the quality of a video for a web user, the
Good in theory, but how many people are prepared to upload videos in original format? It is most of the time even uncompressed, like DV, and may add up to even a few gigabytes. (I don't remember, but I believe it was around a gigabyte per minute or so.)
And it requires an enermous amount of storage space too.
Still I may be completely wrong since I have never checked how long videos do we possess on average. And naturally this method (that we convert lossy from original excellnt quality masters) is the best, since then we control the output format and not the uploader.
We have done a good amount of work with archive.org to ensure that their archive is interpretable. I know from the present vantage point it does not seem helpful to have media on archive.org... but as features like the add_media_wizard get deployed it will make a lot more sense why it does not matter so much where the source media is hosted.
In terms of source files... I think the problem is people don't necessarily have the bandwidth to upload their raw DV footage... If they do then we should also upload a copy to archive.org. Using firefogg its easy to add a js function call to also send a copy of the raw non-ogg encoded footage to archive.org all from within our commons upload interface.
Its of course always better to have the original. But I would argue (for the time being) we should store that original on archive.org rather than build out and maintain all the trannscoder & raw footage storage infrastructure internally. In the future if we do have time and or resources (volunteer or otherwise) to support transocding on wikimedia commons... then thats great and we can support that too.
In terms of encoder updates: Firefogg lets us control the encoder via Firefox extension auto updates. Firefogg is already running the thusnelda encoder branch. In the future we can push out other free encoders (dirac speex etc). This makes it much easier for someone to build a collaborative video wiki since they don't need to build out transcoding infrastructure.
--michael
Tim Starling wrote:
Peter Gervai wrote:
On Sun, Jun 7, 2009 at 17:26, David Gerarddgerard@gmail.com wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis.
As a technical sidenote, it should be mentioned that recoding a lossy format to another lossy format results _always_ a worse quality output than the source lossy format. The amount of quality loss depends on countless factors and usually do not render the result useless, but the quality difference may be still audible/visible.
But if we can do resizing and quality conversion post-upload, then we can encourage users to upload their videos with the best possible quality, they won't be forced to upload at a quality suitable for web download. We can store the source video unconverted for archival purposes. When we reduce the quality of a video for a web user, the process will be under server control and can be incrementally improved, instead of using whatever outdated software the user has on their computer. So the net effect of the feature should be a significant improvement in video quality.
-- Tim Starling
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Firefogg is not a very usable solution for most users. It requires far too much sophistication. Users should be able to just upload video that they know is under a free license and then everything else happens on the backend.
On Mon, Jun 8, 2009 at 3:57 PM, Michael Dale mdale@wikimedia.org wrote:
We have done a good amount of work with archive.org to ensure that their archive is interpretable. I know from the present vantage point it does not seem helpful to have media on archive.org... but as features like the add_media_wizard get deployed it will make a lot more sense why it does not matter so much where the source media is hosted.
In terms of source files... I think the problem is people don't necessarily have the bandwidth to upload their raw DV footage... If they do then we should also upload a copy to archive.org. Using firefogg its easy to add a js function call to also send a copy of the raw non-ogg encoded footage to archive.org all from within our commons upload interface.
Its of course always better to have the original. But I would argue (for the time being) we should store that original on archive.org rather than build out and maintain all the trannscoder & raw footage storage infrastructure internally. In the future if we do have time and or resources (volunteer or otherwise) to support transocding on wikimedia commons... then thats great and we can support that too.
In terms of encoder updates: Firefogg lets us control the encoder via Firefox extension auto updates. Firefogg is already running the thusnelda encoder branch. In the future we can push out other free encoders (dirac speex etc). This makes it much easier for someone to build a collaborative video wiki since they don't need to build out transcoding infrastructure.
--michael
Tim Starling wrote:
Peter Gervai wrote:
On Sun, Jun 7, 2009 at 17:26, David Gerarddgerard@gmail.com wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis.
As a technical sidenote, it should be mentioned that recoding a lossy format to another lossy format results _always_ a worse quality output than the source lossy format. The amount of quality loss depends on countless factors and usually do not render the result useless, but the quality difference may be still audible/visible.
But if we can do resizing and quality conversion post-upload, then we can encourage users to upload their videos with the best possible quality, they won't be forced to upload at a quality suitable for web download. We can store the source video unconverted for archival purposes. When we reduce the quality of a video for a web user, the process will be under server control and can be incrementally improved, instead of using whatever outdated software the user has on their computer. So the net effect of the feature should be a significant improvement in video quality.
-- Tim Starling
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
hmm.. it will be a one-two click install directly from the upload page. (if the user is using Firefox). Then it works exactly the same as the existing upload interface only it transcodes the video as it uploads....
Yea it would be good to support both; and yes we should simplify upload work-flow.
--michael
Brian wrote:
Firefogg is not a very usable solution for most users. It requires far too much sophistication. Users should be able to just upload video that they know is under a free license and then everything else happens on the backend.
On Mon, Jun 8, 2009 at 3:57 PM, Michael Dale mdale@wikimedia.org wrote:
We have done a good amount of work with archive.org to ensure that their archive is interpretable. I know from the present vantage point it does not seem helpful to have media on archive.org... but as features like the add_media_wizard get deployed it will make a lot more sense why it does not matter so much where the source media is hosted.
In terms of source files... I think the problem is people don't necessarily have the bandwidth to upload their raw DV footage... If they do then we should also upload a copy to archive.org. Using firefogg its easy to add a js function call to also send a copy of the raw non-ogg encoded footage to archive.org all from within our commons upload interface.
Its of course always better to have the original. But I would argue (for the time being) we should store that original on archive.org rather than build out and maintain all the trannscoder & raw footage storage infrastructure internally. In the future if we do have time and or resources (volunteer or otherwise) to support transocding on wikimedia commons... then thats great and we can support that too.
In terms of encoder updates: Firefogg lets us control the encoder via Firefox extension auto updates. Firefogg is already running the thusnelda encoder branch. In the future we can push out other free encoders (dirac speex etc). This makes it much easier for someone to build a collaborative video wiki since they don't need to build out transcoding infrastructure.
--michael
Tim Starling wrote:
Peter Gervai wrote:
On Sun, Jun 7, 2009 at 17:26, David Gerarddgerard@gmail.com wrote:
It would be a simple matter of programming to have something that allows upload of encumbered video and audio formats and re-encode them as Ogg Theora or Ogg Vorbis.
As a technical sidenote, it should be mentioned that recoding a lossy format to another lossy format results _always_ a worse quality output than the source lossy format. The amount of quality loss depends on countless factors and usually do not render the result useless, but the quality difference may be still audible/visible.
But if we can do resizing and quality conversion post-upload, then we can encourage users to upload their videos with the best possible quality, they won't be forced to upload at a quality suitable for web download. We can store the source video unconverted for archival purposes. When we reduce the quality of a video for a web user, the process will be under server control and can be incrementally improved, instead of using whatever outdated software the user has on their computer. So the net effect of the feature should be a significant improvement in video quality.
-- Tim Starling
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Michael Dale wrote:
hmm.. it will be a one-two click install directly from the upload page. (if the user is using Firefox). Then it works exactly the same as the existing upload interface only it transcodes the video as it uploads....
Yea it would be good to support both; and yes we should simplify upload work-flow.
--michael
For windows users with a different browser, we could provide a One-click install of Firefox with Firerfogg for easy upload (or perhaps with a more specific xulrunner interface). Not sure if it's also worth for Mac. It probably isn't for Linux.
wikimedia-l@lists.wikimedia.org