5 ms·
And hence the coding quality separation of gstreamer plugins. There is a reason the plugin ended up in gstreamer-plugins-bad, and most of them it is due to code
by boxfire 10y ago
And hence the coding quality separation of gstreamer plugins. There is a reason the plugin ended up in gstreamer-plugins-bad, and most of them it is due to code quality or lack of maintainers or both.
- ronjouch 10y agoOh really, the -{good, bad, ugly} axis is coding quality? I always assumed it was licensing status / patents clearance. EDIT it's both: https://gstreamer.freedesktop.org/documentation/splitup.html https://gstreamer.freedesktop.org/documentation/splitup.html , http://askubuntu.com/questions/468875/plugins-ugly-and-bad http://askubuntu.com/questions/468875/plugins-ugly-and-bad
- NoGravitas 10y agoThe good plugins have both acceptable code quality and acceptable license/patent terms. The ugly plugins have acceptable code quality, but unacceptable license/patent terms. Bad plugins are lacking code review, documentation, or are unmaintained, or have other problems that keep them from being moved to good or ugly.
- gcb0 10y agoI would have expected that to be the "testing" branch, not a different packages. but I guesd it makes sense if you gave up updating the code
- phee 10y agoGStreamer is highly modular, so it makes totally sense to ship a set of plugins with subpar code, unclear patent/licensing, barely maintained in a dedicated package. They called it "bad", what do you expect? The issue here is that distributions should offer more granularity with on demand codec installation. Does it make sense that to play an mp3 (not that sure this is the case) I get also the NSF decoder?
- rwmj 10y agoI think the problem is not that they have a place for the bad/ugly code, but that Nautilus runs that code on any file it can with no sandboxing.