Adding (parts of) gstreamer-plugins-bad to FE?

[Hans de Goede]

Michel Salim wrote:
> 2006/11/28, Hans de Goede <j.w.r.degoede at hhs.nl>:
>>
>>
>> Michel Salim wrote:
>> > 2006/11/27, Hans de Goede <j.w.r.degoede at hhs.nl>:
>> >>
>> >>
>> >> Bill Nottingham wrote:
>> >> > Hans de Goede (j.w.r.degoede at hhs.nl) said:
>> >> >> qt
>> >> >> Quicktime container format support, through own gst code (no libs
>> >> used),
>> >> >> this one is trouble some. I would really like to see this in FE as
>> >> this
>> >> >> adds supports for videos made with many digital photo cameras to
>> >> >> gstreamer using applications (usually these camera's just dump a
>> raw
>> >> >> audio stream and a serie of jpeg images into a .mov file.
>> >> >>
>> >> >> So where should this one go? I really don't know. Can anyone help
>> >> here?
>> >> >
>> >> > I'm not 100% sure, but I believe the quicktime *container* format is
>> >> open;
>> >> > it's just that most of the things put in it usually aren't.
>> >> >
>> >>
>> >> So that makes 2 votes in favor of qt container support in FE, rest
>> >> assured I'm only talking about *container* support here.
>> >>
>> >> Are there any nay-sayers? Should we pass this through legal first? (no
>> >> please). Anyone who can give a definite YES?
>> >>
>> > I'm not too familiar with the QT container format, but here's an Apple
>> > developer talking about parts of QuickTime that is patented:
>> >
>> > http://lists.xiph.org/pipermail/vorbis-dev/2001-October/004846.html
>> >
>> > Whether the patent is still valid, or whether it's implemented in
>> > gstreamer-plugins-bad, I don't know.
>> >
>> >
>>
>> IANAL, but the patent referenced there if I understand the mail
>> correctly is about optimising a file when creating one so that it can
>> be easily streamed, that doesn't seem relevant for qt-reading code.
>>
> Ah, true. In that case, I'm all for having more Gstreamer plugins made
> available out-of-the-box.
> 
> Is the intention to put them in one RPM or split them out
> one-per-plugin? The former seems better, but what do you want to call
> it - gstreamer-plugins-not-so-bad does not really appeal.
> 

The bad references mainly to the code quality, not to licensing issues,
so I'm planning on:
gstreamer-plugins-bad: important bad quality plugins, destined for the
new desktop CD (atleast qt if qt is admissable at all)
gstreamer-plugins-bad-extras: bad quality plugins, which really aren't
all that interesting like speed and pitch change plugins
gstreamer-plugins-bad-extras-non-free: plugins which are both bad and
ugly (licensing wise), this would go in that other repo.

Regards,

Hans