GStreamer announcements

Works fine for me (0.8.8).

That's an application thing for playlists, add a feature request for RB.

No, you don't need GNOME if you're going to use only general-purpose elements (GStreamer even compiles on Microsoft Windows). Even Totem (the video player) can be compiled with GTK only. You'll lose the gnome-vfs plugins, which provide access to remote files (via SMB, for example). To compile GStreamer you only need Glib (which is already required by GTK+).

In the Totem webpage says that gnome is required :S

under "Features" at http://www.hadess.net/totem.php3 it says "Optional GTK+-only build"...
Disclaimer: I'havent actually built it myself without GNOME.

Is there an option to build it with the regular gnome libs but without the stupid burn libs. Why require a cd burner library for a video player?

because it includes a widget for DVD drive selection that we use. There is no option to disable it.

I don't even have DVD drive. Why I still need nautilus-burn? Please, wrapping code for DVD selection in couple of #ifdefs is pretty easy. nautilus-burn should be optional dependency (for those wanting DVD selection).

--
:wq

If you submit a patch, there's a good chance it'll get accepted, I'm not sure about Bastien, but I'm OK with it. As long as the default is yes.

-- Ronald

Uhm. Please. Don't be so unfriendly. He makes a small but valid point. I suggest he goes to Bugzilla and write about this and perhaps its gonna be fixed. Its small, but also pretty easy probably. :)

Well, for me it's a very valid remark, not anything even remotely unfriendly. I am going to dig into totem code, try to make dependency optional and then make a bugzilla entry with patch. I don't have time right now (exams :/) but in two-three weeks I hope I do it.

--
:wq

Commercial linux vendors (RH, Novell etc.) have full time employees working on GNOME.

So I guess if the things you are complaining about are really important for commercial deployment these companies will put resources on fixing these bugs. If it's really important for you why don't just go to this companies and say I'm willing to buy your linux solution if these things gets fixed. Or you could hire a programmer yourself to fix it.

Volunteers in general will only fix what bothers them most, not what bothers you most.

You could also opt for a bounty for these problems.

Hehe, while a puzzle game may sound like a stupid gimmick, it's actually very useful for testing. It tests if interactivity (capturing mouse clicks and keyboard) works. And it's far easier to debug a simple puzzle game than a full blown dvd player. It's more fun, too.
Besides, it's so addictive, I'm starting to think it was a bad idea I even coded it.

Benjamin

PS: I still have the luxury to code for fun, so I can decide to not care about your company's issues and do what I want instead. :)

PS: I still have the luxury to code for fun, so I can decide to not care about your company's issues and do what I want instead. :)

Hahaha... Love the comment.. I think sometimes we need to be a little more light hearted about strong feelings people have and it's good to see a little jab back from the developers occasionally >:-)

PS: The puzzle really does look interesting, I am going to have to try it out. It is a really good example of the power of the gstreamer framework..

"PS: I still have the luxury to code for fun, so I can decide to not care about your company's issues and do what I want instead. :)"

Don't take this the wrong way, but it's this kind of attitude that makes Gnome just that much less professional and serious in the Desktop Arena. While yes, you are doing it for 'fun' and for the love of it, inadvertantly you are telling a lot of market share that they just don't matter to you or other developers.

Imagine how much more coverage, testing, and possible sponsership you could get if every developer of Gnome had the complete opposite attitude of you? I agree with the original poster; hammer out more wrinkles, and fix what's already broken. Who knows, it may make those fun things even more fun to do in the future. :)

I'm not saying that someone should do this and that or that the game is stupid, it does sound really cool.
I also understand that generally programs are written to scratch an itch, and that it is far more fun writing puzzle game than debugging old code or code that does not interest you that much.

Why should you care about my company's issues, it their issues and not yours, but I was using it as an example, of why more people are not switching over.

I personaly use GNOME at home and at work (I have the luxury to generally setup and make sure my pc interacts with everyone elses, plus they are sick of my moaning on using Windows, I was allowed to make the switch), but the MD caught me using it, and got interested, hence my comment.

So more people would make the switch if those new features would simply not be developed and the programmers would decide to spend their valuable freetime playing chess instead? I don't think so.
Freetime development is one huge advantage of free software, and the main reason why it can compete with proprietary software backed by a lot more money. It seems to be "en vogue" to complain about any new features where stability and bugfixes are desired, but it's really silly and unproductive. There are many paid free software developers who keep focusing on polish and fixes, and there even are lots of sparetime developers doing the same (which should be highly commended!) but you can't (and shouldn't!) force anyone to stop working on cool things just for fun. Especially when you are not the one doing the work. :P

This discussion makes me wonder.... Does bugzilla or any other tool keep track of how many bugs were caused by a particular person? I don't mind a "free time" developer putting in new features, but it's not good to have them put in new buggy features and leave the cleanup to someone else. I'm not aware of any specific problem, and I hope this is what patch reviewing is all about. It just occured to me that there could be some people out there that shouldn't even be allowed to submit new features - these guys exist in the commercial world for certain :-)

Try the latest Rhythmbox with a recent GStreamer release. Audio playback works smoothly (at least it can play my 10.000+ mp3 & ogg collection without problems). Video playback is more problematic, but recent releases are working way better than older ones.

I'm using Rhythmbox 0.8.8 and GStreamer 0.8.6/0.8.7. Crashes or hangs at least 3 or 4 times a day.

RB and GST are cool in concept, and I use them every day, but I wouldn't recommend them to others yet. Audio playback is OK, but not ready for the "just works" primetime yet.

It's a while since I looked, but does rhythmbox support tag editing yet? Without it the program was completely pointless.

Simply saying "it hangs" isn't useful to anyone. Launch rhythmbox with the "-d" command line switch, it should give some ideas on what is going wrong.

Your claim that hang/crash bugs are being basically ignored is bogus. Such bugs are getting top priority and have fixed in great numbers. Only hang bugs left open for a longer period time in bugzilla atm is bugs without a real testcase or where we are unable to reproduce.

If you have a media file which you notice cause hangs/crashes when you play it, file a bug report and provide us the file either by attaching it to the bug report or by making it avaialble somewhere and I assure you it will be looked at very quickly.

I don't know if you noticed that recent gstreamer, plugins and ffmpeg releases have contained long lists of numbers. These represent bugs fixed for the release, not random bingo numbers.

From reading gnome planet you GStreamer people seem to be fixing bugs at such a fast rate that there hasn't been enough time to get these out to users in general. If so you should probably be ready for the general feeling about gstreamer to lag the reality for awhile.

For example, it probably won't be before the release of Ubuntu Hoary before I see the new GStreamer work.

Thanks for all the work.

js

We realize that, bit sometimes it's a bit frustrating to see people complain about bugs we never fix whereas it was fixed two weeks ago already. ;-).

Ohwell, that's reality. :-(.

File bugs.

Wow, that's such a helpful thing to say. Why didn't I think of that? :P

I have filed bugs in the past, but these days I don't bother unless it's really bad (like dataloss). They're getting really good at ignoring bug reports, so it's not worth my time.

If you search the bug database, you can turn up plenty of crashing/hanging bugs in Rhythmbox and GStreamer, which were marked "Priority: Urgent" and "Severity: major", and then ignored.

I've written and maintained open-source programs, so I'm no stranger to the process. Filing bugs does not help if the developers don't make stability a priority.

A quick bugzilla query turns up 19 bugs for "rhythmbox crash" and 12 more for "gstreamer crash". I think someone should know there is a stability problem...

And you think we don't know that? That's funny. :).

There's two reasons for you to file reports, even though they're likely duplicates:
(1) it tells us which bugs uses are seeing a lot and thus which are important.
(2) it notifies you of questions on the bug report from ourside and notifies you when progress is made or the bug is fixed.
We probably have around 50 crashers in bugzilla, and I regularly spend full days on fixing those. If you look at the amount of fixed bugs, you'll see that. If you look at the bugzilla statistics, you'll see that. However, since we have a constant flow of new incoming bug reports, there will always be some open reports. And to continue that cycle, see point 1 and 2, we need you to submit those bug reports and follow them.

We care a lot about stability. We've made an impressive progress in the past few months in that area. Your attitude will not help us at all to continue that track.

If you want to get good bug reports from people, you have to make it easy to do so. (I could file a bunch of bug reports consisting of "it stopped responding; no idea where or why, cannot reproduce", but would that really help anybody?)

For example, in order to know where it died, you want the output from the '-d' switch. Who knew?

If it was my program, I'd keep the last 50 lines of debugging info in a file somewhere. That way, if the program crashes, people could send me exactly where it screwed up. (I've done this before, and the usefulness of bug reports went through the roof.)

Asking people to run "rhythmbox -d" from a terminal all the time is a CYA response, not a productive one. By definition, those of us who want to use something simple and easy like Rhythmbox are not going to want to dork around on the command line.

(And if your reaction to this is "Well, just write a shell script to capture it to a file and make a panel launcher to point to that", go back and reread the previous sentence.)

There's good reasons not to do it.

* keeping debugging turned on all the time in apps such as Rhythmbox can be expensive.
* keeping debugging turned on in GStreamer-style is friggin' expensive (ever tried? Start a gst app with GST_DEBUG=*:5 as environment variable - enjoy). Not only that, but the last 50 lines are pretty much useless. I need a log of the full run to see what happens, and preferrably with specific categories turned on only. That's why I ask for specific logs in bug reports.
* the most important thing is usually a gdb backtrace. Valgrind can help a lot too. You don't want to run in gdb/valgrind by default, believe me.

Debugging is debugging. If that makes it less reproduceable, well, bugger, but at least the application is usable.

Over the last month we moved from patchy playback support for major formats to playing any of these files which have a free open source decoder available. Currently I am able to play all quicktime, avi, mpeg, ogg theora/vorbis and matroska, mp3, wav and flac I have.

We have added subtitle support and greatly improved DVD support. ALSA seems to work reliably for people now. This release adds MMS protocol support.

Are there still missing items? Sure, DVD still needs work and there are probably media files out there with quirks we don't cover yet. We still have some issues with some Ogg streams. And while we have put a lot of effort into playback recently there are still issues in regards to aquisition, encoding and manipulation which new applications like Flumotion, Cupid, Thoggen and PiTiVi are exposing.

I feel confident that we will pretty much get there in regards to playback, at least for major formats. I am not sure we can guarantee that every obscure format out there will work, like Nitendo sound system files etc., but work is being done on it. I am guessing we will have DVD support through Totem working before 2.10 which basically works, but it will probably have less functionality than a commercial DVD player does atm. One thing I do not expect to see before 2.10 is RTP/RTSP support, but I never seen anyone complain about it either so I guess its not high on users wishlist anyway.

In regards to other functions the people working on applications in these areas as contributing a lot of fixes back so even there I am hopefull that most things will work, but maybe not up to a 'just works' level as that implies everything works almost to perfection.

"One thing I do not expect to see before 2.10 is RTP/RTSP support, but I never seen anyone complain about it either so I guess its not high on users wishlist anyway."

I only have the vaguest notion of what RTP/RTSP is.

I know that when I click on a multimedia file in my web browser, I have maybe a 50/50 chance of being able to view/hear it. If it doesn't work, I move on.

I'm not saying I want support for this, but I don't think you can jump from "nobody complains about it" to "nobody wants it". How many people understand what RTP/RTSP is? Who would know to ask for it? (Not I.)

About the RTP/RTSP issue:

IIRC, RealVideo and maybe RealAudio streams use these protocols. If that is the case, I for one would _really_ like it to be supported. Real's codecs are not very good, but many websites use them, so I feel that it is key to have it supported.

Since FootNotes is not where all the developers look, where should I go to let them know that at last one person feels strongly about having RTP/RTSP support working, and working well.

Thanks,
--Farrell F.

P.S. If I could code decently, I would definitly work on it. Right now all I have under my belt is a semester of an introductory C++ class...so even if I could some how manage to get something half-decent done, it would not really be even close to usable, quality work.

Bugzilla is always the best place. RTP/RTSP will happen eventually as Fluendo is sponsoring Xiph's work on RTP specifications for Theora and Vorbis.

This is great news!

It would be great, if we from Gnome 2.10 and on could use Totem for daily video viewing, and keep MPlayer for dumping RTPS/RTSP files =)

Do you know if the long term goal is to replace MPlayer and libxine with the ffmpeg library for GStreamer?

Not sure what you are asking. If you are asking if we plan on using xine or mplayer instead of ffmpeg as the decoder source, then no. GStreamer is LGPL and tries to only use LGPL libraries (which ffmpeg is) whenever possible. If you are asking if we hope to have GStreamer as a generic media framework replace Xine and Mplayer as media player backends in general, then yes.

If you are asking if we hope to have GStreamer as a generic media framework replace Xine and Mplayer as media player backends in general, then yes.

Yes, just that=)

How does the Xine and MPlayer developers feel about this?

Is the plan to port all the dll files that MPlayer uses, or to make a framework to read dll files?

We will reverse engineer all dll files until we have free software implementations of each of them. None of the developers is interested in writing a dll loader right now. Feel free to change our mind.

"We will reverse engineer all dll files until we have free software implementations of each of them."

I've heard that doing a clean, legal "black-box" reverse engineering on a modern video codec is about like breaking strong encryption with a slide rule and pencil. Is this true, and can we expect a free WMV9 decoder anytime before the sun expires?

I know that nobody here likes proprietary formats (like wmv9) or ugly hacks (like dll loaders), but there is a lot of content out there that free software users are missing out on right now...

It is a public standard - but without the roylties you see with e.g. Mpeg4.

So no reverse enginering should be necesarry to make it work with gstreamer.
There is already an Open Source plugin to VLC working in Linux.
http://www.nanocrew.net/blog/

The nanocrew code is based on copyrighted code and cannot be released un der (L)GPL. That'd break legislation in about every country in the world. The VC1 standard is public and I've actually got a copy. Several people are working on writing it. It's not so bad.

VC1 does need royalties, just like MPEG. It's heavily patented.

I read the Doom9 Codec shoot-out 2004 where the Nero Digital codec did very well.

Does the GStreamer folks have any codec support priority for any of these codecs?

And in case; Does a Open Source codec have a higher prioity?

Regards and keep up the good work :)
Amadeus