Gstreamer, versions, documentation, frustration

Submitted by gwolf on Mon, 07/24/2006 - 19:00
I've spent a couple of weeks half-working my way towards an application to capture, recode and stream media, much in the fashion of what the very fine video team managed to do for Debconf6: Recording, encoding and streaming a live video feed via an Icecast server. Why didn't I just follow the easy path? Basically, because it's not friendly enough to be used by our camera operator at the Institute. So, I'm working on a simple GUI that will wrap the process, and provide feedback on its working. Feedback? Yes. We streamed the Mexican economy seminar using the simple commands, but the camera guys were so nervous on whether the process would work reliably that they phoned me every 40 minutes to check if the stream was alive. Originally, I worked on a wrapper to the different processes - but controlling the status on each of them didn't turn out to be as robust as I expected, and it's somewhat unnatural to dynamically plug/unplug elements in the pipeline (i.e. to show/hide a monitor to check the video being captured). I turned to Gstreamer. Anyway... I took this as an opportunity to do my first real Ruby work. Ruby is a very nice language, very natural to write and quite easy to understand so far. What's really lacking in it is the documentation. So far, I've referred to different online books and tutorials when doubting about its syntax, and to the GStreamer tutorial, the Ruby/Gstreamer API reference, and the Application Development Manual. The problem? Simple: I have to refer to online documentation, against what I've grown used to with Perl, having full documentation as part of each of the modules. In general, I've found the Ruby community -both on my first approximation, to Rails, and on this one- make really great tools, but are not very keen on documenting. And rubydoc might come from the same basic ideology as perldoc, but while perldoc is natural to check just as if it was a manpage, a rubydoc set of documentation has to be processed/compiled into its final (and, yes, often beautiful) form... Losing in the process a lot of the usability. In the end, my gripe comes because the documentation does not reflect reality. When the documentation is decoupled from the code. Quite a few methods or even classes are supposed to exist, while they don't. The documents I've been referring to don't show a version number
( categories: )