Michel Salim wrote: > 2006/11/28, Hans de Goede <j.w.r.degoede@xxxxxx>: >> >> >> Michel Salim wrote: >> > 2006/11/27, Hans de Goede <j.w.r.degoede@xxxxxx>: >> >> >> >> >> >> Bill Nottingham wrote: >> >> > Hans de Goede (j.w.r.degoede@xxxxxx) 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
