| |||||||||||||
The cake, it was a lieThe cake, it was a liePosted Sep 25, 2012 10:25 UTC (Tue) by Frej (subscriber, #4165)In reply to: The cake, it was a lie by sebas Parent article: GStreamer 1.0 released
The cost of changing from 0.10->1.0 is likely less than having a wrapper?
Everytime a phonon backend does something 'new' that solves an existing problem - What happens then? You add API, and then all media players have backends that are subpar, or must media players verify if current backend supports the new feature? Either way the pain is just pushed to API users.
Or must every backend support a new feature before it's added? So everything slows down?
And how do media players handle support? Now they get to support problems from X backends instead of just one. Oh the mkv parser is broken in Z, but works in Y. Pain :(
(Log in to post comments)
The cake, it was a lie Posted Sep 25, 2012 12:13 UTC (Tue) by sebas (subscriber, #51660) [Link]
What you say is true for one isolated application.
In KDE, this is quite different:
The costs of porting a backend in one place is way lower than changing every application.
Moreover, GStreamer developer could not guarantee source and binary compatibility for KDE's lifetime. (Which is OK, just means we had to find a solution, which we did.)
The cake, it was a lie Posted Sep 25, 2012 14:07 UTC (Tue) by rvfh (subscriber, #31018) [Link]
> Everytime a phonon backend does something 'new' that solves an existing problem - What happens then? You add API, and then all media players have backends that are subpar, or must media players verify if current backend supports the new feature?
The Phonon API is only about the basic stuff you find in 99% of apps: play a sound. So you don't need to change the Phonon API. The fact that the backend does something better (as is the case in GST 1.0, for example buffer sharing) does not mean you need to change the Phonon API to play/pause/stop a stream.
Why would it?
|
|||||||||||||