Mailing List Archive

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.


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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

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


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

On Sun, Jun 7, 2009 at 8:26 AM, David Gerard<dgerard@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

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Sun, Jun 7, 2009 at 12:00 PM, Robert Rohde<rarohde@gmail.com> wrote:
> On Sun, Jun 7, 2009 at 8:26 AM, David Gerard<dgerard@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

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

2009/6/7 Robert Rohde <rarohde@gmail.com>:
> On Sun, Jun 7, 2009 at 12:00 PM, Robert Rohde<rarohde@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.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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 Gerard<dgerard@gmail.com> wrote:
> 2009/6/7 Brian <Brian.Mingus@colorado.edu>:
>
>> 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).
>
>
> 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

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 Gerard<dgerard@gmail.com> wrote:
> > 2009/6/7 Brian <Brian.Mingus@colorado.edu>:
> >
> >> 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).
> >
> >
> > 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
>
_______________________________________________
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.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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


_______________________________________________
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 Gerard<dgerard@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.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[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.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Sun, Jun 7, 2009 at 17:26, David Gerard<dgerard@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.

--
byte-byte,
grin

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

2009/6/8 Peter Gervai <grin@grin.hu>:
> On Sun, Jun 7, 2009 at 17:26, David Gerard<dgerard@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.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Mon, Jun 8, 2009 at 14:54, David Gerard<dgerard@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

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Peter Gervai wrote:
> On Sun, Jun 7, 2009 at 17:26, David Gerard<dgerard@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

On Mon, Jun 8, 2009 at 16:06, Tim Starling<tstarling@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.

--
byte-byte,
grin

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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 Gerard<dgerard@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

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 Gerard<dgerard@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

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 Gerard<dgerard@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
>


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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

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
>
_______________________________________________
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
>
>


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l