Hi all, I am the main developer/maintainer of LiVES (http://lives.sourceforge.net).
I recently noticed the information about LiVES on this page: http://fedoraproject.org/wiki/PackageMaintainers/WishList#L-M
The information give about LiVES is inaccurate/incorrect. First of all, LiVES is not dependant on ffmpeg. As in, you can perfectly well build and run the application without ffmpeg being present on either the build system or the end user system.
However, the ffmpeg libraries are recommended for end users, since LiVES will make indirect use of them (via mplayer) for decoding some video formats, and via mencoder for encoding some video formats.
I fail to see the reason for this to be sufficient cause for crossing out LiVES. A long time ago, ffmpeg contained some allegedly patented code (AAC audio IIRC), however this code was removed from the core of ffmpeg at least 5 years ago. However it seems that the FUD (and that is indeed what it is) persists. Microsoft must be laughing hard at this one.
If you don't believe me, then how is it that both ffmpeg and LiVES are in debian testing and unstable ? Please check for yourselves, and contact the debian legal team if you are still in doubt.
It is particularly timely that I noticed this, as I would like to introduce the new packager for LiVES in Fedora, Harry Rickards (harry@linux.com). Harry is also the point of contact between LiVES and the debian multimedia team who are responsible for packaging LiVES for debian.
I hope that you will correct the information on the wishlist page, stop spreading (unintentional ?) FUD about ffmpeg, and most importantly give Harry every assistance with the Fedora LiVES packages.
Regards, Salsaman, main developer, LiVES.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Mon, May 31, 2010 at 05:34:34AM -0300, salsaman wrote:
Hi all, I am the main developer/maintainer of LiVES (http://lives.sourceforge.net).
I recently noticed the information about LiVES on this page: http://fedoraproject.org/wiki/PackageMaintainers/WishList#L-M
The information give about LiVES is inaccurate/incorrect. First of all, LiVES is not dependant on ffmpeg. As in, you can perfectly well build and run the application without ffmpeg being present on either the build system or the end user system.
However, the ffmpeg libraries are recommended for end users, since LiVES will make indirect use of them (via mplayer) for decoding some video formats, and via mencoder for encoding some video formats.
I fail to see the reason for this to be sufficient cause for crossing out LiVES. A long time ago, ffmpeg contained some allegedly patented code (AAC audio IIRC), however this code was removed from the core of ffmpeg at least 5 years ago. However it seems that the FUD (and that is indeed what it is) persists. Microsoft must be laughing hard at this one.
If you don't believe me, then how is it that both ffmpeg and LiVES are in debian testing and unstable ? Please check for yourselves, and contact the debian legal team if you are still in doubt.
It is particularly timely that I noticed this, as I would like to introduce the new packager for LiVES in Fedora, Harry Rickards (harry@linux.com). Harry is also the point of contact between LiVES and the debian multimedia team who are responsible for packaging LiVES for debian.
I hope that you will correct the information on the wishlist page, stop spreading (unintentional ?) FUD about ffmpeg, and most importantly give Harry every assistance with the Fedora LiVES packages.
You're woefully mistaken if you think all patent-encumbered code has been removed from ffmpeg. Debian doesn't have a singular US corporate entity backing it like Fedora does. Red Hat legal has been down this road, and there's no way ffmpeg can be in Fedora, due to the number of US patents that its pretty well guaranteed to infringe upon. This isn't an endorsement of patents, just a practical matter. There are multiple 3rd-party package repositories for Fedora that carry ffmpeg packages though, as well as a good amount of software that utilize ffmpeg (including LiVES in at least one of said repos, iirc).
Please can you give an example of a patent which is violated in the *core* of ffmpeg.
Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 11:08 AM, Jarod Wilson jarod@redhat.com wrote:
On Mon, May 31, 2010 at 05:34:34AM -0300, salsaman wrote:
Hi all, I am the main developer/maintainer of LiVES (
http://lives.sourceforge.net).
I recently noticed the information about LiVES on this page: http://fedoraproject.org/wiki/PackageMaintainers/WishList#L-M
The information give about LiVES is inaccurate/incorrect. First of all, LiVES is not dependant on ffmpeg. As in, you can perfectly well build and run the application without ffmpeg being present on either the build
system
or the end user system.
However, the ffmpeg libraries are recommended for end users, since LiVES will make indirect use of them (via mplayer) for decoding some video formats, and via mencoder for encoding some video formats.
I fail to see the reason for this to be sufficient cause for crossing out LiVES. A long time ago, ffmpeg contained some allegedly patented code
(AAC
audio IIRC), however this code was removed from the core of ffmpeg at
least
5 years ago. However it seems that the FUD (and that is indeed what it
is)
persists. Microsoft must be laughing hard at this one.
If you don't believe me, then how is it that both ffmpeg and LiVES are in debian testing and unstable ? Please check for yourselves, and contact
the
debian legal team if you are still in doubt.
It is particularly timely that I noticed this, as I would like to
introduce
the new packager for LiVES in Fedora, Harry Rickards (harry@linux.com). Harry is also the point of contact between LiVES and the debian
multimedia
team who are responsible for packaging LiVES for debian.
I hope that you will correct the information on the wishlist page, stop spreading (unintentional ?) FUD about ffmpeg, and most importantly give Harry every assistance with the Fedora LiVES packages.
You're woefully mistaken if you think all patent-encumbered code has been removed from ffmpeg. Debian doesn't have a singular US corporate entity backing it like Fedora does. Red Hat legal has been down this road, and there's no way ffmpeg can be in Fedora, due to the number of US patents that its pretty well guaranteed to infringe upon. This isn't an endorsement of patents, just a practical matter. There are multiple 3rd-party package repositories for Fedora that carry ffmpeg packages though, as well as a good amount of software that utilize ffmpeg (including LiVES in at least one of said repos, iirc).
-- Jarod Wilson jarod@redhat.com
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On Tue, Jun 01, 2010 at 11:41:21AM -0300, salsaman wrote:
Please can you give an example of a patent which is violated in the *core* of ffmpeg.
This is the wrong place to raise legal questions wrt Fedora packaging, or potential new packages for Fedora. They should be directed to Fedora Legal team
http://fedoraproject.org/wiki/Legal
"If you have any legal questions that can be discussed in public, post to fedora-legal-list . If you have any private legal questions send a mail to legal AT fedoraproject.org"
Regards, Daniel
Please answer the question. I have been personally assured by representatives of the mplayer developers that the ffmpeg code contains *no patented code*. I spent over two years fighting to convince the debian developers that this was true, until they finally accepted it.
I am very tired of this discussion, and I am not prepared to go through it all again with the fedora legal dept.
Please just point me to just one registered patent that the core of ffmpeg is known to violate. Otherwise you are just spreading FUD.
Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 11:56 AM, Daniel P. Berrange berrange@redhat.comwrote:
On Tue, Jun 01, 2010 at 11:41:21AM -0300, salsaman wrote:
Please can you give an example of a patent which is violated in the
*core*
of ffmpeg.
This is the wrong place to raise legal questions wrt Fedora packaging, or potential new packages for Fedora. They should be directed to Fedora Legal team
http://fedoraproject.org/wiki/Legal
"If you have any legal questions that can be discussed in public, post to fedora-legal-list . If you have any private legal questions send a mail to legal AT fedoraproject.org"
Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ http://search.cpan.org/%7Edanberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On Tue, Jun 01, 2010 at 12:11:19PM -0300, salsaman wrote:
Please answer the question. I have been personally assured by representatives of the mplayer developers that the ffmpeg code contains *no patented code*. I spent over two years fighting to convince the debian developers that this was true, until they finally accepted it.
The general Fedora package maintainers aren't in a position to decide on legal question, so having this discussion here won't come to any useful conclusion. Only Fedora legal have the authority to decide on legal questions & so they are the people you have to ask about this, not Fedora packagers.
I am very tired of this discussion, and I am not prepared to go through it all again with the fedora legal dept.
Please just point me to just one registered patent that the core of ffmpeg is known to violate. Otherwise you are just spreading FUD.
I'm not spreading FUD, merely directing you to people who actually have the authority to speak for Fedora on legal questions like this.
Daniel
2010/6/1 salsaman salsaman@gmail.com:
Please answer the question. I have been personally assured by representatives of the mplayer developers that the ffmpeg code contains *no patented code*. I spent over two years fighting to convince the debian developers that this was true, until they finally accepted it.
I am very tired of this discussion, and I am not prepared to go through it all again with the fedora legal dept.
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
I suggest you to talk with spot who is the expert in fedora legal. He can determine whether fedora can include ffmpeg or not.
mail: tcallawa AT redhat.com
Regards, Chen Lei
On Tue, Jun 01, 2010 at 12:11:19PM -0300, salsaman wrote:
Please answer the question. I have been personally assured by representatives of the mplayer developers that the ffmpeg code contains *no patented code*.
Are these mplayer developers legal experts in patent law?
I spent over two years fighting to convince the debian developers that this was true, until they finally accepted it.
Again, Debian doesn't have the same level of exposure as a distribution with a corporate backer in the US -- i.e. Red Hat. Red Hat legal has already made a call on this. They would have to clear any change in stance with respect to ffmpeg and the like.
I am very tired of this discussion, and I am not prepared to go through it all again with the fedora legal dept.
Please just point me to just one registered patent that the core of ffmpeg is known to violate. Otherwise you are just spreading FUD.
If you're not willing to talk to someone with legal expertise about a legal matter, then you're not going to get anywhere here. Sorry.
On Tue, Jun 1, 2010 at 11:56 AM, Daniel P. Berrange berrange@redhat.comwrote:
On Tue, Jun 01, 2010 at 11:41:21AM -0300, salsaman wrote:
Please can you give an example of a patent which is violated in the
*core*
of ffmpeg.
This is the wrong place to raise legal questions wrt Fedora packaging, or potential new packages for Fedora. They should be directed to Fedora Legal team
http://fedoraproject.org/wiki/Legal
"If you have any legal questions that can be discussed in public, post to fedora-legal-list . If you have any private legal questions send a mail to legal AT fedoraproject.org"
Regards, Daniel
On Tue, Jun 1, 2010 at 12:30 PM, Jarod Wilson jarod@redhat.com wrote:
On Tue, Jun 01, 2010 at 12:11:19PM -0300, salsaman wrote:
Please answer the question. I have been personally assured by representatives of the mplayer developers that the ffmpeg code contains
*no
patented code*.
Are these mplayer developers legal experts in patent law?
No, but I am assuming they know which codecs are included in a minimal build of the libraries, and which codecs are known to be covered by patents/licensing agreements.
I spent over two years fighting to convince the debian developers that this was true, until they finally accepted it.
Again, Debian doesn't have the same level of exposure as a distribution with a corporate backer in the US -- i.e. Red Hat. Red Hat legal has already made a call on this. They would have to clear any change in stance with respect to ffmpeg and the like.
Debian has an extremely capable legal team who have many years of experience dealing with these matters. If something is cleared for inclusion in debian, you can pretty much assume it is legally OK.
I am very tired of this discussion, and I am not prepared to go through
it
all again with the fedora legal dept.
Please just point me to just one registered patent that the core of
ffmpeg
is known to violate. Otherwise you are just spreading FUD.
If you're not willing to talk to someone with legal expertise about a legal matter, then you're not going to get anywhere here. Sorry.
I am perfectly willing to talk to anyone with legal expertise in these matters. I am just making the point that until you have seen an actual patent which ffmpeg supposedly violates, making statements like "ffmpeg violates patents !" is FUD.
(For the record, for example, I would not advise any distros to include Mono, since I have seen actual US patents which it supposedly violates.)
In the meantime, perhaps you could include LiVES in fedora, since as I have pointed out, ffmpeg/mplayer/mencoder are *not* required for either building or running the application. LiVES will check at runtime if any of these are available so users who wish to use "restricted" codecs can either build mplayer from source or pull it from another distro.
Regards, Salsaman.
2010/6/1 salsaman salsaman@gmail.com: <snip>
In the meantime, perhaps you could include LiVES in fedora, since as I have pointed out, ffmpeg/mplayer/mencoder are *not* required for either building or running the application. LiVES will check at runtime if any of these are available so users who wish to use "restricted" codecs can either build mplayer from source or pull it from another distro.
Just like to say to everyone that I'm currently packaging LiVES, and although I've hit a couple of problems hope to have a review request on bugzilla within the next couple of days.
On Tue, Jun 1, 2010 at 8:30 AM, Harry Rickards harry@linux.com wrote:
Just like to say to everyone that I'm currently packaging LiVES, and although I've hit a couple of problems hope to have a review request on bugzilla within the next couple of days.
How functional is it without mplayer? And does the runtime detection work such that if you install mplayer from rpmfusion full functionality is recovered?
-jef
On Tue, Jun 1, 2010 at 1:34 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Tue, Jun 1, 2010 at 8:30 AM, Harry Rickards harry@linux.com wrote:
Just like to say to everyone that I'm currently packaging LiVES, and although I've hit a couple of problems hope to have a review request on bugzilla within the next couple of days.
How functional is it without mplayer? And does the runtime detection work such that if you install mplayer from rpmfusion full functionality is recovered?
Without mplayer, you would be limited to the following formats (assuming you had all the other required libs installed):
decoding:
dv (audio and video) ogg/theora (no audio) animted gif
multiple images (i.e animation sequences) generators (e.g. title generators)
external window and desktop capturing
clip imports from other copies of LiVES
encoding: dv (via libdv) ogg/theora (via encoder_example) animated gif flash/swf (using multiple jpeg) pdf
mjpeg/pcm (possibly) via transcode
If a user installs mplayer/mencoder after installing LiVES, then they will inherit whatever functionality is in mplayer/mencoder.
Regards, Salsaman.
2010/6/1 salsaman salsaman@gmail.com:
ogg/theora (via encoder_example)
it looks like we don't provided encoder_example. Probably a showstopper. Possibly fixable if the libtheora maintainers are willing to add in the encoder example binary. A gst pipeline encoder seems like a more robust solution however.
flash/swf (using multiple jpeg)
flash/swf? via what utility? This might not be available in Fedora out of the box.
mjpeg/pcm (possibly) via transcode
Definitely won't be in Fedora.
-jef
On Tue, Jun 1, 2010 at 1:55 PM, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
ogg/theora (via encoder_example)
it looks like we don't provided encoder_example. Probably a showstopper. Possibly fixable if the libtheora maintainers are willing to add in the encoder example binary. A gst pipeline encoder seems like a more robust solution however.
flash/swf (using multiple jpeg)
flash/swf? via what utility? This might not be available in Fedora out of the box.
sswf
http://www.m2osw.com/sswf.html
mjpeg/pcm (possibly) via transcode
Definitely won't be in Fedora.
-jef
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
2010/6/1 salsaman salsaman@gmail.com:
In the meantime, perhaps you could include LiVES in fedora, since as I have pointed out, ffmpeg/mplayer/mencoder are *not* required for either building or running the application. LiVES will check at runtime if any of these are available so users who wish to use "restricted" codecs can either build mplayer from source or pull it from another distro.
I'm still not clear on the capabilities that do not eventually require ffmpeg or mplayer. Theora/ogg encoding requires mplayer in LIVES or did I misread the previous post?
-jef
Theora/ogg encoding uses encoder_example from libtheora. Some packages rename this to theora_encoder_example (which will also work with LiVES) and include it in libtheora-bin package.
Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 1:33 PM, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
In the meantime, perhaps you could include LiVES in fedora, since as I
have
pointed out, ffmpeg/mplayer/mencoder are *not* required for either
building
or running the application. LiVES will check at runtime if any of these
are
available so users who wish to use "restricted" codecs can either build mplayer from source or pull it from another distro.
I'm still not clear on the capabilities that do not eventually require ffmpeg or mplayer. Theora/ogg encoding requires mplayer in LIVES or did I misread the previous post?
-jef
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
2010/6/1 salsaman salsaman@gmail.com:
Theora/ogg encoding uses encoder_example from libtheora. Some packages rename this to theora_encoder_example (which will also work with LiVES) and include it in libtheora-bin package.
Thanks for the clarification. We may need to rework the libtheora package to better support LIVES before it is introduced. The libtheora we ship does not including any binary executables.. just the libraries.
If you could find a way to support a theora/ogg gstreamer pipeline via use of gst-launch for our users to use until mplayer is installed that would be another option instead of the encoder_example.
-jef
I've looked into adding gst support and it is something I would love to have, unfortunately there seems to be no generic media detection capability in gstreamer, which is a must have for LiVES. The same problem with MLT.
Regards, Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 1:43 PM, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
Theora/ogg encoding uses encoder_example from libtheora. Some packages rename this to theora_encoder_example (which will also work with LiVES)
and
include it in libtheora-bin package.
Thanks for the clarification. We may need to rework the libtheora package to better support LIVES before it is introduced. The libtheora we ship does not including any binary executables.. just the libraries.
If you could find a way to support a theora/ogg gstreamer pipeline via use of gst-launch for our users to use until mplayer is installed that would be another option instead of the encoder_example.
-jef
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
2010/6/1 salsaman salsaman@gmail.com:
I've looked into adding gst support and it is something I would love to have, unfortunately there seems to be no generic media detection capability in gstreamer, which is a must have for LiVES. The same problem with MLT.
a call to a gst-launch script can't be used in place of encoder_example? I'm looking specifically just to replace the shell out to encoder_example for theora functionality.. not deeply integrate gst.
-jef
Sure it would be possible, somebody would just need to change the theora_encoder.py script. I don't have time for this right now as I am busy with a GSOC project for vlc.
Regards, Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 1:49 PM, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
I've looked into adding gst support and it is something I would love to have, unfortunately there seems to be no generic media detection
capability
in gstreamer, which is a must have for LiVES. The same problem with MLT.
a call to a gst-launch script can't be used in place of encoder_example? I'm looking specifically just to replace the shell out to encoder_example for theora functionality.. not deeply integrate gst.
-jef
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On 06/01/2010 06:26 PM, salsaman wrote:
On Tue, Jun 1, 2010 at 12:30 PM, Jarod Wilsonjarod@redhat.com wrote:
On Tue, Jun 01, 2010 at 12:11:19PM -0300, salsaman wrote:
In the meantime, perhaps you could include LiVES in fedora, since as I have pointed out, ffmpeg/mplayer/mencoder are *not* required for either building or running the application.
Which functional regressions will a missing dependency cause?
LiVES will check at runtime if any of these are available so users who wish to use "restricted" codecs can either build mplayer from source or pull it from another distro.
It has a dependency on mpegtools (N/A in Fedora).
Ralf
On Tue, Jun 1, 2010 at 1:45 PM, Ralf Corsepius rc040203@freenet.de wrote:
On 06/01/2010 06:26 PM, salsaman wrote:
On Tue, Jun 1, 2010 at 12:30 PM, Jarod Wilsonjarod@redhat.com wrote:
On Tue, Jun 01, 2010 at 12:11:19PM -0300, salsaman wrote:
In the meantime, perhaps you could include LiVES in fedora, since as I
have pointed out, ffmpeg/mplayer/mencoder are *not* required for either building or running the application.
Which functional regressions will a missing dependency cause?
When you try to open a video type which LiVES doesn't have a decoder for, the user will get an error "LiVES was unable to extract either video or audio from this file."
LiVES will check at runtime if any of these are
available so users who wish to use "restricted" codecs can either build mplayer from source or pull it from another distro.
It has a dependency on mpegtools (N/A in Fedora).
mjpegtools is an optional dependency. Without it you will lose support for live camera inputs and yuv4mpeg streaming.
(Actually, LiVES doesn't even use the mpeg part of it, it just uses some #defines from yuv4mpeg.h).
Salsaman.
2010/6/1 salsaman salsaman@gmail.com:
(Actually, LiVES doesn't even use the mpeg part of it, it just uses some #defines from yuv4mpeg.h).
Are you saying that mpjegtools sources need to be available at LIVES compile time and this isn't a runtime dep? That could be a significant problem in that we can't make those sources available in our buildsystem.
-jef
2010/6/2 Jeff Spaleta jspaleta@gmail.com:
2010/6/1 salsaman salsaman@gmail.com:
(Actually, LiVES doesn't even use the mpeg part of it, it just uses some #defines from yuv4mpeg.h).
Are you saying that mpjegtools sources need to be available at LIVES compile time and this isn't a runtime dep? That could be a significant problem in that we can't make those sources available in our buildsystem.
-jef
Bundling some source code from other project with compatible license it permitted in fedora, it won't be a big deal.
Chen Lei
As I said, it's an optional build time dependency.
Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 1:54 PM, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
(Actually, LiVES doesn't even use the mpeg part of it, it just uses some #defines from yuv4mpeg.h).
Are you saying that mpjegtools sources need to be available at LIVES compile time and this isn't a runtime dep? That could be a significant problem in that we can't make those sources available in our buildsystem.
-jef
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
2010/6/1 salsaman salsaman@gmail.com:
As I said, it's an optional build time dependency.
But this is a build time only feature right? We try to avoid shipping degraded functionality applications which have to be recompiled to get access to missing features. Is the camera inputs run time detectable? if not... this still be be destined for rpmfusion even with runtime detectable mplayer support.
-jef
Yes, the live camera support will only be there if mjpegtools-devel is present at build time. However, many distros build LiVES without this feature (e.g. debian and ubuntu).
I'd not heard of rpmfusion before, but if it's acceptible to Harry then I suggest we target builds for that instead of for for fedora itself.
This just leaves the issue of encoder_example for theora. In the absence of a gst solution, may I suggest somebody (not me) contact the libtheora packager and ask them to create a theora-bin package with just this binary ?
Regards, Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 2:11 PM, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
As I said, it's an optional build time dependency.
But this is a build time only feature right? We try to avoid shipping degraded functionality applications which have to be recompiled to get access to missing features. Is the camera inputs run time detectable? if not... this still be be destined for rpmfusion even with runtime detectable mplayer support.
-jef
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
2010/6/1 salsaman salsaman@gmail.com:
I'd not heard of rpmfusion before, but if it's acceptible to Harry then I suggest we target builds for that instead of for for fedora itself.
If you are targeting rpmfusion, then the gst workaround I was trying to suggest becomes less important as rpmfusion's LIVES can depend on mplayer as packaged by rpmfusion even for theora.
-jef
Yes, but you will still need encoder_example for encoding theora, even with mencoder present.
Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 3:00 PM, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
I'd not heard of rpmfusion before, but if it's acceptible to Harry then I suggest we target builds for that instead of for for fedora itself.
If you are targeting rpmfusion, then the gst workaround I was trying to suggest becomes less important as rpmfusion's LIVES can depend on mplayer as packaged by rpmfusion even for theora.
-jef
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
2010/6/1 salsaman salsaman@gmail.com:
Yes, but you will still need encoder_example for encoding theora, even with mencoder present.
Ah... hmmm. Looking again.... we do have it in the packages theora-tools. The package naming difference just threw me off.
We package it as /usr/bin/theora-encode in the package theora-tools. So Requires: theora-tools should be enough.
-jef
That will require patching of theora_encoder.py and theora_encoder3.py:
- theora_encoder2 = 'theora_encoder_example' + theora_encoder2 = 'theora-encode'
Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 3:06 PM, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
Yes, but you will still need encoder_example for encoding theora, even
with
mencoder present.
Ah... hmmm. Looking again.... we do have it in the packages theora-tools. The package naming difference just threw me off.
We package it as /usr/bin/theora-encode in the package theora-tools. So Requires: theora-tools should be enough.
-jef
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
I mean for rpmfusion only. I will not patch this upstream.
Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 3:13 PM, salsaman salsaman@gmail.com wrote:
That will require patching of theora_encoder.py and theora_encoder3.py:
- theora_encoder2 = 'theora_encoder_example'
- theora_encoder2 = 'theora-encode'
Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 3:06 PM, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
Yes, but you will still need encoder_example for encoding theora, even
with
mencoder present.
Ah... hmmm. Looking again.... we do have it in the packages theora-tools. The package naming difference just threw me off.
We package it as /usr/bin/theora-encode in the package theora-tools. So Requires: theora-tools should be enough.
-jef
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On 1 June 2010 19:00, Jeff Spaleta jspaleta@gmail.com wrote:
2010/6/1 salsaman salsaman@gmail.com:
I'd not heard of rpmfusion before, but if it's acceptible to Harry then I suggest we target builds for that instead of for for fedora itself.
If you are targeting rpmfusion, then the gst workaround I was trying to suggest becomes less important as rpmfusion's LIVES can depend on mplayer as packaged by rpmfusion even for theora.
That's fine with me.
2010/6/1 salsaman salsaman@gmail.com:
I'd not heard of rpmfusion before, but if it's acceptible to Harry then I suggest we target builds for that instead of for for fedora itself.
From the rpmfusion FAQ - "RPM Fusion is a repository of add-on
packages for Fedora and EL+EPEL maintained by a group of volunteers. RPM Fusion is not a standalone repository, but an extension of Fedora. RPM Fusion distributes packages that have been deemed unacceptable to Fedora."
On 06/01/2010 06:50 PM, salsaman wrote:
On Tue, Jun 1, 2010 at 1:45 PM, Ralf Corsepiusrc040203@freenet.de wrote:
On 06/01/2010 06:26 PM, salsaman wrote:
On Tue, Jun 1, 2010 at 12:30 PM, Jarod Wilsonjarod@redhat.com wrote:
On Tue, Jun 01, 2010 at 12:11:19PM -0300, salsaman wrote:
In the meantime, perhaps you could include LiVES in fedora, since as I
have pointed out, ffmpeg/mplayer/mencoder are *not* required for either building or running the application.
Which functional regressions will a missing dependency cause?
When you try to open a video type which LiVES doesn't have a decoder for, the user will get an error "LiVES was unable to extract either video or audio from this file."
LiVES will check at runtime if any of these are
available so users who wish to use "restricted" codecs can either build mplayer from source or pull it from another distro.
It has a dependency on mpegtools (N/A in Fedora).
mjpegtools is an optional dependency. Without it you will lose support for live camera inputs and yuv4mpeg streaming.
(Actually, LiVES doesn't even use the mpeg part of it, it just uses some #defines from yuv4mpeg.h).
My vote: Let LiVES go into RPMFusion and don't ship functionally degraded packages in Fedora.
Ralf
On 06/01/2010 12:26 PM, salsaman wrote:
Debian has an extremely capable legal team who have many years of experience dealing with these matters. If something is cleared for inclusion in debian, you can pretty much assume it is legally OK.
I'm sorry. If you could only see how hard I am laughing right now.
Needless to say, in this universe, I would not make that assumption.
Legal issues surrounding FOSS are very complicated. I dare say that there are less than 100 people (possibly less than 50) who have a solid grasp on the complexities of the various concerns around copyright, trademarks, trade secrets, and patents with regards to FOSS, and none of those people are involved with debian-legal in any meaningful way, to the best of my knowledge.
That's not saying that Debian Legal isn't a group of well-intentioned, generally intelligent folks, simply that they are by no means a good source for legal advice, issue resolution, or acceptability of licensing.
I consult with lawyers, frequently. There is no evidence that the majority of debian legal participants do.
Now, if you had said that someone like Van Lindberg, or the SFLC had cleared something from a legal perspective, that might be noteworthy, and would motivate me to revisit something. But Debian Legal? Armchair lawyering at its worst.
~spot
On Tuesday, 01 June 2010 at 17:11, salsaman wrote:
Please answer the question. I have been personally assured by representatives of the mplayer developers that the ffmpeg code contains *no patented code*. I spent over two years fighting to convince the debian developers that this was true, until they finally accepted it.
As far as I know (and I know many of them personally), none of MPlayer developers are lawyers, so even if one of them said that (which I seriously doubt), it doesn't "clear" anything. In other words, please tell us what was the exact question that you asked, what was the answer, and who provided it? Preferably by pointing to a post from a public mailing list.
Regards, R.
As far as I can recall it was part of a lengthy discussion I had with Diego Biurrun several years ago. I don't have the email to hand any more. But the gist was that libavcodec/libavformat no longer contained any hard coded codecs, so it would be possible to build these libraries with just free codecs (e.g. ogg/theora/vorbis).
Therefore, I would be interested to know - if one were to build libavcodec/libavformat with all codecs disabled except for say, ogg/theora/vorbis, would there still be a problem ?
Regards, Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 5:54 PM, Dominik 'Rathann' Mierzejewski < dominik@greysector.net> wrote:
On Tuesday, 01 June 2010 at 17:11, salsaman wrote:
Please answer the question. I have been personally assured by representatives of the mplayer developers that the ffmpeg code contains
*no
patented code*. I spent over two years fighting to convince the debian developers that this was true, until they finally accepted it.
As far as I know (and I know many of them personally), none of MPlayer developers are lawyers, so even if one of them said that (which I seriously doubt), it doesn't "clear" anything. In other words, please tell us what was the exact question that you asked, what was the answer, and who provided it? Preferably by pointing to a post from a public mailing list.
Regards, R.
-- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
2010/6/1 salsaman salsaman@gmail.com:
Therefore, I would be interested to know - if one were to build libavcodec/libavformat with all codecs disabled except for say, ogg/theora/vorbis, would there still be a problem ?
Yes. If the codec support in question is strictly a build time option for the libraries in question. If the supported codecs are strictly compile time options, then we are put in a position where we have to anticipate users needing to replace already installed Fedora packages with packages from somewhere else to gain the additional functional. We avoid doing that as a matter of policy as it adds complexity to the multi-repository relationship. We prefer runtime detectable solutions that can be packaged as plugins which do not conflict with Fedora packages.
This is what makes gstreamer a preferred framework for us as a distributor...its runtime extensibility. An addon repository can package gstreamer plugins that extend functionality without needing to replace any packages we provide as part of Fedora. On top of that there are hooks in packagekit which allow users to install the gstreamer plugin package on demand based on mime information from their configured repositories.
Xine libraries also exposes enough runtime detection capabilities to allow up to ship the core xine libraries in fedora...while some codec support support is provided as plugins from elsewhere.
-jef
On 06/01/2010 10:41 AM, salsaman wrote:
Please can you give an example of a patent which is violated in the *core* of ffmpeg.
Since I don't want anyone to get the impression that I didn't see this and chose to ignore it, let me reply.
It is very difficult to have an open and honest discussion about patents. If I was to say "ffmpeg violates patent #123456789ABCDE" (1), it has the potential to be extremely damaging to Red Hat (or potentially, others), as merely doing so puts Red Hat at a much higher risk of being found guilty of "willful infringement" and subject to the possibility of "treble damages".
For details on how that works, please read: http://www.mmmlaw.com/articles/article_234.pdf
So, even if I were to clearly bound my statement as being applicable to only ffmpeg, I would be going on the public record as:
* Being aware of Patent #123456789ABCDE (and accordingly, that Red Hat was aware) * Being familiar enough with Patent #123456789ABCDE to say that it is applicable in that case (so, obviously, both I and Red Hat must be aware of all other places where it is applicable)
The patent holder(s) of #123456789ABCDE would then be able to go through EVERYTHING that Red Hat distributes (which is not a small amount of stuff), find anything that they feel that #123456789ABCDE infringes, and file suit, with my email response as evidence.
So, you will never ever ever ever ever get an email from me or Red Hat that says "foo infringes patent #bar" or even "foo doesn't infringe patent #bar", because of what that means, and the risk it imposes on us.
In 2009, the cost of the average patent lawsuit was $5,500,000. (2) That's just how much it costs to deal with the lawsuit. The damages, should the court find for the patent holder, could easily be 5 to 10 times that amount.
Hopefully, this clarifies why Red Hat does not make statements about specific patents.
*****
Now, with that said:
ffmpeg continues to be unacceptable for Fedora due to legal concerns.
I apologize for any inconvenience this causes you.
Thanks,
Tom Callaway, Fedora Legal
P.S. I Am Not A Lawyer. Nothing in the above email should be considered legal advice. I consult regularly with Red Hat Legal, who are lawyers.
P.P.S. I don't think Debian accounts for patents in any meaningful way when considering which software can be included in their repositories, only copyright licensing.
Notes:
(1) Not a real patent. Not a real statement of review of non-real patent. (2) 2009 AIPLA Economic Survey at pp. 138 to 141.
OK, Tom, thanks for clarifying that.
Salsaman.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 2:40 PM, Tom "spot" Callaway tcallawa@redhat.comwrote:
On 06/01/2010 10:41 AM, salsaman wrote:
Please can you give an example of a patent which is violated in the *core* of ffmpeg.
Since I don't want anyone to get the impression that I didn't see this and chose to ignore it, let me reply.
It is very difficult to have an open and honest discussion about patents. If I was to say "ffmpeg violates patent #123456789ABCDE" (1), it has the potential to be extremely damaging to Red Hat (or potentially, others), as merely doing so puts Red Hat at a much higher risk of being found guilty of "willful infringement" and subject to the possibility of "treble damages".
For details on how that works, please read: http://www.mmmlaw.com/articles/article_234.pdf
So, even if I were to clearly bound my statement as being applicable to only ffmpeg, I would be going on the public record as:
- Being aware of Patent #123456789ABCDE (and accordingly, that Red Hat
was aware)
- Being familiar enough with Patent #123456789ABCDE to say that it is
applicable in that case (so, obviously, both I and Red Hat must be aware of all other places where it is applicable)
The patent holder(s) of #123456789ABCDE would then be able to go through EVERYTHING that Red Hat distributes (which is not a small amount of stuff), find anything that they feel that #123456789ABCDE infringes, and file suit, with my email response as evidence.
So, you will never ever ever ever ever get an email from me or Red Hat that says "foo infringes patent #bar" or even "foo doesn't infringe patent #bar", because of what that means, and the risk it imposes on us.
In 2009, the cost of the average patent lawsuit was $5,500,000. (2) That's just how much it costs to deal with the lawsuit. The damages, should the court find for the patent holder, could easily be 5 to 10 times that amount.
Hopefully, this clarifies why Red Hat does not make statements about specific patents.
Now, with that said:
ffmpeg continues to be unacceptable for Fedora due to legal concerns.
I apologize for any inconvenience this causes you.
Thanks,
Tom Callaway, Fedora Legal
P.S. I Am Not A Lawyer. Nothing in the above email should be considered legal advice. I consult regularly with Red Hat Legal, who are lawyers.
P.P.S. I don't think Debian accounts for patents in any meaningful way when considering which software can be included in their repositories, only copyright licensing.
Notes:
(1) Not a real patent. Not a real statement of review of non-real patent. (2) 2009 AIPLA Economic Survey at pp. 138 to 141.
Hi,
On Monday, 31 May 2010 at 10:34, salsaman wrote:
Hi all, I am the main developer/maintainer of LiVES (http://lives.sourceforge.net).
I recently noticed the information about LiVES on this page: http://fedoraproject.org/wiki/PackageMaintainers/WishList#L-M
The information give about LiVES is inaccurate/incorrect. First of all, LiVES is not dependant on ffmpeg. As in, you can perfectly well build and run the application without ffmpeg being present on either the build system or the end user system.
What codecs and containers is LiVES able to process without FFmpeg/MPlayer?
However, the ffmpeg libraries are recommended for end users, since LiVES will make indirect use of them (via mplayer) for decoding some video formats, and via mencoder for encoding some video formats.
Well, neither MPlayer nor MEncoder can't be included in any useful form in Fedora. We have them in RPMFusion instead.
I fail to see the reason for this to be sufficient cause for crossing out LiVES.
Is it useful without mplayer and mencoder binaries at all? What can it do then?
A long time ago, ffmpeg contained some allegedly patented code (AAC audio IIRC), however this code was removed from the core of ffmpeg at least 5 years ago.
Not true at all. FFmpeg contains a lot of code that implements standards that depend on possibly patented "inventions". I've been following FFmpeg development almost from the beginning (and I maintain FFmpeg packages in RPMFusion) and I don't remember any code being removed from FFmpeg on the basis that it was allegedly covered by patents. The AAC case you're referring to was about licence compatibility, not patents. FAAC was distributed under the GPLv2, but it turned out that it contained some code whose licence was incompatible with the GPL, so FFmpeg stopped allowing enabling FAAC support without --enable-nonfree, because binaries linked with libfaac are not distributable.
If you don't believe me, then how is it that both ffmpeg and LiVES are in debian testing and unstable ? Please check for yourselves, and contact the debian legal team if you are still in doubt.
For some reason, Debian seems to include the decoding parts of various codecs even though they may be covered by some patents. They don't ship any encoders as far as I know, though. Anyway, even the decoders are not OK for Fedora.
It is particularly timely that I noticed this, as I would like to introduce the new packager for LiVES in Fedora, Harry Rickards (harry@linux.com). Harry is also the point of contact between LiVES and the debian multimedia team who are responsible for packaging LiVES for debian.
I hope that you will correct the information on the wishlist page, stop spreading (unintentional ?) FUD about ffmpeg, and most importantly give Harry every assistance with the Fedora LiVES packages.
We welcome all new packagers with open hands. However, please check your facts before going off on a rant and accusing people of spreading FUD.
Regards,
On Tue, Jun 1, 2010 at 11:37 AM, Dominik 'Rathann' Mierzejewski < dominik@greysector.net> wrote:
Hi,
On Monday, 31 May 2010 at 10:34, salsaman wrote:
Hi all, I am the main developer/maintainer of LiVES (
http://lives.sourceforge.net).
I recently noticed the information about LiVES on this page: http://fedoraproject.org/wiki/PackageMaintainers/WishList#L-M
The information give about LiVES is inaccurate/incorrect. First of all, LiVES is not dependant on ffmpeg. As in, you can perfectly well build and run the application without ffmpeg being present on either the build
system
or the end user system.
What codecs and containers is LiVES able to process without FFmpeg/MPlayer?
dv (with libdv), ogg/theora (although ffmpeg is required for vorbis encoding/decoding), mng (encoding only), animated gif.
However, the ffmpeg libraries are recommended for end users, since LiVES will make indirect use of them (via mplayer) for decoding some video formats, and via mencoder for encoding some video formats.
Well, neither MPlayer nor MEncoder can't be included in any useful form in Fedora. We have them in RPMFusion instead.
I fail to see the reason for this to be sufficient cause for crossing out LiVES.
Is it useful without mplayer and mencoder binaries at all? What can it do then?
You can edit dv, or you could for example load in an image sequence and encode it to ogg/theora.
A long time ago, ffmpeg contained some allegedly patented code (AAC audio IIRC), however this code was removed from the core of ffmpeg at
least
5 years ago.
Not true at all. FFmpeg contains a lot of code that implements standards that depend on possibly patented "inventions". I've been following FFmpeg development almost from the beginning (and I maintain FFmpeg packages in RPMFusion) and I don't remember any code being removed from FFmpeg on the basis that it was allegedly covered by patents. The AAC case you're referring to was about licence compatibility, not patents. FAAC was distributed under the GPLv2, but it turned out that it contained some code whose licence was incompatible with the GPL, so FFmpeg stopped allowing enabling FAAC support without --enable-nonfree, because binaries linked with libfaac are not distributable.
Again, what patents are violated by the *core* of ffmpeg (with all non-free decoders/encoders disabled) ? I think the only codecs included in the core are probably snow, and the nut container format.
If you don't believe me, then how is it that both ffmpeg and LiVES are in debian testing and unstable ? Please check for yourselves, and contact
the
debian legal team if you are still in doubt.
For some reason, Debian seems to include the decoding parts of various codecs even though they may be covered by some patents. They don't ship any encoders as far as I know, though. Anyway, even the decoders are not OK for Fedora.
It depends on which codecs. For example if they include only theora, dv, pcm and mjpeg decoding then there is no problem. Same with ogg and matroska container formats.
It is particularly timely that I noticed this, as I would like to
introduce
the new packager for LiVES in Fedora, Harry Rickards (harry@linux.com). Harry is also the point of contact between LiVES and the debian
multimedia
team who are responsible for packaging LiVES for debian.
I hope that you will correct the information on the wishlist page, stop spreading (unintentional ?) FUD about ffmpeg, and most importantly give Harry every assistance with the Fedora LiVES packages.
We welcome all new packagers with open hands. However, please check your facts before going off on a rant and accusing people of spreading FUD.
When you can show me an actual example of a registered patent which the core of ffmpeg violates then I will stop. Until then I still regard it as FUD.
Salsaman.
Regards,
-- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On Tuesday, 01 June 2010 at 16:53, salsaman wrote:
On Tue, Jun 1, 2010 at 11:37 AM, Dominik 'Rathann' Mierzejewski wrote:
[...]
What codecs and containers is LiVES able to process without FFmpeg/MPlayer?
dv (with libdv), ogg/theora (although ffmpeg is required for vorbis encoding/decoding), mng (encoding only), animated gif.
I guess this might be useful then. What about WebM/VP8?
[...]
We welcome all new packagers with open hands. However, please check your facts before going off on a rant and accusing people of spreading FUD.
When you can show me an actual example of a registered patent which the core of ffmpeg violates then I will stop. Until then I still regard it as FUD.
http://wiki.multimedia.cx/index.php?search=patents
If you can provide a configure command that would produce a non-patent- encumbered FFmpeg binary and a list of files that must be deleted from FFmpeg tarball so that it can be distributed by Fedora then please do so. I have no time to do this and even if I did, I'd most likely be unable to find all the relevant patents and miss something. Until then, I'll keep maintaining it in RPMFusion.
Regards, R.
http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman
On Tue, Jun 1, 2010 at 12:09 PM, Dominik 'Rathann' Mierzejewski < dominik@greysector.net> wrote:
On Tuesday, 01 June 2010 at 16:53, salsaman wrote:
On Tue, Jun 1, 2010 at 11:37 AM, Dominik 'Rathann' Mierzejewski wrote:
[...]
What codecs and containers is LiVES able to process without
FFmpeg/MPlayer?
dv (with libdv), ogg/theora (although ffmpeg is required for vorbis encoding/decoding), mng (encoding only), animated gif.
I guess this might be useful then. What about WebM/VP8?
[...]
We welcome all new packagers with open hands. However, please check
your
facts before going off on a rant and accusing people of spreading FUD.
When you can show me an actual example of a registered patent which the
core
of ffmpeg violates then I will stop. Until then I still regard it as FUD.
http://wiki.multimedia.cx/index.php?search=patents
If you can provide a configure command that would produce a non-patent- encumbered FFmpeg binary and a list of files that must be deleted from FFmpeg tarball so that it can be distributed by Fedora then please do so. I have no time to do this and even if I did, I'd most likely be unable to find all the relevant patents and miss something. Until then, I'll keep maintaining it in RPMFusion.
Regards, R.
Sure, I can make a configure commandline which would only enable for example ogg/theora/vorbis and other free codecs. You could then edit (in LiVES):
ogg/theora/vorbis mjpeg/pcm ffv1 (lossless) ogg/dirac/vorbis
and in the future:
vp8/vorbis/matroska (a.k.a webm, the new format from Google).
Actually we should get the terminology straight.
ffmpeg is a binary which uses libavcodec and libavformat. mplayer and mencoder are also binaries which make use of libavcodec and libavformat.
So what we are really talking about are configure options for libavcodec and libavformat in mplayer and mencoder.
LiVES does not use ffmpeg (except as an optional encoder for example for webm format, since the commandline options are simpler than for mencoder).
LiVES will make use of mplayer and mencoder if they are present to decode/encode the above mentioned video and audio formats.
Regards, Salsaman.
packaging@lists.fedoraproject.org
-
Chen Lei -
Daniel P. Berrange -
Dominik 'Rathann' Mierzejewski -
Harry Rickards -
Jarod Wilson -
Jef Spaleta -
Ralf Corsepius -
salsaman -
Tom Callaway