Discussion:
[PATCH] Dynamic plugins loading
Nicolas George
2010-10-31 13:42:14 UTC
Permalink
Hi.

This patch is an attempt at implementing a simple plugins architecture for
ffmpeg / libav*.

The design is kept minimalistic on purpose: any file named av*.so in
$PREFIX/lib/ffmpeg/ or $AV_PLUGIN_PATH is dlopened, and its _init function
is expected to call av_register_something to publish its features.

There is probably much to discuss, but at the very least, it works to simply
add support for a new format in lavf by just dropping a file in a directory.
Codecs and filters should work just the same.

Regards,
--
Nicolas George
Benjamin Larsson
2010-10-31 22:29:16 UTC
Permalink
Post by Nicolas George
Hi.
This patch is an attempt at implementing a simple plugins architecture for
ffmpeg / libav*.
Yey, do we care about the possible licenses of plugins ?

MvH
Benjamin Larsson
Rafaël Carré
2010-10-31 23:04:49 UTC
Permalink
On Sun, 31 Oct 2010 14:42:14 +0100
+ * Load all plugins in a :-separated directory list.
+ */
+void av_plugin_load_path(const char *path);
$ mkdir :;ls -d ?
:


: is a valid name for a file or a directory so it won't work
--
Rafaël Carré
Nicolas George
2010-10-31 23:09:18 UTC
Permalink
Post by Rafaël Carré
: is a valid name for a file or a directory so it won't work
Having : as a separator for $PATH, $LD_LIBRARY_PATH, $MANPATH, etc., has
never bothered anyone much. It is not aesthetically perfect, but it is
common practice and has worked quite well for 40 years.

Regards,
--
Nicolas George
Ronald S. Bultje
2010-11-01 00:52:52 UTC
Permalink
Hi,

On Sun, Oct 31, 2010 at 9:42 AM, Nicolas George
Post by Nicolas George
There is probably much to discuss, but at the very least, it works to simply
add support for a new format in lavf by just dropping a file in a directory.
Codecs and filters should work just the same.
Let's just go over the big phat elephant in the room. Is this an advantage?

I used to think this kind of stuff was good. But is there really an
advantage to all this? I can think of disadvantages:
- no strong license enforcement because you can separate shipping of
software pieces that have strictly incompatible licenses
- security becomes worthless, any plugin can exploit a system
- stability becomes a nightmare as soon as you start thinking about
possibly updating ABI/API
- dynamic plugins won't share code with the main source tree, which
means that the best point of FFmpeg - fast and lean - no longer
applies
- companies can suddenly get away with releasing a binary plus FFmpeg
wrapper code. This is _bad_. We don't want to promote this kind of
silliness in any way

If people want a massive, slow, insecure licensing headache that has
something to do with multimedia, they can install one of the many
"multimedia frameworks" that were created to """solve""" this problem.
Right?

Ronald
Ramiro Polla
2010-11-01 01:06:40 UTC
Permalink
Post by Ronald S. Bultje
On Sun, Oct 31, 2010 at 9:42 AM, Nicolas George
Post by Nicolas George
There is probably much to discuss, but at the very least, it works to simply
add support for a new format in lavf by just dropping a file in a directory.
Codecs and filters should work just the same.
Let's just go over the big phat elephant in the room. Is this an advantage?
I used to think this kind of stuff was good. But is there really an
- no strong license enforcement because you can separate shipping of
software pieces that have strictly incompatible licenses
- security becomes worthless, any plugin can exploit a system
- stability becomes a nightmare as soon as you start thinking about
possibly updating ABI/API
- dynamic plugins won't share code with the main source tree, which
means that the best point of FFmpeg - fast and lean - no longer
applies
- companies can suddenly get away with releasing a binary plus FFmpeg
wrapper code. This is _bad_. We don't want to promote this kind of
silliness in any way
If people want a massive, slow, insecure licensing headache that has
something to do with multimedia, they can install one of the many
"multimedia frameworks" that were created to """solve""" this problem.
Right?
I agree with Ronald.

We had something similar (vhooks) and dropped it.

Ramiro Polla
Michael Niedermayer
2010-11-01 12:46:35 UTC
Permalink
Post by Ronald S. Bultje
Hi,
On Sun, Oct 31, 2010 at 9:42 AM, Nicolas George
Post by Nicolas George
There is probably much to discuss, but at the very least, it works to simply
add support for a new format in lavf by just dropping a file in a directory.
Codecs and filters should work just the same.
Let's just go over the big phat elephant in the room. Is this an advantage?
i was starting to be scared and surprised that noone was bringing the "why"
up already.
Post by Ronald S. Bultje
I used to think this kind of stuff was good. But is there really an
- no strong license enforcement because you can separate shipping of
software pieces that have strictly incompatible licenses
- security becomes worthless, any plugin can exploit a system
- stability becomes a nightmare as soon as you start thinking about
possibly updating ABI/API
- dynamic plugins won't share code with the main source tree, which
means that the best point of FFmpeg - fast and lean - no longer
applies
- companies can suddenly get away with releasing a binary plus FFmpeg
wrapper code. This is _bad_. We don't want to promote this kind of
silliness in any way
If people want a massive, slow, insecure licensing headache that has
something to do with multimedia, they can install one of the many
"multimedia frameworks" that were created to """solve""" this problem.
Right?
It also reminds me of firefox, huge numbers of plugins, the basic browser
lacks huge amounts of basic functionality (resuming downloads, enabling
cookies & scripts per site & blocking well known addvertisement/spy sites)
what should be is firefox should include all that is usefull and that should
be properly checked for being securely implemented.

I agree with ronald that a plugin architecture wont do us nor our users any
good.


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
Nicolas George
2010-11-01 13:54:33 UTC
Permalink
Post by Michael Niedermayer
I agree with ronald that a plugin architecture wont do us nor our users any
good.
My reason for implementing it yesterday, apart from the fact that some
people did manifest interest about it on the mailing lists some time ago,
was this:

For a DVB-grabber/player system I maintain, I have designed a custom storage
format, because none of the existing formats suited my needs. A dynamic
loading system would have slightly simplified upgrades of the video tools,
even making it possible to use the distro's versions (if someday they become
decent).

Anyway, I understand perfectly why most people here do not like the idea of
a plugin system, and I do not intend to insist for its inclusion. But I have
spotted a few logical flaws in the argument that have been stated, and I can
not resist answering them.

The main flaw is that the cat is now out of the box: any GPL abuser can
download my patch from the mailing-list archives, apply it and use it to
load its proprietary code. And even without it, what I have written
yesterday, any half-decent coding monkey working for said GPL abuser could
have coded too. And if that was not enough, using LD_PRELOAD also allows to
add plugins to ffmpeg.

As for the concern about stability and security, I believe it is the concern
of people who decide to load crappy plugins in their ffmpeg, either with a
published interface or with LD_PRELOAD.

The problem in Firefox is not that it has an extension mechanism, it's that
the core developers have taken it as an excuse not to do their job
completely: "this crucial feature is missing? just write an extension", with
all the problems that implies (out of date bitrotting extensions, forks).

As far as I can see, the only security issue with this patch is that some
half-baked privilege escalation systems will sanitize LD_PRELOAD and not
AV_PLUGIN_PATH.

Anyway, as I said, I do not intend to insist further.

(On the other hand, if anyone knows a supported format that allows efficient
extraction of two 1-hour shows from a 3-hours recording with commercials, I
would like to hear about it.)

Regards,
--
Nicolas George
Michael Niedermayer
2010-11-01 19:01:00 UTC
Permalink
On Mon, Nov 01, 2010 at 02:54:33PM +0100, Nicolas George wrote:
[...]
Post by Nicolas George
(On the other hand, if anyone knows a supported format that allows efficient
extraction of two 1-hour shows from a 3-hours recording with commercials, I
would like to hear about it.)
where is the problem with existing formats? mpeg4/h264/mp3/aac in nut?

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
Nicolas George
2010-11-01 20:37:36 UTC
Permalink
Post by Michael Niedermayer
Post by Nicolas George
(On the other hand, if anyone knows a supported format that allows efficient
extraction of two 1-hour shows from a 3-hours recording with commercials, I
would like to hear about it.)
where is the problem with existing formats? mpeg4/h264/mp3/aac in nut?
They require a lot of disc-to-disc copy. With the example I chose, the
original file will be about 6 giga-octets and requires two copies of
2 giga-octets each.

The format I have designed splits the video into fragments of about 1 minute
each, which makes them about 30 or 40 mega-octets, plus a global index.
Extracting a segments uses mostly hardlinks, only the index and the
fragments at the cut points are rebuilt. The whole thing is done in less
than one second. As a bonus, it works even if the disk space is tight.

Regards,
--
Nicolas George
Michael Niedermayer
2010-11-01 22:28:06 UTC
Permalink
Post by Nicolas George
Post by Michael Niedermayer
Post by Nicolas George
(On the other hand, if anyone knows a supported format that allows efficient
extraction of two 1-hour shows from a 3-hours recording with commercials, I
would like to hear about it.)
where is the problem with existing formats? mpeg4/h264/mp3/aac in nut?
They require a lot of disc-to-disc copy. With the example I chose, the
original file will be about 6 giga-octets and requires two copies of
2 giga-octets each.
The format I have designed splits the video into fragments of about 1 minute
each, which makes them about 30 or 40 mega-octets, plus a global index.
Extracting a segments uses mostly hardlinks, only the index and the
fragments at the cut points are rebuilt. The whole thing is done in less
than one second. As a bonus, it works even if the disk space is tight.
And you think you are the only person with this problem?
and thus there is no need to have this feature in svn?
and it would be better with a plugin architecture?

also the split program and using stdout with mpeg-ps or ts might already do
what you want approximately

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
Nicolas George
2010-11-02 00:00:00 UTC
Permalink
Post by Michael Niedermayer
And you think you are the only person with this problem?
and thus there is no need to have this feature in svn?
and it would be better with a plugin architecture?
I did not think that my ad-hoc hack was worthy of being proposed for
inclusion in ffmpeg. If someone here thinks otherwise, I'd be happy to
publish what I have done.
Post by Michael Niedermayer
also the split program and using stdout with mpeg-ps or ts might already do
what you want approximately
As Unix does not provide any API to split a big file or truncate it from the
beginning, I definitely need small fragments that can be moved
independently. And therefore either a new format or a new protocol so that
the video encoders and players see these fragments as a single vide.

The format of the packets in the fragments could indeed have been MPEG-PS or
MPEG-TS, and I hesitated, but in the end I decided they were too complex for
my needs, and used a custom simple header system.

Regards,
--
Nicolas George
Michael Niedermayer
2010-11-02 01:48:18 UTC
Permalink
Post by Nicolas George
Post by Michael Niedermayer
And you think you are the only person with this problem?
and thus there is no need to have this feature in svn?
and it would be better with a plugin architecture?
I did not think that my ad-hoc hack was worthy of being proposed for
inclusion in ffmpeg. If someone here thinks otherwise, I'd be happy to
publish what I have done.
Post by Michael Niedermayer
also the split program and using stdout with mpeg-ps or ts might already do
what you want approximately
As Unix does not provide any API to split a big file or truncate it from the
beginning, I definitely need small fragments that can be moved
ffmpeg -i blah /dev/stdout | split ...
?


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
Nicolas George
2010-11-02 21:09:17 UTC
Permalink
Post by Michael Niedermayer
ffmpeg -i blah /dev/stdout | split ...
?
And what do I do with the files produces by split? I can do nothing useful
with them without concatenating them again. I need to be able to play them
as a single file.

What I need, and what my custom format allows, is this:

(1) I have "recording.xxx", 6 Go, I can "mplayer recording.xxx" and play it
absolutely normally, including seeking.

(2) I can extract (using timestamps I found with any suitable interface) two
parts "program1.xxx" and "program2.xxx", 2 Go each.

(3) I can "mplayer programN.xxx" to check that nothing is wrong, and play
them absolutely normally, including seeking.

(4) I can then remove recording.xxx.

With the following requirements:

(A) Step (2) must be fast. Copying 2 Go of data for each extraction is not
acceptable.

(B) Step (4) must give me back the disk space corresponding to the parts of
the video I do not keep.

(C) (optionally) During step (3), disk space should not grow to much, actual
data should be mostly shared between recording.xxx and programN.xxx.
Actually, (C) is probably a direct consequence of (A).

It would be acceptable if recording.xxx was destroyed while creating
programN.xxx.

Condition (B) excludes having programN.xxx being just an edit list around
recording.xxx. In fact, since Unix does not allow splitting a file nor
truncating its beginning, conditions (A) and (B) pretty much imply that
recording.xxx must actually be a set of small files.

Which leaves the question: How do I make them appear as a single, seekable,
video, to ffmpeg / ffplay / mplayer?

I see three options:

(1) Use any concatenable, headerless format, and use something like FUSE to
make the small files appear as a single big file.

(2) Use any concatenable, headerless format, and design a custom URLProtocol
that virtually concatenates files.

(3) Design a format and the corresponding AVInputFormat.

I hesitated a lot between all three options, but in the end I chose (3).
Now, recording.ivd is in fact a directory with a single file "index" holding
the global headers and an index for seeks, and numbered files that hold the
actual payload with a simple header format.

Regards,
--
Nicolas George
Michael Niedermayer
2010-11-02 21:21:59 UTC
Permalink
Post by Nicolas George
Post by Michael Niedermayer
ffmpeg -i blah /dev/stdout | split ...
?
And what do I do with the files produces by split? I can do nothing useful
with them without concatenating them again. I need to be able to play them
as a single file.
cat files | ffmpeg
and that can be a subset with mpeg-ps/ts

beyond that it looks related to playlists

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
Nicolas George
2010-11-02 21:28:37 UTC
Permalink
Post by Michael Niedermayer
cat files | ffmpeg
... does not allow interactive seeking (assuming ffmpeg is replaced by
ffplay or mplayer) in the whole concatenated video.
Post by Michael Niedermayer
beyond that it looks related to playlists
There are similitudes indeed.

Regards,
--
Nicolas George
Stefano Sabatini
2010-11-02 21:39:46 UTC
Permalink
[...]
Post by Nicolas George
Which leaves the question: How do I make them appear as a single, seekable,
video, to ffmpeg / ffplay / mplayer?
(1) Use any concatenable, headerless format, and use something like FUSE to
make the small files appear as a single big file.
(2) Use any concatenable, headerless format, and design a custom URLProtocol
that virtually concatenates files.
Maybe I'm confused, but this seems related to the concat protocol.
--
FFmpeg = Fabulous and Fancy Marvellous Ponderous Elastic Guru
Nicolas George
2010-11-02 21:58:16 UTC
Permalink
Post by Stefano Sabatini
Maybe I'm confused, but this seems related to the concat protocol.
Indeed. But I wrote it six months before the concat protocol actually
entered ffmpeg, so I hat not that option at the time.

And now, the splitting interface somewhat rely on the format, so changing
would be a lot of work.

Regards,
--
Nicolas George
Jean-Daniel Dupas
2010-11-03 00:06:53 UTC
Permalink
Post by Nicolas George
Post by Michael Niedermayer
ffmpeg -i blah /dev/stdout | split ...
?
And what do I do with the files produces by split? I can do nothing useful
with them without concatenating them again. I need to be able to play them
as a single file.
(1) I have "recording.xxx", 6 Go, I can "mplayer recording.xxx" and play it
absolutely normally, including seeking.
(2) I can extract (using timestamps I found with any suitable interface) two
parts "program1.xxx" and "program2.xxx", 2 Go each.
(3) I can "mplayer programN.xxx" to check that nothing is wrong, and play
them absolutely normally, including seeking.
(4) I can then remove recording.xxx.
(A) Step (2) must be fast. Copying 2 Go of data for each extraction is not
acceptable.
(B) Step (4) must give me back the disk space corresponding to the parts of
the video I do not keep.
(C) (optionally) During step (3), disk space should not grow to much, actual
data should be mostly shared between recording.xxx and programN.xxx.
Actually, (C) is probably a direct consequence of (A).
[…]
(1) Use any concatenable, headerless format, and use something like FUSE to
make the small files appear as a single big file.
(2) Use any concatenable, headerless format, and design a custom URLProtocol
that virtually concatenates files.
(3) Design a format and the corresponding AVInputFormat.
(4) Using MPEG-4 and external references instead of rewriting a format from scratch.

-- Jean-Daniel
Nicolas George
2010-11-03 00:11:30 UTC
Permalink
Post by Jean-Daniel Dupas
(4) Using MPEG-4 and external references instead of rewriting a format from scratch.
Could you give me more details about what kind of external references you
are thinking about?

As a side note, I needed a format that could store the packets as demuxed
from the DVB recorder: MPEG-2 video, MP2 audio, DVB subtitles.

Regards,
--
Nicolas George
Baptiste Coudurier
2010-11-03 00:28:37 UTC
Permalink
Post by Nicolas George
Post by Jean-Daniel Dupas
(4) Using MPEG-4 and external references instead of rewriting a format from scratch.
Could you give me more details about what kind of external references you
are thinking about?
The data is not actually stored in the file, but in a different file.
The header index the data in different files.
MOV/MP4 can do that.
Post by Nicolas George
As a side note, I needed a format that could store the packets as demuxed
from the DVB recorder: MPEG-2 video, MP2 audio, DVB subtitles.
MOV can do that except the DVB subtitles, however I know that they
standardized the storage of transport streams in ISO media for settop
boxes mainly, so I guess there might be a way to store the subtitles as
well.
--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
Aurelien Jacobs
2010-11-03 00:32:07 UTC
Permalink
Post by Nicolas George
Post by Jean-Daniel Dupas
(4) Using MPEG-4 and external references instead of rewriting a format from scratch.
Could you give me more details about what kind of external references you
are thinking about?
I don't really know details about mov, but indeed it is capable of
containing "links" to other files.
Matroska has some similar features. You can get a good idea of the
features here: http://mod16.org/hurfdurf/?p=8
One common use of this feature is to store a whole bunch of episode of a
TV serie, but store the opening theme only once in a separate file. Still
each episode will play fully, including the opening theme.
I think it would fulfill your usecase perfectly.

lavf don't support those features yet (neither in movnor mkv), but
patches would be welcome. I think the main problem is to decide of a
proper API to expose this.
Post by Nicolas George
As a side note, I needed a format that could store the packets as demuxed
from the DVB recorder: MPEG-2 video, MP2 audio, DVB subtitles.
Matroska should support all of this.

Aurel
Alexander Strange
2010-11-03 00:46:31 UTC
Permalink
Post by Aurelien Jacobs
Post by Nicolas George
Post by Jean-Daniel Dupas
(4) Using MPEG-4 and external references instead of rewriting a format from scratch.
Could you give me more details about what kind of external references you
are thinking about?
I don't really know details about mov, but indeed it is capable of
containing "links" to other files.
Matroska has some similar features. You can get a good idea of the
features here: http://mod16.org/hurfdurf/?p=8
One common use of this feature is to store a whole bunch of episode of a
TV serie, but store the opening theme only once in a separate file. Still
each episode will play fully, including the opening theme.
I think it would fulfill your usecase perfectly.
Matroska can only link other matroska files. mov's data references don't imply anything about the referenced file, so you can use it for anything you want.
Except that it can't reference TS files, because IIRC they don't have contiguous packets in the file. So even that would still require copying data out of the original file.
Nicolas George
2010-11-04 19:24:46 UTC
Permalink
Post by Alexander Strange
Post by Aurelien Jacobs
I don't really know details about mov, but indeed it is capable of
containing "links" to other files.
Matroska has some similar features. You can get a good idea of the
features here: http://mod16.org/hurfdurf/?p=8
One common use of this feature is to store a whole bunch of episode of a
TV serie, but store the opening theme only once in a separate file. Still
each episode will play fully, including the opening theme.
I think it would fulfill your usecase perfectly.
Matroska can only link other matroska files. mov's data references don't
imply anything about the referenced file, so you can use it for anything
you want.
Except that it can't reference TS files, because IIRC they don't have
contiguous packets in the file. So even that would still require copying
data out of the original file.
I see. Thanks to you both for those details. It seems this is still
uncharted territory, with a lot of new code needed to achieve anything. The
system I have designed two years ago works satisfactorily, and I have no
spare time to re-work it in depth, so I will leave it as is for now.

If people here want, I can give the technical details and the code for the
tools I have written. If not, I think I can stop this discussion here.

Regards,
--
Nicolas George
Tomas Härdin
2010-11-02 07:06:26 UTC
Permalink
Post by Nicolas George
Post by Michael Niedermayer
Post by Nicolas George
(On the other hand, if anyone knows a supported format that allows efficient
extraction of two 1-hour shows from a 3-hours recording with commercials, I
would like to hear about it.)
where is the problem with existing formats? mpeg4/h264/mp3/aac in nut?
They require a lot of disc-to-disc copy. With the example I chose, the
original file will be about 6 giga-octets and requires two copies of
2 giga-octets each.
The format I have designed splits the video into fragments of about 1 minute
each, which makes them about 30 or 40 mega-octets, plus a global index.
Extracting a segments uses mostly hardlinks, only the index and the
fragments at the cut points are rebuilt. The whole thing is done in less
than one second. As a bonus, it works even if the disk space is tight.
Just use mov. It supports this via edit lists and drefs. The lavf
demuxer doesn't support edit lists yet though - patch welcome for that I
suppose.

You still need to split the stream up into separate files, but something
like what Michael suggested probably works. Otherwise you could add an
option to ffmpeg so it starts new files every X seconds, like -fragment
60 output%d.mov or something like that.

/Tomas
Peter Ross
2010-11-02 02:01:29 UTC
Permalink
Post by Nicolas George
Post by Michael Niedermayer
I agree with ronald that a plugin architecture wont do us nor our users any
good.
My reason for implementing it yesterday, apart from the fact that some
people did manifest interest about it on the mailing lists some time ago,
For a DVB-grabber/player system I maintain, I have designed a custom storage
format, because none of the existing formats suited my needs. A dynamic
loading system would have slightly simplified upgrades of the video tools,
even making it possible to use the distro's versions (if someday they become
decent).
FFmpeg is not allergic to custom storage formats, so why not add it to libavformat
and be done with it?

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
Felipe Contreras
2010-11-02 12:36:02 UTC
Permalink
On Mon, Nov 1, 2010 at 3:54 PM, Nicolas George
Post by Nicolas George
Post by Michael Niedermayer
I agree with ronald that a plugin architecture wont do us nor our users any
good.
My reason for implementing it yesterday, apart from the fact that some
people did manifest interest about it on the mailing lists some time ago,
For a DVB-grabber/player system I maintain, I have designed a custom storage
format, because none of the existing formats suited my needs. A dynamic
loading system would have slightly simplified upgrades of the video tools,
even making it possible to use the distro's versions (if someday they become
decent).
Anyway, I understand perfectly why most people here do not like the idea of
a plugin system, and I do not intend to insist for its inclusion. But I have
spotted a few logical flaws in the argument that have been stated, and I can
not resist answering them.
The main flaw is that the cat is now out of the box: any GPL abuser can
download my patch from the mailing-list archives, apply it and use it to
load its proprietary code. And even without it, what I have written
yesterday, any half-decent coding monkey working for said GPL abuser could
have coded too. And if that was not enough, using LD_PRELOAD also allows to
add plugins to ffmpeg.
I think this is a main feature missing from FFmpeg, and I planned to
do this myself. So, thanks for doing this :)

In fact, I think if this is not accepted in the main branch, I would
push anyway to get it into MeeGo as it would be the only way to get it
there. In fact, probably all distributions would want this, as it's
the only sensible way to package FFmpeg.
Post by Nicolas George
As for the concern about stability and security, I believe it is the concern
of people who decide to load crappy plugins in their ffmpeg, either with a
published interface or with LD_PRELOAD.
The problem in Firefox is not that it has an extension mechanism, it's that
the core developers have taken it as an excuse not to do their job
completely: "this crucial feature is missing? just write an extension", with
all the problems that implies (out of date bitrotting extensions, forks).
As far as I can see, the only security issue with this patch is that some
half-baked privilege escalation systems will sanitize LD_PRELOAD and not
AV_PLUGIN_PATH.
For security freaks there's the option to disable this.
--
Felipe Contreras
Stefano Sabatini
2010-11-01 14:30:19 UTC
Permalink
Post by Michael Niedermayer
Post by Ronald S. Bultje
Hi,
On Sun, Oct 31, 2010 at 9:42 AM, Nicolas George
Post by Nicolas George
There is probably much to discuss, but at the very least, it works to simply
add support for a new format in lavf by just dropping a file in a directory.
Codecs and filters should work just the same.
Let's just go over the big phat elephant in the room. Is this an advantage?
i was starting to be scared and surprised that noone was bringing the "why"
up already.
Post by Ronald S. Bultje
I used to think this kind of stuff was good. But is there really an
- no strong license enforcement because you can separate shipping of
software pieces that have strictly incompatible licenses
- security becomes worthless, any plugin can exploit a system
- stability becomes a nightmare as soon as you start thinking about
possibly updating ABI/API
- dynamic plugins won't share code with the main source tree, which
means that the best point of FFmpeg - fast and lean - no longer
applies
- companies can suddenly get away with releasing a binary plus FFmpeg
wrapper code. This is _bad_. We don't want to promote this kind of
silliness in any way
If people want a massive, slow, insecure licensing headache that has
something to do with multimedia, they can install one of the many
"multimedia frameworks" that were created to """solve""" this problem.
Right?
It also reminds me of firefox, huge numbers of plugins, the basic browser
lacks huge amounts of basic functionality (resuming downloads, enabling
cookies & scripts per site & blocking well known addvertisement/spy sites)
what should be is firefox should include all that is usefull and that should
be properly checked for being securely implemented.
I agree with ronald that a plugin architecture wont do us nor our users any
good.
Sometimes I fancied with the idea of a plugin system, for example you
could have a set of plugin filters which are too specific or are
simply not worth to be committed to the main repo. Having a plugin
system would simplify the use of those plugins (no need to
patch+compile FFmpeg).

Anyway I'm also concerned with licensing, stability, and maintanance
issues so I tend to prefer to avoid to open that can of worms (and for
filters people can still use frei0r/ladspa plugins).

It is also interesting to note that FFmpeg as a community shines
another time for its diversity, indeed most software projects consider
plugins just "a good thing (TM)" (on the other hand most software
projects are bug-ridden and bloated, so there is not much to learn
from them...).
--
FFmpeg = Free and Forgiving Monstrous Peaceless Enhancing Generator
Diego Biurrun
2010-11-02 23:56:33 UTC
Permalink
Since we're already offtopic...
Post by Michael Niedermayer
It also reminds me of firefox, huge numbers of plugins, the basic browser
lacks huge amounts of basic functionality (resuming downloads, enabling
cookies & scripts per site & blocking well known addvertisement/spy sites)
I think Firefox does all of this except for per-site scripts out-of-the-box.

Diego
Michael Niedermayer
2010-11-03 01:53:17 UTC
Permalink
Post by Diego Biurrun
Since we're already offtopic...
Post by Michael Niedermayer
It also reminds me of firefox, huge numbers of plugins, the basic browser
lacks huge amounts of basic functionality (resuming downloads, enabling
cookies & scripts per site & blocking well known addvertisement/spy sites)
I think Firefox does all of this except for per-site scripts out-of-the-box.
mine definitly does not resume downloads (and wget did succeed resuming)
block google analytics, adsense, ... not as far as i know, yeah these dont
leave a vissual trace like add banners but they serve no purpose except
collecting statistics that the user likely doesnt want collected if he did knew
they are being collected

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
Luca Barbato
2010-11-02 09:29:59 UTC
Permalink
Post by Ronald S. Bultje
I used to think this kind of stuff was good. But is there really an
- no strong license enforcement because you can separate shipping of
software pieces that have strictly incompatible licenses
You can already if you want in the application
Post by Ronald S. Bultje
- security becomes worthless, any plugin can exploit a system
So the application
Post by Ronald S. Bultje
- stability becomes a nightmare as soon as you start thinking about
possibly updating ABI/API
Any application have to care about it
Post by Ronald S. Bultje
- dynamic plugins won't share code with the main source tree, which
means that the best point of FFmpeg - fast and lean - no longer
applies
No different than features implemented in the main application IMHO
Post by Ronald S. Bultje
- companies can suddenly get away with releasing a binary plus FFmpeg
wrapper code. This is _bad_. We don't want to promote this kind of
silliness in any way
Not that companies aren't already doing that using wrapper/abstraction
libraries
Post by Ronald S. Bultje
If people want a massive, slow, insecure licensing headache that has
something to do with multimedia, they can install one of the many
"multimedia frameworks" that were created to """solve""" this problem.
Right?
Right.

In short: the trick is nice to extend ffmpeg and ffplay, but doesn't add
or subtract much beside making harder to track bugs to disingenuous
people not updating the plugins while updating ffmpeg.

I think we could check the concept if there is a compelling use case or
enough users want the feature.

lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
Ronald S. Bultje
2010-11-02 11:21:25 UTC
Permalink
Hi,
Post by Luca Barbato
Post by Ronald S. Bultje
I used to think this kind of stuff was good. But is there really an
- no strong license enforcement because you can separate shipping of
software pieces that have strictly incompatible licenses
You can already if you want in the application
Post by Ronald S. Bultje
- security becomes worthless, any plugin can exploit a system
So the application
Post by Ronald S. Bultje
- stability becomes a nightmare as soon as you start thinking about
possibly updating ABI/API
Any application have to care about it
Post by Ronald S. Bultje
- dynamic plugins won't share code with the main source tree, which
means that the best point of FFmpeg - fast and lean - no longer
applies
No different than features implemented in the main application IMHO
The difference is that if one application becomes "problematic", users
will simply not start the application anymore if it's unsafe /
unstable, and we're done. No more problem.

In the real world, if installing a new application ("ConvertYtoCVC")
with a custom codec causes my Chrome to suddenly crash and become
exploitable, we are in deep PR shit. There is no way to save ourselves
from that mess.

Ronald
Luca Barbato
2010-11-02 13:30:34 UTC
Permalink
Post by Ronald S. Bultje
In the real world, if installing a new application ("ConvertYtoCVC")
with a custom codec causes my Chrome to suddenly crash and become
exploitable, we are in deep PR shit. There is no way to save ourselves
from that mess.
In the real world having your application replacing libavcodec or an
other system lib is bad nonetheless.

lu
Ronald S. Bultje
2010-11-02 13:42:29 UTC
Permalink
Hi,
Post by Ronald S. Bultje
In the real world, if installing a new application ("ConvertYtoCVC")
with a custom codec causes my Chrome to suddenly crash and become
exploitable, we are in deep PR shit. There is no way to save ourselves
from that mess.
In the real world having your application replacing libavcodec or an other
system lib is bad nonetheless.
They shouldn't. They should send us a patch so we can update
libavcodec for them, after proper review and so on. This is what makes
FFmpeg so great.

Ronald
Felipe Contreras
2010-11-02 19:22:40 UTC
Permalink
Post by Ronald S. Bultje
In the real world, if installing a new application ("ConvertYtoCVC")
with a custom codec causes my Chrome to suddenly crash and become
exploitable, we are in deep PR shit. There is no way to save ourselves
from that mess.
In the real world having your application replacing libavcodec or an other
system lib is bad nonetheless.
Chrome doesn't use the system's FFmpeg, it has it's own built-in
protected in a sandbox. They would build it with this option disabled.
Not relevant.
--
Felipe Contreras
Luca Barbato
2010-11-02 21:00:58 UTC
Permalink
Post by Felipe Contreras
Post by Ronald S. Bultje
In the real world, if installing a new application ("ConvertYtoCVC")
with a custom codec causes my Chrome to suddenly crash and become
exploitable, we are in deep PR shit. There is no way to save ourselves
from that mess.
In the real world having your application replacing libavcodec or an other
system lib is bad nonetheless.
Chrome doesn't use the system's FFmpeg, it has it's own built-in
protected in a sandbox. They would build it with this option disabled.
Not relevant.
Chrome isn't the point. The point is having an application messing with
system libraries.

lu
Felipe Contreras
2010-11-02 12:23:56 UTC
Permalink
Post by Ronald S. Bultje
On Sun, Oct 31, 2010 at 9:42 AM, Nicolas George
Post by Nicolas George
There is probably much to discuss, but at the very least, it works to simply
add support for a new format in lavf by just dropping a file in a directory.
Codecs and filters should work just the same.
Let's just go over the big phat elephant in the room. Is this an advantage?
Of course it is is!

There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.

This is solved in GStreamer by having a separate package for the core,
and the patent encumbered plugins. The third party repo provides the
codec packages that get installed into /usr/lib/gstreamer-0.10, and
voilá, you have support for all the codecs. There's even on-the-fly
codec installation support so when trying to play a clip, you get
asked if you want to install the codec package.

Personally I think it's a shame that FFmpeg is not shipped in such
important distributions just because of this reason. And of course if
your package depends on FFmpeg, then you are out of the distro as
well.
--
Felipe Contreras
Ronald S. Bultje
2010-11-02 12:39:24 UTC
Permalink
Hi,

On Tue, Nov 2, 2010 at 8:23 AM, Felipe Contreras
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
You know Fedora + MeeGo together have a market share of like 0.01%,
right? That's not a lot of leverage.

Ronald
Diego Biurrun
2010-11-02 13:09:51 UTC
Permalink
Post by Felipe Contreras
Personally I think it's a shame that FFmpeg is not shipped in such
important distributions just because of this reason.
How many people here have even heard of meego and how many use Fedora
(on their desktops)? Nowadays FFmpeg is available in all mainstream
distributions, it's just the fringe ones that are missing, see

http://wiki.multimedia.cx/index.php?title=FFmpeg_distribution_status

BTW, if you have information to contribute to that package, let me know.

Diego
Gwenole Beauchesne
2010-11-02 13:26:38 UTC
Permalink
Post by Diego Biurrun
http://wiki.multimedia.cx/index.php?title=FFmpeg_distribution_status
BTW, if you have information to contribute to that package, let me know.
Talking of which, I would say to s/after 10\.04/& 10.10/. i.e.
Ubuntu/maverick is 10.10. 10.04 (lucid) had 0.5.1.

Regards,
Gwenole.
Felipe Contreras
2010-11-02 18:53:47 UTC
Permalink
Post by Diego Biurrun
Post by Felipe Contreras
Personally I think it's a shame that FFmpeg is not shipped in such
important distributions just because of this reason.
How many people here have even heard of meego and how many use Fedora
(on their desktops)?
Who cares what people here have heard of? Presumably for your argument
what matters is what people _out there_ use.
Post by Diego Biurrun
Nowadays FFmpeg is available in all mainstream
distributions, it's just the fringe ones that are missing, see
http://wiki.multimedia.cx/index.php?title=FFmpeg_distribution_status
BTW, if you have information to contribute to that package, let me know.
Are you saying Fedora is a fringe distribution?

The mainstream distributions are:
1. Ubuntu
2. Fedora
3. Mint
4. OpenSUSE
5. Debian

http://distrowatch.com/

If you have evidence that suggests otherwise it would be nice to see that.
--
Felipe Contreras
Ronald S. Bultje
2010-11-02 19:18:57 UTC
Permalink
Hi,

On Tue, Nov 2, 2010 at 2:53 PM, Felipe Contreras
 1. Ubuntu
 2. Fedora
 3. Mint
 4. OpenSUSE
 5. Debian
Your statistics is a tracker of fanboys clicking "me too" buttons.
Real stats come from e.g. daily data-usage over large ranges of
websites, e.g. NetApplications. See
http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10
for a quick overview, also see
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=8

Details:
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Linux
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Windows
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Mac
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Android
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=iOS
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Blackberry

Quick breakdown:
Windows is 91%
Mac is 5%
iOS (iPad/iPhone) is 1.25%
Linux - for all of the above distributions together - is 0.86%, and going down
Android is 0.27%
Blackberry is 0.10%
(all mobiles are going up)

http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0

Chrome is fine with FFmpeg and has a market share tenfold of all Linux together.

http://www.videolan.org/vlc/

VLC is fine with FFmpeg and had 177 million downloads since their 1.0 release.

Fedora 13 has 2.5M users according to Fedora. Ubuntu claims 12M users.
Not very much. Fantastic market share indeed. Let's all roll over and
play dead for Fedora.

Ronald
Felipe Contreras
2010-11-02 19:31:17 UTC
Permalink
Post by Ronald S. Bultje
On Tue, Nov 2, 2010 at 2:53 PM, Felipe Contreras
 1. Ubuntu
 2. Fedora
 3. Mint
 4. OpenSUSE
 5. Debian
Your statistics is a tracker of fanboys clicking "me too" buttons.
Real stats come from e.g. daily data-usage over large ranges of
websites, e.g. NetApplications. See
http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10
for a quick overview, also see
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=8
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Linux
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Windows
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Mac
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Android
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=iOS
http://www.netmarketshare.com/report.aspx?qprid=9&qpcustom=Blackberry
Windows is 91%
Mac is 5%
iOS (iPad/iPhone) is 1.25%
Linux - for all of the above distributions together - is 0.86%, and going down
Android is 0.27%
Blackberry is 0.10%
(all mobiles are going up)
We were talking about *linux* distributions.
Post by Ronald S. Bultje
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0
Chrome is fine with FFmpeg and has a market share tenfold of all Linux together.
Nobody said otherwise.
Post by Ronald S. Bultje
http://www.videolan.org/vlc/
VLC is fine with FFmpeg and had 177 million downloads since their 1.0 release.
Nobody said otherwise.
Post by Ronald S. Bultje
Fedora 13 has 2.5M users according to Fedora. Ubuntu claims 12M users.
Not very much. Fantastic market share indeed. Let's all roll over and
play dead for Fedora.
So what you are saying is: "we don't care about linux". Ok, that's good to know.
--
Felipe Contreras
Ronald S. Bultje
2010-11-02 19:37:54 UTC
Permalink
Hi,

On Tue, Nov 2, 2010 at 3:31 PM, Felipe Contreras
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Fedora != Linux. I'm saying Fedora doesn't have enough leverage to
force us to shoot ourselves.

Ronald
Michael Niedermayer
2010-11-02 20:14:36 UTC
Permalink
Post by Ronald S. Bultje
Hi,
On Tue, Nov 2, 2010 at 3:31 PM, Felipe Contreras
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Fedora != Linux. I'm saying Fedora doesn't have enough leverage to
force us to shoot ourselves.
Carefull ronald, you are falling in that guys trap
ffmpeg works fine on fedora
noone from fedora asked us to change anything
so its not even "we dont care about fedora"
we do care about all distros and their maintainers official requests.

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
Felipe Contreras
2010-11-02 21:27:57 UTC
Permalink
Post by Michael Niedermayer
Post by Ronald S. Bultje
On Tue, Nov 2, 2010 at 3:31 PM, Felipe Contreras
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Fedora != Linux. I'm saying Fedora doesn't have enough leverage to
force us to shoot ourselves.
Carefull ronald, you are falling in that guys trap
ffmpeg works fine on fedora
noone from fedora asked us to change anything
so its not even "we dont care about fedora"
we do care about all distros and their maintainers official requests.
There's no FFmpeg in Fedora:
https://admin.fedoraproject.org/pkgdb/acls/list/*ffmpeg*

Nobody has asked you to change anything because they decided not to
use it, and instead use GStreamer with libraries such as libvorbis and
libvpx.

*If* patent encumbered codecs could be installed as plugins, then the
situation might change.
--
Felipe Contreras
Ronald S. Bultje
2010-11-02 21:29:31 UTC
Permalink
Hi,

On Tue, Nov 2, 2010 at 5:27 PM, Felipe Contreras
Post by Felipe Contreras
*If* patent encumbered codecs could be installed as plugins, then the
situation might change.
"might" is a great reason to accept a controversial patch.

Ronald
Michael Niedermayer
2010-11-02 21:44:01 UTC
Permalink
Post by Felipe Contreras
Post by Michael Niedermayer
Post by Ronald S. Bultje
On Tue, Nov 2, 2010 at 3:31 PM, Felipe Contreras
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Fedora != Linux. I'm saying Fedora doesn't have enough leverage to
force us to shoot ourselves.
Carefull ronald, you are falling in that guys trap
ffmpeg works fine on fedora
noone from fedora asked us to change anything
so its not even "we dont care about fedora"
we do care about all distros and their maintainers official requests.
https://admin.fedoraproject.org/pkgdb/acls/list/*ffmpeg*
theres a compiler in fedora, and theres ./configure && make
Post by Felipe Contreras
Nobody has asked you to change anything because they decided not to
use it, and instead use GStreamer with libraries such as libvorbis and
libvpx.
did they obtain libvpx patent licenses too or do they belive that the code
is not patent encumbered?
Post by Felipe Contreras
*If* patent encumbered codecs could be installed as plugins, then the
situation might change.
you should talk to the people from fedora and find out what their point of
view is on these things and not argue here that they _might_ something


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
Felipe Contreras
2010-11-02 22:20:34 UTC
Permalink
Post by Michael Niedermayer
Post by Felipe Contreras
Post by Michael Niedermayer
Post by Ronald S. Bultje
On Tue, Nov 2, 2010 at 3:31 PM, Felipe Contreras
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Fedora != Linux. I'm saying Fedora doesn't have enough leverage to
force us to shoot ourselves.
Carefull ronald, you are falling in that guys trap
ffmpeg works fine on fedora
noone from fedora asked us to change anything
so its not even "we dont care about fedora"
we do care about all distros and their maintainers official requests.
https://admin.fedoraproject.org/pkgdb/acls/list/*ffmpeg*
theres a compiler in fedora, and theres ./configure && make
That doesn't say anything. If you can compile FFmpeg on Windows that
doesn't mean Microsoft has no problem with FFmpeg.
Post by Michael Niedermayer
Post by Felipe Contreras
Nobody has asked you to change anything because they decided not to
use it, and instead use GStreamer with libraries such as libvorbis and
libvpx.
did they obtain libvpx patent licenses too or do they belive that the code
is not patent encumbered?
Why would that even matter for this discussion? Anyway, it's about
philosophy, not legality.
Post by Michael Niedermayer
Post by Felipe Contreras
*If* patent encumbered codecs could be installed as plugins, then the
situation might change.
you should talk to the people from fedora and find out what their point of
view is on these things and not argue here that they _might_ something
There is no other reason why a distribution would not be shipping
FFmpeg. I can tell you this is the reason in MeeGo.

Anyway, if the Fedora board officially requests a pluggable
architecture, will it happen?
--
Felipe Contreras
Ronald S. Bultje
2010-11-02 23:03:37 UTC
Permalink
Hi,

On Tue, Nov 2, 2010 at 6:20 PM, Felipe Contreras
Post by Felipe Contreras
Anyway, if the Fedora board officially requests a pluggable
architecture, will it happen?
Seems highly speculative; will they pay for it?

Ronald
Felipe Contreras
2010-11-06 08:57:41 UTC
Permalink
Post by Ronald S. Bultje
On Tue, Nov 2, 2010 at 6:20 PM, Felipe Contreras
Post by Felipe Contreras
Anyway, if the Fedora board officially requests a pluggable
architecture, will it happen?
Seems highly speculative; will they pay for it?
So that's a no. You don't care about Fedora, even if it's the #2
distribution out there, just say so and save us time.
--
Felipe Contreras
Michael Niedermayer
2010-11-03 02:10:59 UTC
Permalink
Post by Felipe Contreras
Post by Michael Niedermayer
Post by Felipe Contreras
Post by Michael Niedermayer
Post by Ronald S. Bultje
On Tue, Nov 2, 2010 at 3:31 PM, Felipe Contreras
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Fedora != Linux. I'm saying Fedora doesn't have enough leverage to
force us to shoot ourselves.
Carefull ronald, you are falling in that guys trap
ffmpeg works fine on fedora
noone from fedora asked us to change anything
so its not even "we dont care about fedora"
we do care about all distros and their maintainers official requests.
https://admin.fedoraproject.org/pkgdb/acls/list/*ffmpeg*
theres a compiler in fedora, and theres ./configure && make
That doesn't say anything. If you can compile FFmpeg on Windows that
doesn't mean Microsoft has no problem with FFmpeg.
yes and it doesnt matter
ffmpeg exists and works on ms windows, so does it on fedora.
We dont live in soviet russia where someones "problems" dictate what the users
can use
Post by Felipe Contreras
Post by Michael Niedermayer
Post by Felipe Contreras
Nobody has asked you to change anything because they decided not to
use it, and instead use GStreamer with libraries such as libvorbis and
libvpx.
did they obtain libvpx patent licenses too or do they belive that the code
is not patent encumbered?
Why would that even matter for this discussion?
because it was argued the inclusion was related to patent encumberedness
and inclusion of libvpx is a act of hypocrisy in that light.
Not that it matters but its entertaining
Post by Felipe Contreras
Anyway, it's about
philosophy, not legality.
exactly, the discussion is about some quite retarded philosophy neither
technically nor legally real things.
I wonder if theres a relation to fedoras market share and that
Post by Felipe Contreras
Post by Michael Niedermayer
Post by Felipe Contreras
*If* patent encumbered codecs could be installed as plugins, then the
situation might change.
you should talk to the people from fedora and find out what their point of
view is on these things and not argue here that they _might_ something
There is no other reason why a distribution would not be shipping
FFmpeg. I can tell you this is the reason in MeeGo.
There are many reasons, for example there might be a distro that is
targeted toward devices that have no multimedia capabilities.
That said discussion with MeeGo or fedora people is welcome as that may lead
to improvments in ffmpeg as well as in MeeGo/fedora

OTOH discussion with you is welcome for the entertainment value only,
i have no hope that this could lead to any improvments in ffmpeg.
Post by Felipe Contreras
Anyway, if the Fedora board officially requests a pluggable
architecture, will it happen?
Discussion between the ffmpeg developers and the board would happen in this
case so we better understand the reasons and needs and if another solution is
maybe supperior for fedora.

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
Anatoly Nenashev
2010-11-03 09:04:40 UTC
Permalink
Post by Michael Niedermayer
yes and it doesnt matter
ffmpeg exists and works on ms windows, so does it on fedora.
We dont live in soviet russia where someones "problems" dictate what the users
can use
And where bears walking on the streets and playing balalaika.
Alex Converse
2010-11-03 05:55:45 UTC
Permalink
On Tue, Nov 2, 2010 at 2:27 PM, Felipe Contreras
Post by Felipe Contreras
Post by Michael Niedermayer
Post by Ronald S. Bultje
On Tue, Nov 2, 2010 at 3:31 PM, Felipe Contreras
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Fedora != Linux. I'm saying Fedora doesn't have enough leverage to
force us to shoot ourselves.
Carefull ronald, you are falling in that guys trap
ffmpeg works fine on fedora
noone from fedora asked us to change anything
so its not even "we dont care about fedora"
we do care about all distros and their maintainers official requests.
https://admin.fedoraproject.org/pkgdb/acls/list/*ffmpeg*
Nobody has asked you to change anything because they decided not to
use it, and instead use GStreamer with libraries such as libvorbis and
libvpx.
*If* patent encumbered codecs could be installed as plugins, then the
situation might change.
Fedora's policy objections against FFmpeg seem to go farther than
individual codecs. They object to chromium's branch of FFmpeg mt which
only supports ogg, webm, and wav demuxers and vp8, theora, vorbis, and
s16le/u8 pcm decoders.

Splitting off the MPEG codecs would have huge implications on dsputil,
the magic smoke behind FFmpeg
http://blogs.gnome.org/rbultje/2010/06/27/googles-vp8-video-codec/
Felipe Contreras
2010-11-02 21:23:01 UTC
Permalink
Post by Ronald S. Bultje
On Tue, Nov 2, 2010 at 3:31 PM, Felipe Contreras
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Fedora != Linux. I'm saying Fedora doesn't have enough leverage to
force us to shoot ourselves.
Fedora is the #2 distribution out there. I asked for evidence stating
otherwise, that it's a fringe distribution, and all I got from you is
numbers showing that linux has no market share.

Now, do you have numbers showing Fedora is not #2, or are you saying
that you only care about Ubuntu?
--
Felipe Contreras
Ronald S. Bultje
2010-11-02 21:28:33 UTC
Permalink
Hi,

On Tue, Nov 2, 2010 at 5:23 PM, Felipe Contreras
Post by Felipe Contreras
Post by Ronald S. Bultje
On Tue, Nov 2, 2010 at 3:31 PM, Felipe Contreras
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Fedora != Linux. I'm saying Fedora doesn't have enough leverage to
force us to shoot ourselves.
Fedora is the #2 distribution out there. I asked for evidence stating
otherwise, that it's a fringe distribution, and all I got from you is
numbers showing that linux has no market share.
Now, do you have numbers showing Fedora is not #2
or are you saying that you only care about Ubuntu?
No.

Ronald
Luca Barbato
2010-11-02 21:10:51 UTC
Permalink
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Other way round.

I could say that Gentoo does care about FFmpeg, same could be said for
Ubuntu, Google, VLC and so on.

as I wrote a minimal libavcodec is easy to get swap this one for the
full feature one is easy as well.

I don't see your use case compelling.

lu
Felipe Contreras
2010-11-02 21:40:34 UTC
Permalink
Post by Luca Barbato
Post by Felipe Contreras
So what you are saying is: "we don't care about linux". Ok, that's good to know.
Other way round.
I could say that Gentoo does care about FFmpeg, same could be said for
Ubuntu, Google, VLC and so on.
No. It's their own specific circumstances that allows them to use
FFmpeg. Fedora has taken a stance against software that can be patent
encumbered. Neither Ubuntu, Google, and VLC have any philosophical
issues with patented codecs, so they can use FFmpeg just fine.
Post by Luca Barbato
as I wrote a minimal libavcodec is easy to get swap this one for the full
feature one is easy as well.
I don't see your use case compelling.
Sure, _you_ can do that, but that's not how packaging works. A package
owns a file, and having multiple packages owning the same file is just
asking for trouble.
--
Felipe Contreras
Luca Barbato
2010-11-03 02:10:25 UTC
Permalink
Post by Felipe Contreras
Sure, _you_ can do that, but that's not how packaging works. A package
owns a file, and having multiple packages owning the same file is just
asking for trouble.
maybe then it would be better to ditch rpm and move to something else
say deb or even tbz2 (gentoo's binary packaging)...

If other can do that why Fedora couldn't?

lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
Felipe Contreras
2010-11-06 08:55:32 UTC
Permalink
Post by Luca Barbato
Post by Felipe Contreras
Sure, _you_ can do that, but that's not how packaging works. A package
owns a file, and having multiple packages owning the same file is just
asking for trouble.
maybe then it would be better to ditch rpm and move to something else
say deb or even tbz2 (gentoo's binary packaging)...
It's the same on dpkg.
--
Felipe Contreras
Jean-Baptiste Kempf
2010-11-03 10:53:03 UTC
Permalink
Hello,
Post by Felipe Contreras
No. It's their own specific circumstances that allows them to use
FFmpeg. Fedora has taken a stance against software that can be patent
encumbered. Neither Ubuntu, Google, and VLC have any philosophical
issues with patented codecs, so they can use FFmpeg just fine.
How can Fedora run at all when menus, double-click and most part of UIs
are patented?

Moreover, patents in what country?
The main VLC distribution is done by VideoLAN, which is French, which
has to follow French law.
How can you account about our "philosophical" ideas, without even
discussing to us?

Best Regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
+33 672 704 734
Jason Garrett-Glaser
2010-11-03 11:02:14 UTC
Permalink
Post by Jean-Baptiste Kempf
Hello,
Post by Felipe Contreras
No. It's their own specific circumstances that allows them to use
FFmpeg. Fedora has taken a stance against software that can be patent
encumbered. Neither Ubuntu, Google, and VLC have any philosophical
issues with patented codecs, so they can use FFmpeg just fine.
How can Fedora run at all when menus, double-click and most part of UIs
are patented?
Freetards are only against "patented software" when it serves their
agenda. When someone points out that their software violates patents,
those cases don't matter. It's only when software they don't like
violates patents that they oppose it.

Dark Shikari
Diego Biurrun
2010-11-02 23:54:51 UTC
Permalink
Post by Felipe Contreras
Post by Diego Biurrun
Post by Felipe Contreras
Personally I think it's a shame that FFmpeg is not shipped in such
important distributions just because of this reason.
How many people here have even heard of meego and how many use Fedora
(on their desktops)?
Who cares what people here have heard of? Presumably for your argument
what matters is what people _out there_ use.
Correct, this is exactly my point. I have never seen anybody "out there"
use either.
Post by Felipe Contreras
Post by Diego Biurrun
Nowadays FFmpeg is available in all mainstream
distributions, it's just the fringe ones that are missing, see
http://wiki.multimedia.cx/index.php?title=FFmpeg_distribution_status
BTW, if you have information to contribute to that package, let me know.
Are you saying Fedora is a fringe distribution?
A fringe desktop distribution, yes.
Post by Felipe Contreras
1. Ubuntu
2. Fedora
3. Mint
What is Mint? I have never heard of or seen it during years of going
to Linux conferences...
Post by Felipe Contreras
4. OpenSUSE
5. Debian
http://distrowatch.com/
If you have evidence that suggests otherwise it would be nice to see that.
The only places I have ever seen Fedora used is at the Fedora booth at
LinuxTag, Dominik's laptop and one other person I know. I have never
heard about Mint before (well, let's say I don't remember) and maemo
or meego is a corporate-sponsored project with no adoption from endusers
that I am aware of.

I'm sure there are trillions of people running Fedora or Red Hat or CentOS
on servers, but you were talking about desktops. I just don't believe that
Fedora's market share on the Linux desktop is anything but minuscule.
Maybe it would be higher if they offered their users more than just
support for fring multimedia formats.

Diego
Michael Niedermayer
2010-11-03 02:16:03 UTC
Permalink
On Wed, Nov 03, 2010 at 12:54:51AM +0100, Diego Biurrun wrote:
[...]
Post by Diego Biurrun
I'm sure there are trillions of people running Fedora or Red Hat or CentOS
on servers, but you were talking about desktops. I just don't believe that
Fedora's market share on the Linux desktop is anything but minuscule.
Maybe it would be higher if they offered their users more than just
support for fring multimedia formats.
Actually i think there are people who start from windows want to try linux
end up with fedora and angrily and confused go then back to windows.
But except that minor detail i agree with you

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
Felipe Contreras
2010-11-06 08:54:19 UTC
Permalink
Post by Diego Biurrun
I'm sure there are trillions of people running Fedora or Red Hat or CentOS
on servers, but you were talking about desktops.  I just don't believe that
Fedora's market share on the Linux desktop is anything but minuscule.
Maybe it would be higher if they offered their users more than just
support for fring multimedia formats.
Believe what you want, I asked you for evidence, just like I provided
evidence that Fedora is #2, you have not provided a shred of it.
--
Felipe Contreras
Luca Barbato
2010-11-02 13:28:59 UTC
Permalink
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Post by Felipe Contreras
This is solved in GStreamer by having a separate package for the core,
and the patent encumbered plugins. The third party repo provides the
codec packages that get installed into /usr/lib/gstreamer-0.10, and
voilá, you have support for all the codecs. There's even on-the-fly
codec installation support so when trying to play a clip, you get
asked if you want to install the codec package.
What about having multiple libavcodec and just switch one with the other?
Post by Felipe Contreras
Personally I think it's a shame that FFmpeg is not shipped in such
important distributions just because of this reason. And of course if
your package depends on FFmpeg, then you are out of the distro as
well.
Not our fault.

lu
Felipe Contreras
2010-11-02 19:18:16 UTC
Permalink
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Is it? Say Fedora provides ffmpeg-free-0.6, rpmfusion provides
ffmpeg-all-0.6, presumably making sure it obsoletes ffmpeg-free, that
might work. But then ffmpeg-free-0.7 is released, and there's ABI
breakage so applications are updated at the same time, but now updates
are blocked, because of ffmpeg-all-0.6.

This looks like it would be a package maintenance hell.
Post by Luca Barbato
Post by Felipe Contreras
This is solved in GStreamer by having a separate package for the core,
and the patent encumbered plugins. The third party repo provides the
codec packages that get installed into /usr/lib/gstreamer-0.10, and
voilá, you have support for all the codecs. There's even on-the-fly
codec installation support so when trying to play a clip, you get
asked if you want to install the codec package.
What about having multiple libavcodec and just switch one with the other?
How? Having two separate packages? I don't think that would fly on
many distributions.
Post by Luca Barbato
Post by Felipe Contreras
Personally I think it's a shame that FFmpeg is not shipped in such
important distributions just because of this reason. And of course if
your package depends on FFmpeg, then you are out of the distro as
well.
Not our fault.
According to you.
--
Felipe Contreras
Luca Barbato
2010-11-02 21:17:46 UTC
Permalink
Post by Felipe Contreras
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Is it? Say Fedora provides ffmpeg-free-0.6, rpmfusion provides
ffmpeg-all-0.6, presumably making sure it obsoletes ffmpeg-free, that
might work. But then ffmpeg-free-0.7 is released, and there's ABI
breakage so applications are updated at the same time, but now updates
are blocked, because of ffmpeg-all-0.6.
This looks like it would be a package maintenance hell.
I'm not so proficient with rpm, in portage-speak there is the concept of
virtual and I guess deb has the same thing.

rpm doesn't have ffmpeg-$version that is aliased to ffmpeg-all
ffmpeg-free so that once you have a package requiring ffmpeg-$ver the
resolver will pick whatever satisfies the requirement within the virtual
providers?
Post by Felipe Contreras
How? Having two separate packages? I don't think that would fly on
many distributions.
works for ubuntu. For alternate implementations in Gentoo we provide
slot and virtual (depending if you want one to replace the other or one
stay aside the other)
Post by Felipe Contreras
According to you.
Me, and apparently a good chunk of the downstream distributors of ffmpeg
and upstream developers.

lu - donning both hats at the same time.
Felipe Contreras
2010-11-02 22:06:34 UTC
Permalink
Post by Luca Barbato
Post by Felipe Contreras
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Is it? Say Fedora provides ffmpeg-free-0.6, rpmfusion provides
ffmpeg-all-0.6, presumably making sure it obsoletes ffmpeg-free, that
might work. But then ffmpeg-free-0.7 is released, and there's ABI
breakage so applications are updated at the same time, but now updates
are blocked, because of ffmpeg-all-0.6.
This looks like it would be a package maintenance hell.
I'm not so proficient with rpm, in portage-speak there is the concept of
virtual and I guess deb has the same thing.
No, there isn't (neither in deb, nor rpm).
Post by Luca Barbato
rpm doesn't have ffmpeg-$version that is aliased to ffmpeg-all ffmpeg-free
so that once you have a package requiring ffmpeg-$ver the resolver will pick
whatever satisfies the requirement within the virtual providers?
It might be possible to use 'alternatives' for that[1]. I hadn't
thought of that... I will explore that option. However, it's still not
ideal:

Currently, without leaving the UI:
* Click search
* Click install

http://fedoraproject.org/wiki/Features/AutoFontsAndMimeInstaller

With alternatives:
* Manually find and install the required package
* Go to console, and configure the alternate

Obviously, the first one is more user friendly, the second one
requires documentation.
Post by Luca Barbato
Post by Felipe Contreras
How? Having two separate packages? I don't think that would fly on
many distributions.
works for ubuntu. For alternate implementations in Gentoo we provide slot
and virtual (depending if you want one to replace the other or one stay
aside the other)
Ubuntu ships FFmpeg already with most of what people need. It's only
for fringe cases where the second package is needed, which is
maintained by the community, and still, it's not straight-forward:
https://wiki.ubuntu.com/ffmpeg
Post by Luca Barbato
Post by Felipe Contreras
According to you.
Me, and apparently a good chunk of the downstream distributors of ffmpeg and
upstream developers.
Surely all those people know the insides-out of Fedora, their
philosophies, technical constraints, and final user requirements.

[1] http://fedoraproject.org/wiki/Packaging:Alternatives
--
Felipe Contreras
Reinhard Tartler
2010-11-03 06:56:05 UTC
Permalink
Post by Felipe Contreras
Post by Luca Barbato
Post by Felipe Contreras
How? Having two separate packages? I don't think that would fly on
many distributions.
works for ubuntu. For alternate implementations in Gentoo we provide slot
and virtual (depending if you want one to replace the other or one stay
aside the other)
Ubuntu ships FFmpeg already with most of what people need. It's only
for fringe cases where the second package is needed, which is
https://wiki.ubuntu.com/ffmpeg
FTR, I do maintain both packages in both distribution under the umbrella
of the debian pkg-multimedia packaging team.

The differences between ffmpeg and ffmpeg-extra are solely in three
additional build dependencies (elaborated elsewhere in the thread).
Moreover, ffmpeg-extra provides drop-in replacement packages for
libraries and is an annoyance to maintain.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reinhard Tartler
2010-11-02 19:41:41 UTC
Permalink
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Just FTR, I really dislike the ffmpeg/ffmpeg-extra hack and would prefer
a solution that does not involve a copied source package.

What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
libxvidcore-dev and libmp3lame-dev. Moving these three dependencies to
main is unfortunately not an option AFAIUI.

Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Michael Niedermayer
2010-11-02 20:30:11 UTC
Permalink
Post by Reinhard Tartler
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Just FTR, I really dislike the ffmpeg/ffmpeg-extra hack and would prefer
a solution that does not involve a copied source package.
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
libxvidcore-dev and libmp3lame-dev. Moving these three dependencies to
main is unfortunately not an option AFAIUI.
why is this not an option btw? it seems to make most sense technically
Post by Reinhard Tartler
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
i have no objection if the respective maintainers agree

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
Reimar Döffinger
2010-11-02 20:52:58 UTC
Permalink
Post by Michael Niedermayer
Post by Reinhard Tartler
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
i have no objection if the respective maintainers agree
I do (though without an actual patch it's possible they are unfounded),
it seems likely to me that it will either be an ifdef-mess (dlopen is not
available on all platforms) or platform-specific code (which beyond being
ugly on principle also causes some issues for testing).
Not saying it is really a better idea, but one could have
dummy/stub stub libraries that just return errors for example...
Michael Niedermayer
2010-11-02 21:01:38 UTC
Permalink
Post by Reimar Döffinger
Post by Michael Niedermayer
Post by Reinhard Tartler
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
i have no objection if the respective maintainers agree
I do (though without an actual patch it's possible they are unfounded),
it seems likely to me that it will either be an ifdef-mess (dlopen is not
available on all platforms) or platform-specific code (which beyond being
ugly on principle also causes some issues for testing).
if dl*() is unavailable id guess one could have macros that turn them into
just returning pointers to the functions directly
Post by Reimar Döffinger
Not saying it is really a better idea, but one could have
dummy/stub stub libraries that just return errors for example...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
Stefano Sabatini
2010-11-02 21:15:59 UTC
Permalink
Post by Michael Niedermayer
Post by Reinhard Tartler
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Just FTR, I really dislike the ffmpeg/ffmpeg-extra hack and would prefer
a solution that does not involve a copied source package.
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
libxvidcore-dev and libmp3lame-dev. Moving these three dependencies to
main is unfortunately not an option AFAIUI.
why is this not an option btw? it seems to make most sense technically
Speaking of technical reasons, which is the advantage of using
libxvidcore compared to the native FFmpeg MPEG 4.2 encoder?

Also was ever discussed the implementation of a native MP3 encoder?
Would that fit as a GSoc task and what are we still missing?

(As for the a libx264->FFmpeg merge I'm not holding my breath, but yes
there would be great technical advantages from that as well...).
--
FFmpeg = Formidable Fostering Mythic Power Explosive God
Michael Niedermayer
2010-11-02 21:33:30 UTC
Permalink
Post by Stefano Sabatini
Post by Michael Niedermayer
Post by Reinhard Tartler
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Just FTR, I really dislike the ffmpeg/ffmpeg-extra hack and would prefer
a solution that does not involve a copied source package.
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
libxvidcore-dev and libmp3lame-dev. Moving these three dependencies to
main is unfortunately not an option AFAIUI.
why is this not an option btw? it seems to make most sense technically
Speaking of technical reasons, which is the advantage of using
libxvidcore compared to the native FFmpeg MPEG 4.2 encoder?
there are people who like xvid, and i want to keep them happy.
in that sense the question about which is technically better doesnt matter,
not saying i know or there even is an awnser
(thats about libxvid support in ffmpeg not debian linking ffmpeg to xvid which
is the debian maintainers thing to decide not mine)
Post by Stefano Sabatini
Also was ever discussed the implementation of a native MP3 encoder?
i started working on one but havnt worked on it since a long time so i wouldnt
put too much hope in me finishing it
Post by Stefano Sabatini
Would that fit as a GSoc task and what are we still missing?
we would need a well qualified student for this, encoders arent all that easy

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
Nicolas George
2010-11-02 21:36:01 UTC
Permalink
Post by Stefano Sabatini
Speaking of technical reasons, which is the advantage of using
libxvidcore compared to the native FFmpeg MPEG 4.2 encoder?
That is a question I am interested also.

I usually use XviD when I need MPEG 4.2, because I did not manage to find
settings for the native encoder that yield as good a quality-for-bitrate as
XviD -mbd 2 / vhq=4 in fixed_quant=2 mode. But the native encoder has a
whole lot of settings and knobs to tweak.

I think some presets files would be very useful.

Regards,
--
Nicolas George
Michael Niedermayer
2010-11-02 21:46:41 UTC
Permalink
Post by Nicolas George
Post by Stefano Sabatini
Speaking of technical reasons, which is the advantage of using
libxvidcore compared to the native FFmpeg MPEG 4.2 encoder?
That is a question I am interested also.
I usually use XviD when I need MPEG 4.2, because I did not manage to find
settings for the native encoder that yield as good a quality-for-bitrate as
XviD -mbd 2 / vhq=4 in fixed_quant=2 mode. But the native encoder has a
whole lot of settings and knobs to tweak.
I think some presets files would be very useful.
I think debuging the differences would be usefull
is it caused by quantization, motion estimation, scenechange detection
macroblock decisison ?
both we and xvid could benefit from knowing this

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
Nicolas George
2010-11-02 22:05:48 UTC
Permalink
Post by Michael Niedermayer
I think debuging the differences would be usefull
is it caused by quantization, motion estimation, scenechange detection
macroblock decisison ?
both we and xvid could benefit from knowing this
I had been told, at the time, that the main difference was that XviD uses a
higher quantizer for B-frames, while the native encoder, in fixed-quantizer
mode, does not without specific options. But I had not been able to find the
relevant options.

That is why I am not claiming that XviD is better, but asking: does someone
know how to tune the native encoder to be better than XviD?

Regards,
--
Nicolas George
Alexander Strange
2010-11-02 22:14:43 UTC
Permalink
Post by Nicolas George
Post by Michael Niedermayer
I think debuging the differences would be usefull
is it caused by quantization, motion estimation, scenechange detection
macroblock decisison ?
both we and xvid could benefit from knowing this
I had been told, at the time, that the main difference was that XviD uses a
higher quantizer for B-frames, while the native encoder, in fixed-quantizer
mode, does not without specific options. But I had not been able to find the
relevant options.
That is why I am not claiming that XviD is better, but asking: does someone
know how to tune the native encoder to be better than XviD?
That particular setting is -b_qoffset <something>.
More interesting options would start off with "-bidir_refine 1 -brd_scale 1 -bf 4 -b_strategy 2".

Given x264's success with MB-Tree (which obsoletes I/P offset and P/B offsets) and trellis frametype (b_strategy 2 is IIRC exponential) I think some improvement in algorithms would work better than options tuning here, but it would take a lot of effort and ASP is not really worth it.
Michael Niedermayer
2010-11-03 02:19:53 UTC
Permalink
Post by Alexander Strange
Post by Nicolas George
Post by Michael Niedermayer
I think debuging the differences would be usefull
is it caused by quantization, motion estimation, scenechange detection
macroblock decisison ?
both we and xvid could benefit from knowing this
I had been told, at the time, that the main difference was that XviD uses a
higher quantizer for B-frames, while the native encoder, in fixed-quantizer
mode, does not without specific options. But I had not been able to find the
relevant options.
That is why I am not claiming that XviD is better, but asking: does someone
know how to tune the native encoder to be better than XviD?
That particular setting is -b_qoffset <something>.
More interesting options would start off with "-bidir_refine 1 -brd_scale 1 -bf 4 -b_strategy 2".
Given x264's success with MB-Tree (which obsoletes I/P offset and P/B offsets) and trellis frametype (b_strategy 2 is IIRC exponential) I think some improvement in algorithms would work better than options tuning here, but it would take a lot of effort and ASP is not really worth it.
long term, we will likely start using x264s encoding core for
mpeg1/2/4/h261/2/3. That way we would get all the improvments in x264 for free

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
Jason Garrett-Glaser
2010-11-03 05:04:27 UTC
Permalink
Post by Michael Niedermayer
Post by Alexander Strange
Post by Nicolas George
Post by Michael Niedermayer
I think debuging the differences would be usefull
is it caused by quantization, motion estimation, scenechange detection
macroblock decisison ?
both we and xvid could benefit from knowing this
I had been told, at the time, that the main difference was that XviD uses a
higher quantizer for B-frames, while the native encoder, in fixed-quantizer
mode, does not without specific options. But I had not been able to find the
relevant options.
That is why I am not claiming that XviD is better, but asking: does someone
know how to tune the native encoder to be better than XviD?
That particular setting is -b_qoffset <something>.
More interesting options would start off with "-bidir_refine 1 -brd_scale 1 -bf 4 -b_strategy 2".
Given x264's success with MB-Tree (which obsoletes I/P offset and P/B offsets) and trellis frametype (b_strategy 2 is IIRC exponential) I think some improvement in algorithms would work better than options tuning here, but it would take a lot of effort and ASP is not really worth it.
long term, we will likely start using x264s encoding core for
mpeg1/2/4/h261/2/3. That way we would get all the improvments in x264 for free
Well, mpeg-2 for sure: http://github.com/kierank/x262 :)

Dark Shikari
Reinhard Tartler
2010-11-03 06:23:41 UTC
Permalink
Post by Michael Niedermayer
Post by Reinhard Tartler
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Just FTR, I really dislike the ffmpeg/ffmpeg-extra hack and would prefer
a solution that does not involve a copied source package.
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
libxvidcore-dev and libmp3lame-dev. Moving these three dependencies to
main is unfortunately not an option AFAIUI.
why is this not an option btw? it seems to make most sense technically
Here are the requirements for main:
https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
Promotion to main also includes committment of Canonical in terms of
maintenance, security updates, etc.
Given that the request for x264 is unprocessed since 2 years, I don't
have much hope that mp3lame or xvid will make it:
https://wiki.ubuntu.com/MainInclusionX264

(granted, I didn't push it either, but still)
Post by Michael Niedermayer
Post by Reinhard Tartler
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
i have no objection if the respective maintainers agree
Okay, since AFAIUI you maintain mp3lame.c and xvid, I take this as
agreement for these codecs.

Jason? Would you accept something like that for the x264 wrapper?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Jason Garrett-Glaser
2010-11-03 06:54:48 UTC
Permalink
Post by Reinhard Tartler
Promotion to main also includes committment of Canonical in terms of
maintenance, security updates, etc.
Given that the request for x264 is unprocessed since 2 years, I don't
Is there some need to have a commitment for maintenance for something
that's actively maintained? Security updates for something that only
takes raw input, and therefore has near-zero chance of a meaningful
security vulnerability (and which has never had a security fix in 6
years)?
Post by Reinhard Tartler
Post by Michael Niedermayer
Post by Reinhard Tartler
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
i have no objection if the respective maintainers agree
Okay, since AFAIUI you maintain mp3lame.c and xvid, I take this as
agreement for these codecs.
Jason? Would you accept something like that for the x264 wrapper?
How exactly does dlopen work? Can it figure out the right version of
x264 to load, or will it just blindly load the latest and then fail,
like GNU's braindead linker does?

Dark Shikari
Reimar Döffinger
2010-11-03 07:24:00 UTC
Permalink
Post by Jason Garrett-Glaser
Post by Reinhard Tartler
Post by Michael Niedermayer
Post by Reinhard Tartler
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
i have no objection if the respective maintainers agree
Okay, since AFAIUI you maintain mp3lame.c and xvid, I take this as
agreement for these codecs.
Jason? Would you accept something like that for the x264 wrapper?
How exactly does dlopen work? Can it figure out the right version of
x264 to load, or will it just blindly load the latest and then fail,
like GNU's braindead linker does?
Well, you could make it search for a library with a matching
symbol, however I think the code might become quite messy.
Well, actually if x264 is careful enough you probably could
even load any and all x264 libs you can grab and then just
look for the correctly versioned symbol, but that approach
seems ... scary to me.
Jason Garrett-Glaser
2010-11-03 09:07:03 UTC
Permalink
On Wed, Nov 3, 2010 at 12:24 AM, Reimar Döffinger
Post by Reimar Döffinger
Post by Reinhard Tartler
Post by Michael Niedermayer
Post by Reinhard Tartler
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
i have no objection if the respective maintainers agree
Okay, since AFAIUI you maintain mp3lame.c and xvid, I take this as
agreement for these codecs.
Jason? Would you accept something like that for the x264 wrapper?
How exactly does dlopen work?  Can it figure out the right version of
x264 to load, or will it just blindly load the latest and then fail,
like GNU's braindead linker does?
Well, you could make it search for a library with a matching
symbol, however I think the code might become quite messy.
Well, actually if x264 is careful enough you probably could
even load any and all x264 libs you can grab and then just
look for the correctly versioned symbol, but that approach
seems ... scary to me.
That last doesn't seem too bad, considering that x264 *does* have
symbol versioning already...

Dark Shikari
Nicolas George
2010-11-02 21:22:49 UTC
Permalink
Post by Reinhard Tartler
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
What good will it do to dlopen() libx264 if you do not know the prototype
for x264_encoder_encode?

The prototype is quite complex and changes pretty often: you still
build-depend on x264.h.

What you can do to cheat stupid patent laws is create The "x264crap"
project, which is a fork of x264 with all possibly patent infringing code
removed, but exactly the same API and ABI as x264. It may produce files with
an horribly bad quality, or even not work at all, that's not a problem, as
it would only be used for building / linking, not for encoding.

Regards,
--
Nicolas George
Michael Niedermayer
2010-11-02 21:35:06 UTC
Permalink
Post by Nicolas George
Post by Reinhard Tartler
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
What good will it do to dlopen() libx264 if you do not know the prototype
for x264_encoder_encode?
The prototype is quite complex and changes pretty often: you still
build-depend on x264.h.
What you can do to cheat stupid patent laws is create The "x264crap"
project, which is a fork of x264 with all possibly patent infringing code
removed, but exactly the same API and ABI as x264. It may produce files with
an horribly bad quality, or even not work at all, that's not a problem, as
it would only be used for building / linking, not for encoding.
call it x264black, the encoder that can encode only black frames ;)

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
Reinhard Tartler
2010-11-03 06:48:36 UTC
Permalink
Post by Nicolas George
Post by Reinhard Tartler
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
Would the project accept patches to dlopen() these three libraries at
runtime? Then I could (finally) drop ffmpeg-extra.
What good will it do to dlopen() libx264 if you do not know the prototype
for x264_encoder_encode?
The prototype is quite complex and changes pretty often: you still
build-depend on x264.h.
I'd copy it to the ffmpeg source package. Same for mp3lame and
xvid. Still ugly, but already done IIRC for faad.h.
Post by Nicolas George
What you can do to cheat stupid patent laws is create The "x264crap"
project, which is a fork of x264 with all possibly patent infringing code
removed, but exactly the same API and ABI as x264. It may produce files with
an horribly bad quality, or even not work at all, that's not a problem, as
it would only be used for building / linking, not for encoding.
I'll consider that idea when the need actually arises.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Diego Biurrun
2010-11-03 07:39:02 UTC
Permalink
Post by Reinhard Tartler
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Just FTR, I really dislike the ffmpeg/ffmpeg-extra hack and would prefer
a solution that does not involve a copied source package.
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
libxvidcore-dev and libmp3lame-dev. Moving these three dependencies to
main is unfortunately not an option AFAIUI.
Why?

Diego
Reinhard Tartler
2010-11-03 08:02:27 UTC
Permalink
Post by Reinhard Tartler
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Just FTR, I really dislike the ffmpeg/ffmpeg-extra hack and would prefer
a solution that does not involve a copied source package.
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
libxvidcore-dev and libmp3lame-dev. Moving these three dependencies to
main is unfortunately not an option AFAIUI.
Why?
cf. Message-ID: <***@faui44a.informatik.uni-erlangen.de>
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Diego Biurrun
2010-11-03 08:24:24 UTC
Permalink
Post by Reinhard Tartler
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Just FTR, I really dislike the ffmpeg/ffmpeg-extra hack and would prefer
a solution that does not involve a copied source package.
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
libxvidcore-dev and libmp3lame-dev. Moving these three dependencies to
main is unfortunately not an option AFAIUI.
Why?
Sorry, I misread and thought this was about Debian. What is the status
of these packages in Debian?

Diego
Reinhard Tartler
2010-11-03 10:36:18 UTC
Permalink
Post by Diego Biurrun
Post by Reinhard Tartler
Post by Luca Barbato
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs. Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
That is a stupid excuse as pointed by ubuntu.
Just FTR, I really dislike the ffmpeg/ffmpeg-extra hack and would prefer
a solution that does not involve a copied source package.
What's holding me back from doing this are three build dependencies,
that are not available in the 'main' section: libx264-dev,
libxvidcore-dev and libmp3lame-dev. Moving these three dependencies to
main is unfortunately not an option AFAIUI.
Why?
Sorry, I misread and thought this was about Debian. What is the status
of these packages in Debian?
seems that reviewing NEW packages is suspended until after squeeze release:

http://lists.debian.org/debian-devel-announce/2010/10/msg00012.html
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Carl Eugen Hoyos
2010-11-02 14:12:57 UTC
Permalink
Post by Felipe Contreras
This is solved in GStreamer
Where is Måns when we really need his comments?

Allow me to add that I am very strictly against the proposed patch as long as no
explanation is given what it is needed for (which should probably not include
the word "patents").

Carl Eugen
Nicolas George
2010-11-02 21:14:22 UTC
Permalink
Post by Carl Eugen Hoyos
Allow me to add that I am very strictly against the proposed patch as long
as no explanation is given what it is needed for
I explained why I needed it for: adding a home-made input format for
specific needs. There are other options to do it, each with pros and cons.
Adding it statically by patching the source and rebuilding, which is what I
do at this time, has the con that I can not use the distro's libav*.

Regards,
--
Nicolas George
Reimar Döffinger
2010-11-02 21:22:54 UTC
Permalink
Post by Nicolas George
Post by Carl Eugen Hoyos
Allow me to add that I am very strictly against the proposed patch as long
as no explanation is given what it is needed for
I explained why I needed it for: adding a home-made input format for
specific needs. There are other options to do it, each with pros and cons.
Adding it statically by patching the source and rebuilding, which is what I
do at this time, has the con that I can not use the distro's libav*.
You can't do that anyway, unless you use none of the non-public API functions
at all (and someone else mentioned why that is highly undesirable, and honestly
in my opinion it makes it pointless for that plugin to be implemented "below"
ffmpeg instead of a wrapper above it), the internal API can change any time,
including for security updates.
Unless there's also a stable API for those plugins they are more likely to
be a nightmare than an improvement to users.
Nicolas George
2010-11-02 21:39:01 UTC
Permalink
Post by Reimar Döffinger
You can't do that anyway, unless you use none of the non-public API
functions at all (and someone else mentioned why that is highly
undesirable, and honestly in my opinion it makes it pointless for that
plugin to be implemented "below" ffmpeg instead of a wrapper above it),
the internal API can change any time, including for security updates.
Unless there's also a stable API for those plugins they are more likely to
be a nightmare than an improvement to users.
The format I have written only uses structures and functions from the
public, installed headers, and it works quite well as a LD_PRELOADed plugin.

Regards,
--
Nicolas George
Reimar Döffinger
2010-11-02 22:15:24 UTC
Permalink
Post by Nicolas George
Post by Reimar Döffinger
You can't do that anyway, unless you use none of the non-public API
functions at all (and someone else mentioned why that is highly
undesirable, and honestly in my opinion it makes it pointless for that
plugin to be implemented "below" ffmpeg instead of a wrapper above it),
the internal API can change any time, including for security updates.
Unless there's also a stable API for those plugins they are more likely to
be a nightmare than an improvement to users.
The format I have written only uses structures and functions from the
public, installed headers, and it works quite well as a LD_PRELOADed plugin.
Yes, I actually though it might work somewhat for formats, I don't think
it will for codecs though.
Even for more complex formats there's things like reading or writing
ID3 tags, interleaving, a few other stuff in internal.h that makes it
a good bit less likely to be a good implementation IMO.
Michael Niedermayer
2010-11-02 18:02:33 UTC
Permalink
these kind of mails really make me miss mans
Post by Felipe Contreras
Post by Ronald S. Bultje
On Sun, Oct 31, 2010 at 9:42 AM, Nicolas George
Post by Nicolas George
There is probably much to discuss, but at the very least, it works to simply
add support for a new format in lavf by just dropping a file in a directory.
Codecs and filters should work just the same.
Let's just go over the big phat elephant in the room. Is this an advantage?
Of course it is is!
true, we found a bug in your speech synth that leads to repeated words
Post by Felipe Contreras
There is a need to package separately free, and patent encumbered
codecs.
and we do, ffmpeg is patent encumbered, and main(){} is free (with some luck)
Post by Felipe Contreras
Right now that's impossible with FFmpeg, and that's the reason
it's not offered on Fedora, or MeeGo.
what is meego? and who uses fedora after having tried any other major distro?
Post by Felipe Contreras
This is solved in GStreamer by having a separate package for the core,
and the patent encumbered plugins.
if so why do you complain?
Post by Felipe Contreras
The third party repo provides the
codec packages that get installed into /usr/lib/gstreamer-0.10, and
voilá, you have support for all the codecs.
dont use fedora and viola you have support for all the codecs
out of the box
Post by Felipe Contreras
There's even on-the-fly
codec installation support so when trying to play a clip, you get
asked if you want to install the codec package.
and with ffmpeg it just works, no annoying questions to the end user,
no download needed, no net connection needed.

Thats just besides that automated install of patent encumbered things will make
the core be patent encumbered too if the automatically installed things are.
If it was otherwise SW patents would be unenforceable and every company would
just install that part seperately after asking the user "do you want this to
work?"
Post by Felipe Contreras
Personally I think it's a shame that FFmpeg is not shipped in such
important distributions just because of this reason. And of course if
your package depends on FFmpeg, then you are out of the distro as
well.
I think its a shame such distros are shiped anywhere but the next garbage dump

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
Peter Ross
2010-11-01 12:07:13 UTC
Permalink
Post by Nicolas George
Hi.
This patch is an attempt at implementing a simple plugins architecture for
ffmpeg / libav*.
The design is kept minimalistic on purpose: any file named av*.so in
$PREFIX/lib/ffmpeg/ or $AV_PLUGIN_PATH is dlopened, and its _init function
is expected to call av_register_something to publish its features.
There is probably much to discuss, but at the very least, it works to simply
add support for a new format in lavf by just dropping a file in a directory.
Codecs and filters should work just the same.
Whats the purpose? You can already add news codecs, formats and filters to
an existing FFmpeg installation. It simple. Download source code, compile,
then copy the libav*so files over the existing ones.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
Loading...