From: Michael R. <mr...@us...> - 2005-08-09 18:30:48
|
Hi team, it caught my attention that the latest release of Kaffeine now has a gstreamer backend next to the xine-lib one. I started some quick research on gstreamer and found a lot of statements like "gstreamer is definitely the future of video on Linux". From my biased perspective, around the xine-lib 1.0 preparations, there was a lot of excitement around xine and a lot of projects were going for our lib. Now this excitement seems to have moved towards gstreamer. Why? Have I missed something? Did we do something wrong? Maybe xine-lib did not evolve fast enough over the last months? I am not panicing and I don't think xine will become obsolete (at least not yet), but the (new?) competition is there, so I would like to hear some feelings and opinions from others on how we should deal with this. Michael |
From: Mike M. <mi...@mu...> - 2005-08-09 18:54:05
|
Michael Roitzsch wrote: > Hi team, > > it caught my attention that the latest release of Kaffeine now has a > gstreamer backend next to the xine-lib one. I started some quick > research on gstreamer and found a lot of statements like "gstreamer is > definitely the future of video on Linux". From my biased perspective, > around the xine-lib 1.0 preparations, there was a lot of excitement > around xine and a lot of projects were going for our lib. Now this > excitement seems to have moved towards gstreamer. Why? Have I missed > something? Did we do something wrong? Maybe xine-lib did not evolve > fast enough over the last months? I am not panicing and I don't think > xine will become obsolete (at least not yet), but the (new?) > competition is there, so I would like to hear some feelings and > opinions from others on how we should deal with this. We should really be worried if Daniel plugs xine-ui into the GStreamer backend. :) Actually, no, that would not be cause for concern. That just means that both xine-lib and GStreamer have been designed with a high degree of modularity in mind. If there is enough homogeneity and stability in the various projects that it is possible to swap out backends, wow! It also signals opportunity for more cooperation. Anyway, I stopped thinking about competition between open source multimedia projects a long time ago. Our real competition is the world of closed, proprietary multimedia. -- -Mike Melanson |
From: Michael R. <mr...@us...> - 2005-08-10 12:41:56
|
Hi Mike, > We should really be worried if Daniel plugs xine-ui into the > GStreamer backend. :) Actually, no, that would not be cause for > concern. That just means that both xine-lib and GStreamer have been > designed with a high degree of modularity in mind. If there is > enough homogeneity and stability in the various projects that it is > possible to swap out backends, wow! It also signals opportunity for > more cooperation. Cooperation is also the one conclusion I would like to draw. I think I will have a look at their design docs. I have some ideas for a possible xine 2.0 which might be similar to their concept. > Anyway, I stopped thinking about competition between open > source multimedia projects a long time ago. Our real competition is > the world of closed, proprietary multimedia. Nice attitude! I should make that my own. Michael |
From: Christophe T. <hf...@fr...> - 2005-08-09 22:15:45
|
Le Mardi 09 Ao=FBt 2005 20:29, Michael Roitzsch a =E9crit=A0: > Hi team, > > it caught my attention that the latest release of Kaffeine now has a > gstreamer backend next to the xine-lib one. > I started some quick=20 > research on gstreamer and found a lot of statements like "gstreamer > is definitely the future of video on Linux". From my biased > perspective, around the xine-lib 1.0 preparations, there was a lot of > excitement around xine and a lot of projects were going for our lib. > Now this excitement seems to have moved towards gstreamer. Why? Have > I missed something? Did we do something wrong? Maybe xine-lib did not > evolve fast enough over the last months? I am not panicing and I > don't think xine will become obsolete (at least not yet), but the > (new?) competition is there, so I would like to hear some feelings > and opinions from others on how we should deal with this. > > Michael This does not mean that xine-lib is obsolete. It's still the default Kaffei= ne=20 backend and IMHO will remain so for a while. At that time, gstreamer is far= =20 from xine. So, keep up the excellent work, and remember that we are still=20 waiting for this superior kernel ... But yes, xine can still evolve : =2Dmaking seeking faster (esp for audio : give amarok+arts a try) =2Dfading audio tracks (again : amarok+arts) =2Dand a very special feature i would like, (but do not believe that much:)= :=20 the ability to play the next mrl without discontinuity (like if it was the= =20 same). For example for live cdda tracks, or (in my case) a dvb stream throu= gh=20 a pipe followed by a regular file (timeshifting!). =2D-=20 Christophe Thommeret |
From: Michael R. <mr...@us...> - 2005-08-10 12:57:53
|
Hi Christophe, > This does not mean that xine-lib is obsolete. It's still the > default Kaffeine backend and IMHO will remain so for a while. At > that time, gstreamer is far from xine. So, keep up the excellent > work, and remember that we are still waiting for this superior > kernel ... Thanks for the reassurance. :) > But yes, xine can still evolve : > > -making seeking faster (esp for audio : give amarok+arts a try) Make everything faster is always a goal, but seeking might be difficult, because there is so much code involved. Anything from the demuxer down to metronom needs to handle a seek. I think there is potential for simplification in the engine which should be exploited to clear this up. I hope that bottlenecks will be easier to spot then. > -fading audio tracks (again : amarok+arts) I have thought about it and I think it should be possible with just one post plugin. I have not found the time to look closer into it, though. But if anyone is interested, I would happily explain my idea in detail. > -and a very special feature i would like, (but do not believe that > much:) : > the ability to play the next mrl without discontinuity (like if it > was the same). For example for live cdda tracks, or (in my case) a > dvb stream through a pipe followed by a regular file (timeshifting!). This has been on my list for a very long time, but I have not found a clear way to do that. Since xine streams need a lot of preroll time, this would have to be done somehow in a second stream, which should take over once the first stream has finished, probably smoothing the transition by propagating some metronom state. Anyway, xine should start pushing the limits again, so I guess I should step up the pace with these 2.0 ideas... Michael PS: Kaffeine rocks! |
From: Andre P. <oz...@al...> - 2005-08-10 14:07:06
|
On 10/08/2005, at 4:29 AM, Michael Roitzsch wrote: > From my biased perspective, around the xine-lib 1.0 preparations, > there was a lot of excitement around xine and a lot of projects > were going for our lib. Now this excitement seems to have moved > towards gstreamer. I don't think the two projects are tackling the same problem area. xine is a fantastic API for video playback: it's a "cheap'n'cheery" interface, and is simple to use. gstreamer is an all-encompassing media framework, designed to be able to build arbitrary, complex pipelines of connected components. You can do some amazing things with gstreamer, such as having several video-capture servers all running on different machines, each sending their video stream to a main server that can stream it out to the Internet. The downside of gstreamer is that it's a _lot_ more complex than xine. The tutorials on gstreamer make it look simple, but once you move past trivial examples and want to write something that's moderately complex, it gets much more difficult. So, I don't regard the two as true competition for each other. (And, in response to Mike Melanson's post about competition, I think competition between open-source projects is a great, healthy thing!) -- % Andre Pang : trust.in.love.to.save <http://www.algorithm.com.au/> |
From: Mike M. <mi...@mu...> - 2005-08-10 15:17:22
|
Andre Pang wrote: > I don't think the two projects are tackling the same problem area. Excellent point. And whenever people ask me what Linux media player is the best (e.g., xine, MPlayer, or VLC) I always have to patiently explain that all 3 are designed with different goals and are targeted at different audiences. > So, I don't regard the two as true competition for each other. (And, > in response to Mike Melanson's post about competition, I think > competition between open-source projects is a great, healthy thing!) Friendly, healthy competition, as long as all participants realize that we are on the same team in the end. -- -Mike Melanson |
From: Michael R. <mr...@us...> - 2005-08-10 15:33:52
|
Hi, > I don't think the two projects are tackling the same problem area. > xine is a fantastic API for video playback: it's a "cheap'n'cheery" > interface, and is simple to use. gstreamer is an all-encompassing > media framework, designed to be able to build arbitrary, complex > pipelines of connected components. That's interesting. I don't know anything about the gstreamer API, so perhaps I should do some reading to avoid those design problems. > So, I don't regard the two as true competition for each other. > (And, in response to Mike Melanson's post about competition, I > think competition between open-source projects is a great, healthy > thing!) So true. Healthy competition is certainly very helpful. xine and mplayer being a very good example. I guess neither project would be where it is now without the other. Michael |
From: Jason T. <ta...@sa...> - 2005-08-10 16:35:31
|
On Tue, 2005-08-09 at 20:29 +0200, Michael Roitzsch wrote: > Now this excitement seems to have moved towards gstreamer. Why? Have =20 > I missed something? Did we do something wrong? Maybe xine-lib did not =20 I've been interested in digital video for some years now, but have been using MPlayer (and mencoder) pretty much exclusively. As I mentioned before, I'd used xine very briefly in the past, but never really gave it any serious consideration. My hacking interests have also been centered around MPlayer. So I'm quite a newcomer to the xine scene. Maybe that's good, as it gives me a fresh perspective to discuss this. Here are my thoughts. First, let me explain why I stayed away from xine all these years. The main reason was xine-ui. I freely admit a strong distaste for any software that looks bad, and xine-ui looks bad. I just feel that it's a tragically bad UI. It's reminiscent of the old Xt days: traumatic times that I'm desperately trying to block out. Consequently, the amount of time I had used xine could be best measured in seconds. Long enough to load a video in xine, fiddle through the menus, observe the lackluster list of video filters, and draw the conclusion, "There's really no benefit over MPlayer here." Xine feels slower than MPlayer. This perception is largely, I suspect, due to the delays in seeking. Certainly it doesn't use much more CPU than MPlayer, so by "slow" here I mean in terms of responsiveness. MPlayer has a very rich set of filters compared to Xine's anemic video post plugins. With MPlayer, I play back my DVD rips with -vf fspp,noise=3D8ah:5ah,eq2=3D1.2:1.1 and I generally have an extremely hard time distinguishing this from DVD. MPlayer has also very high quality software scaler. Playing back DVDs with MPlayer using software scaling produces higher quality through TV-out than my DVD settop box does. (Also, I have noticed some things look better in MPlayer even without filters than with Xine. I recently transcoded my Hide & Seek DVD using xvid and observed things looked a bit blockier in Xine. Could be that MPlayer has a more recent and improved libavcodec. I mention this as an aside since I haven't had much time to look into it, so it's just a very cursory observation.) I'm comparing Xine to MPlayer rather than GStreamer since that's where my experience lies. GStreamer has been on my radar for a while now, though. I haven't been closely following development, but from the periphery there are a couple things I have observed. Firstly, GStreamer seems to have a lot of development momentum. I hear about it all the time. It is backed by a company that has a vested interest in seeing it succeed, and that's always a nice attribute to have. (But certainly not a necessary one.) GStreamer also has python bindings, which is attractive to me. The reason I recently turned to Xine seriously is that for Freevo (and MeBox) we need DVD menus, and we want better UI integration. So, rather completely on a whim, I dropped what I was working on and started hacking Python bindings for xine-lib. That's when I began to notice all the things in xine that I'd been missing out on. First, Xine has great deinterlacers, thanks to tvtime. That these deinterlacers automatically detect telecined content and adjust the framerate accordingly, or do proper framerate doubling for interlaced material, is something MPlayer just can't do. I was very pleased to see this. I didn't know it existed in xine because I was too UI-bigoted to give it a proper evaluation. Second is that the API is mostly pretty reasonable. I was able to look at the simple example and quickly make something that resembled a video player. I like the fact that I can manipulate post plugins dynamically. (GStreamer offers this too, of course, but MPlayer doesn't.) One big exception is setting parameters for post plugins. The API for this is terribly cumbersome, and if I was forced to work exclusively in C, wrapping this is one of the first things I'd do. Since I'm doing everything from Python, though, this isn't a real concern for me in practice. Since I haven't worked with GStreamer's API, I don't know how it compares to xine-lib. Third, and absolutely most importantly, is the development support offered in xine-devel. I got responsive replies to my newbie questions from xine hackers, with good, well-thought advice. Miguel even promised he would add the API features I needed for my project in the next release. Believe me, when you come from a community where an active developer routinely calls nearly everything you say nonsense, the support I received here is astounding. It's the reason I feel very confident using xine-lib in my project, even though I remain very apprehensive of the architecture's threadedness. :) I think that, by and large, you guys know where Xine needs improvement. As a user, I'd like to see faster seeking (which was recently mentioned here or on xine-user, I believe), and a richer set of video filters, including high quality software scaling. I really think a modern, attractive, and integrated front-end would go a long way to improving Xine's image. Of course, there's Totem, but I'm thinking of something that's Xine-branded, and something that provides the more advanced features of xine-ui, like being able to manipulate filter chains. Maybe that something is or will become gxine. As a developer, as discussed previously on this list, "unbuffered" post plugins and a more feature-rich OSD are the main things that would be useful to me. But xine-lib allows me to do these things myself in my application, and I think that's a testimony to its flexibility. Cheers, Jason. |
From: Alien <ali...@us...> - 2005-08-10 19:41:31
|
Op woensdag 10 augustus 2005 18:35, schreef Jason Tackaberry: > On Tue, 2005-08-09 at 20:29 +0200, Michael Roitzsch wrote: > > Now this excitement seems to have moved towards gstreamer. Why? Have > > I missed something? Did we do something wrong? Maybe xine-lib did not > > I've been interested in digital video for some years now, but have been > using MPlayer (and mencoder) pretty much exclusively. As I mentioned > before, I'd used xine very briefly in the past, but never really gave it > any serious consideration. My hacking interests have also been centered > around MPlayer. So I'm quite a newcomer to the xine scene. Maybe > that's good, as it gives me a fresh perspective to discuss this. Here > are my thoughts. > > First, let me explain why I stayed away from xine all these years. The > main reason was xine-ui. I freely admit a strong distaste for any > software that looks bad, and xine-ui looks bad. I just feel that it's a > tragically bad UI. It's reminiscent of the old Xt days: traumatic times > that I'm desperately trying to block out. Consequently, the amount of > time I had used xine could be best measured in seconds. Long enough to > load a video in xine, fiddle through the menus, observe the lackluster > list of video filters, and draw the conclusion, "There's really no > benefit over MPlayer here." =2E.. > I think that, by and large, you guys know where Xine needs improvement. > As a user, I'd like to see faster seeking (which was recently mentioned > here or on xine-user, I believe), and a richer set of video filters, > including high quality software scaling. I really think a modern, > attractive, and integrated front-end would go a long way to improving > Xine's image. Of course, there's Totem, but I'm thinking of something > that's Xine-branded, and something that provides the more advanced > features of xine-ui, like being able to manipulate filter chains. Maybe > that something is or will become gxine. > > As a developer, as discussed previously on this list, "unbuffered" post > plugins and a more feature-rich OSD are the main things that would be > useful to me. But xine-lib allows me to do these things myself in my > application, and I think that's a testimony to its flexibility. I think that the idea of xine-ui is not bad at all (the skinning idea is ve= ry=20 good), it does need a xitk improvement, the most important (but extensive=20 one) being a method of clean skinned resizing, the windows are much too sma= ll=20 and there should be a way one could resize all the windows and place button= s=20 anywhere, also with scrolling of all lists of buttons, etc... This of course breaks all compatibility in xine-ui towards skins. Also it needs to be a bit more generalized, remembering that people could=20 select bigger or smaller fonts, etc... even maybe a standardized skinning w= ay=20 of all controls and windows, that can automatically be used on any window,= =20 and then a way to override this in certain windows or certain options. the resize is quite important because the playlist (for example) is way too= =20 small. I do not believe i have ever seen an application where they have such a thi= ng,=20 winamp may have had something like this (but not completely). If this gets accompagnied by a sort of somewhat more abstraction, (just=20 keeping a thought on the fact that things can look different than intended,= )=20 this could be a great idea for xine-ui-2.0 just my thoughts |
From: Mike M. <mi...@mu...> - 2005-08-10 20:25:21
|
Jason Tackaberry wrote: > Xine feels slower than MPlayer. This perception is largely, I suspect, > due to the delays in seeking. Certainly it doesn't use much more CPU > than MPlayer, so by "slow" here I mean in terms of responsiveness. Just curious, which formats do you usually work with? I put a lot of work into making QuickTime seeking very speedy, for example. But QT is designed for that. > a necessary one.) GStreamer also has python bindings, which is > attractive to me. pyxine seems to ring a bell... I think it exists. Anyway, about all the UI issues, don't be afraid to try out the other UIs such as toxine (if you just want command line playback like MPlayer), Totem for GNOME, or Kaffeine for KDE. -- -Mike Melanson |
From: Michael R. <mr...@us...> - 2005-08-11 13:10:18
|
Hi Jason, > First, let me explain why I stayed away from xine all these years. > The > main reason was xine-ui. I freely admit a strong distaste for any > software that looks bad, and xine-ui looks bad. I just feel that > it's a > tragically bad UI. It is tradition that xine-ui is completely independent of any widget toolkit. That does not exactly simplify development... > (Also, I have noticed some things look better in MPlayer even without > filters than with Xine. I recently transcoded my Hide & Seek DVD > using > xvid and observed things looked a bit blockier in Xine. Could be that > MPlayer has a more recent and improved libavcodec. I mention this > as an > aside since I haven't had much time to look into it, so it's just a > very > cursory observation.) The quality of the MPEG-4 post processing is configurable. Maybe the settings differ in xine and MPlayer. > It is backed by a company that has a vested interest in seeing it > succeed, and that's always a nice attribute to have. Interesting, I did not know that. > One big exception is setting parameters for post plugins. Agreed, this must be worked on. > I think that, by and large, you guys know where Xine needs > improvement. Let's hope so. :) > I really think a modern, attractive, and integrated front-end would > go a long way to improving Xine's image. Of course, there's Totem, > but I'm thinking of something that's Xine-branded, and something > that provides the more advanced features of xine-ui, like being > able to manipulate filter chains. For KDE users, this would be Kaffeine. Michael |
From: Hans-Dieter K. <hd...@t-...> - 2005-08-11 23:54:59
|
Hi Jason, > First, let me explain why I stayed away from xine all these years. The > main reason was xine-ui. I freely admit a strong distaste for any > software that looks bad, and xine-ui looks bad. I just feel that it's a > tragically bad UI. Is it bad visual appearance, unintuitive operation, lack of functionalities, odd behaviour, bugs, ... ? Hans-Dieter |
From: Michael R. <mr...@us...> - 2005-08-12 10:53:31
|
Hi, > Is it bad visual appearance, unintuitive operation, lack of > functionalities, odd behaviour, bugs, ... ? I don't intend to answer for Jason, but for me, xine-ui most prominently lacks in what is called "discoverability". It has some really interesting features which do not have any obvious representation in the GUI. Not all users try to right-click all interface elements to find "hidden" context menus. But I think xine-ui is heading in the right direction and all these issues will be solved eventually. Usability being underrepresented is a common problem to a lot of open-source projects. Leaving any actual code aside, maybe some of us just need to sit down and design a reasonable usability concept for xine-ui, so we have a better idea about what needs to be worked on. Sometimes things as easy as moving some widgets around or reordering a menu can make a huge difference. Anyone interested in giving this a try? I am no usability expert but I accumulated some experience over the last year, so I would like to help. Michael |
From: Hans-Dieter K. <hd...@t-...> - 2005-08-13 02:10:38
|
Hi Michael, Michael Roitzsch wrote: > Hi, > >> Is it bad visual appearance, unintuitive operation, lack of >> functionalities, odd behaviour, bugs, ... ? > > > I don't intend to answer for Jason, but for me, xine-ui most > prominently lacks in what is called "discoverability". It has some > really interesting features which do not have any obvious > representation in the GUI. Not all users try to right-click all > interface elements to find "hidden" context menus. > > But I think xine-ui is heading in the right direction and all these > issues will be solved eventually. Usability being underrepresented is a > common problem to a lot of open-source projects. > > Leaving any actual code aside, maybe some of us just need to sit down > and design a reasonable usability concept for xine-ui, so we have a > better idea about what needs to be worked on. Sometimes things as easy > as moving some widgets around or reordering a menu can make a huge > difference. Anyone interested in giving this a try? I am no usability > expert but I accumulated some experience over the last year, so I would > like to help. > I understand what you mean. xine-ui has a lot of features and handling them is an issue that all complex applications have: For me, it's nearly impossible to operate them intuitive. Maybe we should invest in more help menus? On the other hand, I think a right-click for context menus is well-known practice nowadays and requires no special explanation (if looking for something, try a right-click). The menus have to be reasonably laid out of course. IMO a consumer video player is not easier to handle. You have to press key sequences that you can't remember to reach some desired functions, so you always need the manual, at least if you don't use them often, and nobody seems to complain about. But anyway, your suggestions match my thougths. I'm experienced since many years in user interfaces for embedded systems (e.g. electronic measurement equipment). So I'd really like to contribute to a redesign. However, my free time is very limited. Thus, it'd be very appreciable if somebody could work out a concept. Often, visual appearance makes a just subjective big difference. Is there anybody having experience in graphics design volunteering to help? Meanwhile, I'll continue to improve and patch. I'm sure there is still potential in the current design. Hans-Dieter |
From: Alien <ali...@us...> - 2005-08-13 07:12:51
|
Op zaterdag 13 augustus 2005 04:08, schreef Hans-Dieter Kosch: > Hi Michael, > > Michael Roitzsch wrote: > > Hi, > > > >> Is it bad visual appearance, unintuitive operation, lack of > >> functionalities, odd behaviour, bugs, ... ? > > > > I don't intend to answer for Jason, but for me, xine-ui most > > prominently lacks in what is called "discoverability". It has some > > really interesting features which do not have any obvious > > representation in the GUI. Not all users try to right-click all > > interface elements to find "hidden" context menus. > > > > But I think xine-ui is heading in the right direction and all these > > issues will be solved eventually. Usability being underrepresented is a > > common problem to a lot of open-source projects. > > > > Leaving any actual code aside, maybe some of us just need to sit down > > and design a reasonable usability concept for xine-ui, so we have a > > better idea about what needs to be worked on. Sometimes things as easy > > as moving some widgets around or reordering a menu can make a huge > > difference. Anyone interested in giving this a try? I am no usability > > expert but I accumulated some experience over the last year, so I would > > like to help. > > I understand what you mean. xine-ui has a lot of features and handling > them is an issue that all complex applications have: For me, it's nearly > impossible to operate them intuitive. Maybe we should invest in more > help menus? On the other hand, I think a right-click for context menus > is well-known practice nowadays and requires no special explanation (if > looking for something, try a right-click). The menus have to be > reasonably laid out of course. for starters, a small waiting time for submenu's to appear is something... |
From: Hans-Dieter K. <hd...@t-...> - 2005-08-18 19:18:50
|
Hi Alien, Alien wrote: > Op zaterdag 13 augustus 2005 04:08, schreef Hans-Dieter Kosch: > >>Hi Michael, >> >>Michael Roitzsch wrote: >> >>>Hi, >>> >>> >>>>Is it bad visual appearance, unintuitive operation, lack of >>>>functionalities, odd behaviour, bugs, ... ? >>> >>>I don't intend to answer for Jason, but for me, xine-ui most >>>prominently lacks in what is called "discoverability". It has some >>>really interesting features which do not have any obvious >>>representation in the GUI. Not all users try to right-click all >>>interface elements to find "hidden" context menus. >>> >>>But I think xine-ui is heading in the right direction and all these >>>issues will be solved eventually. Usability being underrepresented is a >>>common problem to a lot of open-source projects. >>> >>>Leaving any actual code aside, maybe some of us just need to sit down >>>and design a reasonable usability concept for xine-ui, so we have a >>>better idea about what needs to be worked on. Sometimes things as easy >>>as moving some widgets around or reordering a menu can make a huge >>>difference. Anyone interested in giving this a try? I am no usability >>>expert but I accumulated some experience over the last year, so I would >>>like to help. >> >>I understand what you mean. xine-ui has a lot of features and handling >>them is an issue that all complex applications have: For me, it's nearly >>impossible to operate them intuitive. Maybe we should invest in more >>help menus? On the other hand, I think a right-click for context menus >>is well-known practice nowadays and requires no special explanation (if >>looking for something, try a right-click). The menus have to be >>reasonably laid out of course. > > > for starters, a small waiting time for submenu's to appear is something... Good idea! I'll see what I can do. Hans-Dieter |