path: root/src/htdocs/news/status.xml

<!DOCTYPE xsl:stylesheet
[
  <!ENTITY % site-entities SYSTEM "../entities.site">
  %site-entities;
]>
<status>
  <item>
    <title>GStreamer status, 20 Sept 2005</title>
    <date>2005-09-20 00:00</date>
    <content>
<pre>
Aloha hackers,

This is the first installment of what I hope will be a weekly or
biweekly newsletter on the state of GStreamer. You will find in it a
discussion of recent API changes, bug and release status, and notes on a
featured application built with GStreamer. I hope you enjoy this first
one. Let me know what you think about it, good or bad, and especially
let me know if you want to write a paragraph or so about your area of
GStreamer interest.


Recent Core Changes
-------------------

The registry recently underwent a rewrite at the hands of David Scheef.
Developers will notice that there are no more pluggable registries or
registry pools, and that some of the plugin/pluginfeature semantics have
changed. Users will notice that there is no more gst-register. Initial
reports show this registry to be faster at rebuilding than the old one
and that run-time rebuilding actually works. Someone should port the
gnome-multimedia utilities to 0.9 to see how the changes affect Gnome
startup time :-)

Also, Wim Taymans checked in some bus-related changes. What was called a
GstBusHandler is now a GstBusFunc, to match the naming of GSourceFunc,
and its return value is just like any other GSourceFunc -- that is, TRUE
to keep the source in the GMainContext, and FALSE otherwise. Also, now
you can attach multiple bus watches, each listening to a different set
of events. A related change is that gst_bus_poll now returns the actual
message that was received, not just its type -- no need to explicitly
pop the message off the bus anymore.

In other changes, Stefan Kost checked in a patch to use GLib 2.8's
atomic refcounting for GObject, which was something Wim pushed hard for
in GLib's last development cycle. Of course, we still support the hacks
that allow GStreamer to work reliably with GLib as old as 2.4, but you
have to be careful when getting an object from GLib, as with
g_value_get_object.

David also recently removed our atomic memchunk and trash stack
implementations, which is related to ongoing work in GLib -- see
http://bugzilla.gnome.org/show_bug.cgi?id=118439. This change shouldn't
affect anyone out there.

Thomas on the other hand has continued on his masochistic selfless quest
for quality, adding a 'make valgrind' target to the build. He will be
rewarded in heaven.


Buildbot status
---------------

The buildbot configuration has been partly upgraded for some slaves to
build the new modules. The Mac OSX buildslave is on a short holiday
while it's being upgraded. The Fedora Core 4 slave will now be
valgrinding and reporting leaks as failures.

Remember - if you're not part of the solution, you're part of the
problem ! Buildbot will still blame you if you keep committing to a tree
that's in a broken state. So hold off committing if the tree is broken
and you're not trying to fix it yourself.

We are still looking for more build slave platforms to add to our
system.  In particular, a Windows slave would be great.


Meanwhile, Back At The Ranch
----------------------------

Or, notable activity in the plugins modules. Have you checked out the
plugins documentation[1]? Go and see it and then tell Thomas how awesome
he is. The goal here is to have every element come with either an
example launch line or a small program that demonstrates the use of the
element. This is a very simple thing for new developers to be
contributing to and it helps in understanding how GStreamer works.

gst-plugins-base: Leak fixing, a new RTP payloader base class, 24 bit
audioconvert

gst-plugins-good: Work on RTP payloaders (AMR, GSM, H263, MP4, MPA),
wavparse updates

gst-plugins-bad: A ported SDL video sink, yay

gst-plugins-ugly: lame updates, documentation work

[1] &site;/documentation/plugins.html


Bug Activity
------------

Total number of GStreamer bugs as of today : 200
Number opened in the last week             : +21
Number closed in the last week             : -22
Net change                                 : -1

GStreamer is currently number 9 on the list of projects with the most
bugs in GNOME bugzilla. Our project is a pile of bugs!

Luca Ognibene has put together a triaged list of bugs for the stable
series (0.8) here[2]. Some of these are low-hanging fruit, and it's an
easy-to-read list -- check it out if you have half an hour free
sometime.

[2] http://skaboy.no-ip.org/~luogni/gst08-bug-status-20050919


Featured Application: Banshee
-----------------------------

Christian Schaller lets us know about this week's featured application.

A lot of application development is being done using Mono and C# these
days and Banshee is no exception. Banshee is a music player being
developed with the support of Novell with a interface similar to what
you find in applications such as iTunes and Rhythmbox. Banshee is has a
lot of work being put in to support seamless syncing with Apple iPods
and includes its own GStreamer mp3 encoder for instance to acomplish
this. Doesn't yet support the DAAP music sharing like Rhythmbox does for
instance, but if iPod support is what you want then this is definetly
the application to look out for. Banshee is licensed under a MIT style
license. You can find out more on the Banshee homepage:

http://www.banshee-project.org/index.php/Main_Page


Well that's all for this week. Thanks to Thomas, Luca, and Christian for
their contributions to this week's edition, and if you want to write
something for next week, send it along to me, preferably before Monday.

Until next time,
-- 
Andy Wingo
http://wingolog.org/
</pre>
</content>
  </item>
  <item>
    <title>GStreamer status, 28 Sept 2005</title>
    <date>2005-09-28 12:48</date>
    <content>
<pre>
Hey folks,

It's a marvelous mercredi we have here, and a nice time for the second
edition of the GStreamer status report. So prop up your feet, grab a
GStreamer-approved beverage and relax as we go over the crucial
happenings of the last week.


The Bleeding Edge
-----------------

Stefan Kost is the hero of the week, for completely inlining all of
GStreamer's API documentation into the source code. Now the primary
source for all of the API documentation is maintained right beside the
API itself, which should help to increase the long-term quality of our
documentation. Go Stefan!

Interestingly enough, there were no actual API changes this week, as far
as I can tell -- just function additions, and moving around header files
as part of the documentation work. Added API includes structure field
and GstValue accessors for GstClockTime and GDate. Also,
gst_object_has_ancestor was made public, and fdsrc was ported and moved
to the core.

As an internal detail, Wim rewrote the state change algorithm this week.
Changing the states of a bin's children is a tricky operation in 0.9,
because changing state can cause elements to start pushing or pulling
data in another thread. Obviously this can only work if the other
elements in a bin are in the correct state to start processing when the
thread starts. The problem of determining the order in which the
element's states should be changed is complicated by allowing element
additions and removals from other threads while performing the state
change.

Wim solved this gracefully by implementing a GstIterator that iterates a
bin's children in state-change order, having done a topological sort,
and then folding over that iterator. Wow. I guess there's a reason we
keep him around.

Also, one of our primary data structures is acquiring a dependency on an
outside library. Congratulations to Jan Schmidt (thaytan)'s marriage to
Jaime Hemmett!


Meanwhile, Back At The Ranch
----------------------------

The "base" plugin set saw the normal set of bugfixes, some work on the
RTP payloader base class, seeking optimization work in playbin, and
general refactoring in sinesrc, the tcp elements, and audio sink base
classes.

News from the "good" plugins includes Tim Müller's fixing of OSS
playback of mono streams, fixes when demuxing AVI files containing
unknown types, refactoring in the level element by Thomas, porting of
auparse from 0.8 by Edgard Lima, and the normal batch of RTP work from
Wim.

In the "ugly" set, there were bugfixes in mp3parse and amrnbenc, and
Michael Smith wielded a sword of righteousness over the AC3 framer for
S/PDIF output.

Finally, the ttaparse and gsmdec plugins were ported to 0.9 by Arwed v.
Merkatz and Edgard Lima, respectively.


The Path To Release
-------------------

Andy Wingo proposed a tentative schedule[1] for GStreamer development
releases, culminating with 0.10.0 on 5 December. As part of that plan,
expect to see a 0.9.3 release of GStreamer and plugin modules on Monday
3 October. See the mail for more details.

[1] http://article.gmane.org/gmane.comp.video.gstreamer.devel/13768


Bugs
----

Total number of GStreamer bugs as of today : 206
Number opened in the last week             : +18
Number closed in the last week             : -23
Net change                                 : -5

GStreamer is currently number 8 on the list of projects with the most
bugs in GNOME bugzilla, which is one place higher than we were last
week.

On the 0.8 side of things, Luca Ognibene has been doing some great
work dealing with bugs. He could use a bit of help now, though -- check
out his recent mail to the list[2] for ways you can help.

[2] http://article.gmane.org/gmane.comp.video.gstreamer.devel/13808


Featured Application: Istanbul
------------------------------

Christian Schaller once again brings us this week's featured
application.

    Istanbul is a nice GStreamer based application made by Zaheer
    Merali. It gives you a small notification area icon which by a click
    of your mouse lets you stop or start recording sessions of your
    desktop. The resulting video is stored as an Ogg file. This is a
    quick and easy way to to create desktop videos demonstrating your
    favourite desktop application feature. And its all free software and
    using free media formats. You find more on Istanbul here:

    http://live.gnome.org/Istanbul

Thanks, Christian!


Well, that's about all for this week. Happy hacking!
</pre>
</content>
  </item>
  <item>
    <title>GStreamer status, 05 October 2005</title>
    <date>2005-10-05 00:00</date>
    <content>
<p>
Mwa lala po oohacker yoGStreamer,
</p>

<p>
It's that time of the week again, where we take a caffeine-assisted look
at last week's events in GStreamer. So whether you percolate, filter,
steep or express, fill your mug and prepare to be educated.
</p>

<h3>Release, Release, Release, Release, Release, Release, Release</h3>

<p>Seven of them, my friends. Version 0.9.3 of GStreamer core,
plugins-base, -good, -bad, -ugly, ffmpeg, and gst-python were released
on Monday by Master Builder Thomas Vander Stichele (+47 endurance).
Check the main page[0] for links, and check the 0.10 roadmap[1] to see
how we're doing for the release. The next releases will be on 17
October, at which point the API will be frozen for four weeks. Any API
changes after 17 October will have to go through bugzilla, be reviewed,
and applied on 14 November. API stability for that time means 17 October
will be a great time to start porting your application to 0.9.
</p>


<p>[0] &site;/<br/>
[1] http://article.gmane.org/gmane.comp.video.gstreamer.devel/13768
</p>

<h3>Core Happenings</h3>

<p>GStreamer is an abnormal GObject-based library in that it is
multithreaded. Because GTK+ is normally programmed from one thread,
programmers are not accustomed to having to think about concurrency. To
make application programming simpler, GStreamer 0.9 offers the ability
to marshal messages from the pipeline into the main thread.
</p>

<p>GStreamer does this by the use of a bus, where messages are received,
handled synchronously, and then depending on the return value of the
synchronous handler they can be placed on a threadsafe queue. There is
GLib integration that creates a GSource to operate in the main context,
so you can handle messages from this queue in your main loop.
Integration with other main loop APIs is also possible.
</p>

<p>Last week Wim Taymans made it even easier to use the bus. Now the
suggested way to use the bus is to connect to signals on the bus instead
of installing a bus watch. To listen for all messages, you connect to
the "message" signal. To listen for only EOS messages, you can connect
to "message::eos" (using the "detailed signal" functionality in GLib).
To use these signals, you will have to first call
gst_bus_add_signal_watch(), to add the bus integration to the main loop,
and gst_bus_remove_signal_watch() to clean up.
</p>

<p>You also have to option to receive signals synchronously via the
"sync-message" signal, but most programmers will find the "message"
signal to be more convenient.
</p>

<p>Other core changes include the normal bug fixes, refcount fixes in tee,
and the destruction of a couple of race conditions that affected mp3
playback.
</p>

<h3>Plugin Activity</h3>

<p>Cutting to the quick, a brief look at activity by module:
</p>

<ul>
<li>base: more robust error handling in ogg, theora, vorbis; cleanup fixes</li>
<li>good: rtp payloading bugfixes, enable tag reading in flacdec, flacenc
        ported to 0.9, cleanup fixes, dv query fixes</li>
<li>bad: qtdemux locking fix</li>
<li>  ugly: elite real demuxer work by Michael Smith</li>
</ul>

<p>FFMpeg also has gotten some love these days from Thomas and Wim.
</p>

<h3>Bug Status</h3>

<center>
<table width="50%">
<tr><td>Total number of GStreamer bugs as of today</td><td>207</td></tr>
<tr><td>Number opened in the last week</td><td>+13</td></tr>
<tr><td>Number closed in the last week</td><td>-23</td></tr>
<tr><td>Net change</td><td>-10</td></tr>
</table>
</center>

<p>We are again #9 in the GNOME bug rankings. Frankly though I don't see
how these numbers add up -- we were at 207 bugs last week. Does this
prove the existence of a divine being? Stay tuned next week to find out.
</p>

<h3>Current Releases</h3>

<p>Thomas considers it crucial that each and every one of you tatoo this
information to your forearms.</p>

<h4>Latest development versions</h4>
<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-base</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-good</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-bad</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-ugly</td><td>0.9.3</td></tr>
<tr><td>gst-ffmpeg</td><td>0.9.3</td></tr>
<tr><td>gst-python</td><td>0.9.3</td></tr>
</table>
</center>

<h4>Latest stable versions</h4>
<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.8.11</td></tr>
<tr><td>gst-plugins</td><td>0.8.11</td></tr>
<tr><td>gst-ffmpeg</td><td>0.8.6</td></tr>
<tr><td>gst-python</td><td>0.8.2</td></tr>
</table>
</center>

<h3>Featured Application: Thoggen</h3>

<p>Christian Schaller lets us know how to back up DVDs with GStreamer.
</p>

<blockquote>
    Looking for a tool to backup your DVD's? Well you are in luck. This
    week we take a look at Thoggen, written by Tim Müller, which gives
    you a nice looking GTK+ GUI for ripping your DVD's into Ogg files.
    It uses HAL/d-bus for DVD detection and provides nice features such
    as preview, picture cropping and picture resizing. So free yourself
    from DivX and move into the world of Ogg.
</blockquote>

<blockquote>
    You find Thoggen and lots of screenshots on the Thoggen website,
    http://thoggen.net/.
</blockquote>

<p>
Well well, there went another week and this status newsletter is all we
have to show for it, that and some code and tarballs and stuff. I'm now
syndicating this newsletter over RSS at
&site;/news/status-rss-1.0.xml, for the more
technologically inclined out there. However it is you read, farewell for
another half-fortnight. Tu hackeni nenyanyu (Happy hacking).
</p>
</content>
  </item>
  <item>
    <title>GStreamer status, 05 October 2005</title>
    <date>2005-10-13 11:57</date>
    <content>
<p>
Goeiemorgen GStreamer hackers,
</p>

<p>
Another day, another dollar, another 1000 lines of ChangeLog. You are
tuned into Radio GStreamer, operating at a frequency of 0.131 summaries
per day, which, when the DJs are not sipping piña coladas and letting the
radio software play some chilled-out dub, is all about some crucial
GStreamer news. Represent.
</p>

<h3>
The Coming Winter
</h3>

<p>
As our plan for 0.10 [0] indicates, the frost is coming. After Monday 17
October, GStreamer will enter an API freeze. Much of the frenetic
hacking this last week has focused on dealing with the things we
normally ignore, like dirt under the fridge.
</p>

<p>
Command-line argument parsing is now done with GOption instead of the
byzantine relic known as popt. The GST_FLAG_IS_SET macro and friends
were renamed to GST_OBJECT_FLAG_*, and the flags themselves are now
declared as flags instead of enums. gst_element_get_state now takes a
GstClockTime instead of a GTimeVal for the timeout, the newsegment
events got a new boolean flag only to be used by Wim Taymans, and
iterators now declare which GType they are iterating over so as to be
more bindings-friendly. Clock distribution got the Taymans treatment,
including a new provide_clock vmethod in GstElement. Tim Müller sped up
typefinding while fixing some bugs. Also, there's a new type of
messages, TYPE_ELEMENT, which is designed for element-specific
notifications. GStreamer will not post TYPE_APPLICATION messages
anymore; those are reserved for you.
</p>

<p>
But by far the largest change of the past week was Wim's state change
patch. Before this week, applications had to keep a rather complicated
model of GStreamer's state in order to deal with all possible pipeline
behaviors. Setting a pipeline to PLAYING could block or not depending on
an object property on the GstPipeline object; it could succeed all the
way up to PAUSED but not try to go to PLAYING in some cases; error
conditions were poorly defined; sometimes messages would be posted and
sometimes not. It was more complex than it should be.
</p>

<p>
The core of the patch was rather simple. The state lock was made into a
recursive mutex that can be waited on. Setting the state on a bin simply
sets the state on all elements and returns even if some elements are
changing state asynchronously, instead of blocking like GstPipeline used
to do. Elements record the state that they are trying to go to; that is,
if you set an element to PLAYING that is in READY, its _current_ state
will be READY, the _next_ state is PAUSED, but the _pending_ state is
PLAYING. Then when it commits its state either by returning SUCCESS from
the change_state function or manually in the case of ASYNC elements
(sinks mainly), it pulls itself up recursively into the _pending_ state
(PLAYING in this case).
</p>

<p>
After the patch, things are much more simple. Setting a pipeline to a
given state will either result in success or error. Messages will always
be posted. There are a couple of bugs still but we are confident they
will be ironed out soon. That or we send Wim to go work on MPlayer.
</p>

<p>
[0] http://article.gmane.org/gmane.comp.video.gstreamer.devel/13768
</p>

<h3>
Plugin Activity
</h3>

<p>
Our wire services indicate the following changes in the plugins modules:
</p>

<ul>
<li>base: multifdsink bugfixes, audiosink bugfixes, typefind leaks
        plugged, adder querying added, addition of a most rocking
        audiotestsrc by Stefan Kost, tcpserversrc state change fix,
        unsigned audio in alsaink, playbin seeking fix</li>
<li>good: cairo timeoverlay ported to cairo 1.0 API, speexenc ported by
        Edgard Lima, error handling in oss elements, dv1394src made
        nonblocking and interruptible (and it posts a message when the
        cable is plugged/unplugged), many debugging plugins ported by
        Tim Müller (progressreport, navseek, navigationtest, testsink,
        breakmydata)</li>
<li>bad: faac bugfixes</li>
<li>ugly: mad bugfix, amrnbdec bugfix</li>
</ul>

<h3>
Build Status
</h3>

<p>
We are pleased to announce that Thomas Vander Stichele now the proud
godfather of a new buildslave running FreeBSD, thanks to Koop Mast for
naming Thomas to this honored position. Also the Fedora Core 3
buildslaves have been removed, as they do not support GLib 2.6, and the
OS X buildslaves have been reenabled thanks to Stephen Thorne.
</p>

<p>
For a while now we have also had a monster of a Power 5 machine running
builds from Augsburg, Germany. /proc/cpuinfo says it has 32
processors!!!!! Thanks to Thomas Morpe and the debian-ppc folks over at
http://tuxppc.rz.uni-augsburg.de/ for the use of this machine.
</p>

<h3>
Vital statistics
</h3>

<center>
<table width="50%">
<tr><td>Core files changed this week</td><td>166</td></tr>
<tr><td>Lines added this week</td><td>10082</td></tr>
<tr><td>Lines removed</td><td>2947</td></tr>
<tr><td>New change in core value according to sloccount(1)</td><td>+$88,294</td></tr>
<tr><td>Total number of GStreamer bugs as of today</td><td>209 [1]</td></tr>
<tr><td>Number opened in the last week</td><td>+23</td></tr>
<tr><td>Number closed in the last week</td><td>-20</td></tr>
<tr><td>Net change</td><td>-3</td></tr>
<tr><td>Rank among most buggy projects hosted in gnome bugzilla</td><td>8</td></tr>
</table>
</center>

<p>
[1] Not counting enhancements; this discounts the
divine-beings-are-munging-our-bug-counts theory, but leaves open the
possibility of malicious gremlins.
</p>

<h3>
Current Releases
</h3>

<p>
No new tarballs were dropped on the world this week. Monday, however,
will see the release into the wild of the 0.9.4 development versions.
</p>

<h4>Latest development versions</h4>
<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-base</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-good</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-bad</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-ugly</td><td>0.9.3</td></tr>
<tr><td>gst-ffmpeg</td><td>0.9.3</td></tr>
<tr><td>gst-python</td><td>0.9.3</td></tr>
</table>
</center>

<h4>Latest stable versions</h4>
<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.8.11</td></tr>
<tr><td>gst-plugins</td><td>0.8.11</td></tr>
<tr><td>gst-ffmpeg</td><td>0.8.6</td></tr>
<tr><td>gst-python</td><td>0.8.2</td></tr>
</table>
</center>

<h3>
Featured Application
</h3>

<p>
Christian Schaller, our foreign correspondent in Norwegia, was too busy
researching a hot lead to send us a featured application this week. Stay
tuned next week for his report.
</p>

<p>
That brings this piece to a close. My fellow DJ's appear to already be
in dub-and-piña-colada mode, so I am taking that as a sign from the most
high. From our broadcasting office in Barcelona this is Radio GStreamer
signing off. Tune in again in 1/0.131 days!
</p>
    </content>
  </item>
  <item>
    <title>GStreamer status, 21 October 2005</title>
    <date>2005-10-21 16:26</date>
    <content>
<p>
God kveld GStreamer hackere,
</p>

<p>
Happy Friday to everyone across the land. The days slip by and we still
do work, accelerating time's arrow by reducing entropy in our CVS.
Depressing? No my friends, we party while the ship sinks. At least when
we're not reading dinosaur comics[0], that is.
</p>

<p>
[0] http://www.qwantz.com/index.pl?comic=116
</p>


<h3>
The Flocculator
</h3>

<p>
Remember Wim's state change patch from last week? It turns out that it
had some nasty deadlocks due to a kind of mayonnaise policy[1] regarding
the state lock. The state lock was being used (1) to synchronize access
to the state variables on elements; (2) to serialize calls to
gst_element_get_state; and (3) to serialize calls to
gst_element_set_state. With such a broad lock, adding recursion only
made the deadlocks trickier to find and understand.
</p>

<p>
The ultimate solution to this problem was to redefine the role of the
state lock. Now it is private to GstElement, and is only used to
serialize calls to gst_element_set_state. Accessing the state variables
themselves is done with the normal object lock. Bins are notified of
asynchronous state changes via a new STATE_DIRTY message, which tells
bins that a state recalculation is needed. It's still not entirely
elegant internally, but application writers should now have a library
that Just Works(tm).
</p>

<p>
In light of these changes, in addition to the 600 unread dinosaur
comics, the API freeze was postponed until Wednesday evening. It will be
in effect until 14 November. The releases should hopefully come out
today; as it turns out it takes time to distcheck 7 modules on a puny
Thinkpad laptop.
</p>

<p>
Of course, given the extra opportunity to break API, various malevolent
hackers were busy doing just that. Position and duration queries were
split, as position changes frequently but duration does not. In addition
position queries are now handled by sink elements, which makes the query
results sample-accurate. Duration changes are now broadcast via messages
as well. There was some further win32 porting done, autoconf flogged
Thomas a bit more, some plugin version-checking helper functions found
their way in, and dates in GstTag objects are now of type GST_TYPE_DATE.
</p>

<p>
[1] More is better!
</p>


<h3>
API Freeze Status
</h3>

<p>
Totally frozen dude! This is just like being in a stable series. No
changes in properties, no changes in API, no changes in ABI, &amp;c. At this
point, if there are changes that need to made, they should be filed in
bugzilla as blocking bug #319388 so they can be reviewed and maybe
applied on 14 November.
</p>


<h3>
Plug It In, Plug It In
</h3>

<p>
In addition to the churn this week related to the position/duration
query changes, and the date tag type change, the plugins saw a lot of
hacking this week. Here's a brief run-down:
</p>

<ul>
<li>
  base: decodebin and playbin now change state asynchronously (only
        going to PAUSED when all streams are decoded), buffer-frames
        removed from float audio caps (see [2]), typefinding updates,
        bugfixes in oggmux, theoraenc, ffmpegcolorspace, and some build
        system flaggelation by Thomas
</li>

<li>
  good: lots of elements ported -- matroska demuxer and muxer, pngdec,
        alphacolor, videomixer, flxdec; bugfixes in wavparse, videobox;
        level uses ELEMENT messages (instead of APPLICATION)
</li>

<li>
   bad: build fixes, speed updates from 0.8, faac ported better
</li>

<li>
  ugly: a52dec ported, siddec fixes
</li>
</ul>

<p>
[2] http://article.gmane.org/gmane.comp.video.gstreamer.devel/13647
</p>


<h3>
Everyone Likes Numbers
</h3>

<center>
<table width="50%">
<tr><td>Core files changed this week</td><td>247</td></tr>
<tr><td>Lines added this week</td><td>4522</td></tr>
<tr><td>Lines removed</td><td>6266</td></tr>
<tr><td>New change in core value according to sloccount(1)</td><td>-$58,893 [3]</td></tr>
<tr><td>Total number of GStreamer bugs as of today</td><td>213</td></tr>
<tr><td>Number opened in the last week</td><td>+19</td></tr>
<tr><td>Number closed in the last week</td><td>-11</td></tr>
<tr><td>Net change</td><td>+8</td></tr>
<tr><td>Rank among most buggy projects hosted in gnome bugzilla</td><td>8</td></tr>
</table>
</center>

<p>
[3] Thomas stole $69,000 of testsuites for 0.8-only features and has
laundered it to Belgium. If anyone seek him, ask him to bankroll your
bar tab -- the guy is loaded!
</p>


<h3>
Current Releases
</h3>

<p>
0.9.4 should come out later today, but as I write this these are still
the latest releases:
</p>

<h4>Latest development versions</h4>
<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-base</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-good</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-bad</td><td>0.9.3</td></tr>
<tr><td>gst-plugins-ugly</td><td>0.9.3</td></tr>
<tr><td>gst-ffmpeg</td><td>0.9.3</td></tr>
<tr><td>gst-python</td><td>0.9.3</td></tr>
</table>
</center>

<h4>Latest stable versions</h4>
<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.8.11</td></tr>
<tr><td>gst-plugins</td><td>0.8.11</td></tr>
<tr><td>gst-ffmpeg</td><td>0.8.6</td></tr>
<tr><td>gst-python</td><td>0.8.2</td></tr>
</table>
</center>


<h3>
Featured Application: Totem
</h3>

<p>
Christian Schaller has brought this breathtaking report back from his
Norvegian holidays:
</p>

<blockquote>
<p>
    Every system needs a good video player and in the GStreamer world
    the best one out there is Totem. Totem is the default media player
    in GNOME and has seen a lot of development put into making it very
    mature and well featured, like support for Infrared remotes, video
    thumbnails for Nautilus, support for various playlist formats and
    much work put into optimizing usability. And maybe best of all you
    can already use it with GStreamer 0.9 by using the patch from GNOME
    bugzilla bug 313086. More information on the Totem homepage:
</p>
<p>
    http://www.gnome.org/projects/totem/
</p>
</blockquote>


<p>
Well people, by my count I've got about 300 dinosaur comics left to read
and only another 2 hours of work. So enough of this playing around, it's
time to get serious. Have a quite fine weekend.
</p>
    </content>
  </item>
  <item>
    <title>GStreamer status, 31 October 2005</title>
    <date>2005-10-31 16:26</date>
    <content>
<p>
доброе утро gstreamer хакеры
</p>

<p>
Spooky Monday greetings! You weren't about to start working, were you?
Much better to put off beginning your day with a pot of coffee and a
GStreamer summary. That's what I think anyway.
</p>


<h3>
Life Under The Ice
</h3>

<p>
Binary and source stability notwithstanding, quite a few mischievous
minions have found ways to introduce changes into GStreamer CVS. 
</p>

<p>
Support was added in basesink for some of the more esoteric seeking
flags. filesink is more polite to the streams i/o layer now, and the
queue saw some crasher/deadlock fixes. Bins got some support code for
managing segment-start and segment-stop messages from their children,
and now cache durations queried from their children. Property
notifications are no longer serialized in GLib 2.8, and there is a new
lock in basetransform [0].
</p>

<p>
However the largest activity this last week centered around improving
our API documentation. This culminated in our first-ever documentation
day on Friday. It got off to a bit of a slow start, but was fruitful in
the end. Unfortunately we probably still have about 120 hours of
documentation work left to do, and we need your help. Read [1] to find
out how you can get involved!
</p>

<p>
[0] http://wingolog.org/pub/new-lock.jpg<br />
[1] http://article.gmane.org/gmane.comp.video.gstreamer.devel/14044
</p>


<h3>
Roadmap
</h3>

<p>
Owing to the delay in freezing the API, as well as the delay in getting
0.9.4 out the door, we pushed back the next two milestones by a week.
Thus the 0.9.5 and 0.9.6 releases will happen on 7 November and 21
November, with the hard freeze on 21 November [2].
</p>

<p>
[2] http://article.gmane.org/gmane.comp.video.gstreamer.devel/14038
</p>


<h3>
Plugged In
</h3>

<p>
The standard capabilities for video data no longer have arbitrary
bounds. Framerate now ranges from 0 to MAXDOUBLE, and dimensions are now
[1, MAXINT]. Although it is in the plans, it does not look like
framerate will become a rational for 0.10.
</p>

<ul>
<li>
  base: baseaudiosink now accepts audio buffers without timestamps,
        vorbisdec fixes, rtp base class work, audioconvert renegotiating
        fix, adder timestamps, oggdemux convert fix
</li>

<li>
  good: pngdec videobox bugfixen and optimization, flacenc fixes from
        Tim, osssrc mono/width fixes, h263 and asterisk payloaders,
        dvdemux autoplugging fix, payloader/depayloaders for gsm, mulaw,
        alaw, videomixer refcount fixen, matroska v2 support, speexenc
        fix
</li>

<li>
   bad: ttaparse fix, gsmenc/gsmdec rewritten, qtdemux update,
        sdlvideosink
</li>

<li>
  ugly: mpeg2dec fixes
</li>
</ul>


<h3>
Digits
</h3>

<center>
<table width="50%">
<tr><td>Core files changed this week</td><td>71</td></tr>
<tr><td>Lines added this week</td><td>4157</td></tr>
<tr><td>Lines removed</td><td>3362</td></tr>
<tr><td>New change in core value according to sloccount(1)</td><td>+$9,723</td></tr>
<tr><td>Total number of GStreamer bugs as of today</td><td>230</td></tr>
<tr><td>Number opened in the last week</td><td>+33</td></tr>
<tr><td>Number closed in the last week</td><td>-16</td></tr>
<tr><td>Net change</td><td>+17</td></tr>
<tr><td>Rank among most buggy projects hosted in gnome bugzilla</td><td>8</td></tr>
</table>
</center>


<h3>
Current Releases
</h3>

<h4>Latest development versions</h4>
<p>
0.9.4 of all of the development modules was released on 24 October. The
API and ABI of those modules will not change until 21 November. 
</p>

<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.9.4</td></tr>
<tr><td>gst-plugins-base</td><td>0.9.4</td></tr>
<tr><td>gst-plugins-good</td><td>0.9.4</td></tr>
<tr><td>gst-plugins-bad</td><td>0.9.4</td></tr>
<tr><td>gst-plugins-ugly</td><td>0.9.4</td></tr>
<tr><td>gst-ffmpeg</td><td>0.9.4</td></tr>
<tr><td>gst-python</td><td>0.9.4</td></tr>
</table>
</center>

<h4>Latest stable versions</h4>

<p>
Ronald has rolled a stable gst-ffmpeg prerelease which he would like
people to test, version 0.8.6.3. Check #gstreamer on irc
for more information.
</p>

<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.8.11</td></tr>
<tr><td>gst-plugins</td><td>0.8.11</td></tr>
<tr><td>gst-ffmpeg</td><td>0.8.6</td></tr>
<tr><td>gst-python</td><td>0.8.2</td></tr>
</table>
</center>


<h3>
Featured Application: Buzztard
</h3>

<p>
Tall. Blond. Norwegian. Add these words together and decode them for the
name of the secret author bringing us this week's featured application!
</p>

<p>
    Buzztard is a music production software modelled after the program
    Buzz which was released for Windows. The main person behind Buzztard
    is Stefan Kost who has also been one of the primary drivers behind
    making GStreamer 0.9/0.10 well suited for music creation software
    like this. Buzztard aims to reach parity and then surpass the
    original, a task made a little easier by the fact that the
    original's development stopped due to lost source code. You can find
    out more about Buzztard here:
</p>

<p>
    http://www.buzztard.org/
</p>


<p>
So it's four oclock already, I imagine I should start working. You too.
Have a fine week!
</p>
    </content>
  </item>
  <item>
    <title>GStreamer status, 11 November 2005</title>
    <date>2005-11-10 17:50</date>
    <content>
<p>
Bon dia hackers,
</p>

<p>
Happy Friday across the land. Don't start with the keyboard yet, just
chill and let the hangover subside by doing some, er, "professional
development". Time to check out what's been going on in the land of
GStreamer!
</p>

<h3>
Acontecimientos Nucleares
</h3>

<p>
Odds and ends, odds and ends. GstBaseSrc now supports a mode where it
synchronizes its output to a clock, which is useful for elements which
simulate live sources. Wim fixed a bug when linking ghost pads, filesrc
got some cleanups, and sink elements now emit the correct state change
messages. gst_bus_poll can now co-exist happily with the "message"
signal, and the GstBaseTransform class that underlies most filters was
fixed to correctly support passthrough mode.
</p>

<p>
GstBaseSrc also saw a number of segment seeking fixes, which allow for
looped and reverse playback. A deadlock when flushing blocked pads was
fixed, Thomas made sure that local plugins can override system plugins
in the registry, and there were also a series of collectpads fixes and
updates for win32.
</p>

<p>
Finally, lots of documentation was reviewed and expanded. Mmm.
Documentation.
</p>


<h3>
A Look Ahead
</h3>

<p>
As we are in a freeze right now, we can't commit API-breaking patches to
CVS directly. Breaks proposed before 0.10.0 is out are being queued up
in bugzilla as blocking bug #319388 [0]. A brief look at these patches
shows changes in the following categories:
</p>

<ul>
<li>
 removals of deprecated API that doesn't work (319389, 320097, 321235)
</li><li>
 name changes for consistency (319392, 319395, 320113, 320395, 320766)
</li><li>
 cleanups (320324, 321061, 319940, 320423)
</li>
</ul>

<p>
Surprisingly there is only one addition bug, and we're not sure if it's
needed -- to spec out filler events (319178). The one left (320299) is
to have the core take the stream lock for event functions, only if
necessary. Plugin code should then be updated not to take the stream
lock within event functions, although it will not cause an error because
the stream lock is recursive.
</p>

<p>
Of these patches, the name changes are the only thing application/plugin
writers should be concerned about. However, there is one other source of
proposed changes, which is Wim's to-do list [1], which is looking quite
formidable. We'll know what hit us on the 21st...
</p>

<p>
[0] http://bugzilla.gnome.org/showdependencytree.cgi?id=319388<br />
[1] http://cvs.freedesktop.org/*checkout*/gstreamer/gstreamer/docs/design/part-TODO.txt
</p>


<h3>
Enchufado
</h3>

<p>
I was looking at changelogs and I noticed that this is the first summary
period in which no commit was made to 0.8 core or plugins. Sweet!
</p>

<p>
The highlight of this week in plugins was Julien Moutte's directfb video
sink port. Not only does it handle all of the tricky things video sinks
should implement (reverse negotiation, hardware scaling, DMA buffer
allocation...), but it was committed with documentation and example
code. As it should be, it was first put into -bad while he worked on it,
and then he filed a bug [2] requesting that it be accepted into -good.
Truly a model for how to port plugins. Excellent work, Julien!
</p>

<p>
[2] http://bugzilla.gnome.org/show_bug.cgi?id=321240
</p>

<ul>
<li>
  base: ffmpegcolorspace passthrough mode fix, better errors in
        alsasink, better seeking in ogg, playbin fixes, test sources
        let basesrc do the clock synchronization for them, v4lsrc fix,
        mux ogg correctly (mostly a forward-port from 0.8), base rtp
        depayloader fixes, baseaudiosink optimizations, new example for
        changing playback rate (not completely implemented in audio
        sinks yet)
</li>

<li>
  good: matroskamux fixes, autoaudiosink and autovideosink more robust,
        wavenc decruftifying, cairotextoverlay ported, osssink debugging
        fixes, flxdec optimizations
</li>

<li>
   bad: qtdemux supports custom genre tags, documentation fixes, tremor
        integer vorbis decoder ported, directfb video sink ported (with
        examples and documentation!)
</li>

<li>
  ugly: nothing!
</li>
</ul>

<h3>
Digits
</h3>

<center>
<table width="50%">
<tr><td>Core files changed this week</td><td>77</td></tr>
<tr><td>Lines added this week</td><td>3179</td></tr>
<tr><td>Lines removed</td><td>1780</td></tr>
<tr><td>New change in core value according to sloccount(1)</td><td>+$18,017</td></tr>
<tr><td>Total number of GStreamer bugs as of today</td><td>245</td></tr>
<tr><td>Number opened in the last week</td><td>+21</td></tr>
<tr><td>Number closed in the last week</td><td>-17</td></tr>
<tr><td>Net change</td><td>+4</td></tr>
<tr><td>Rank among most buggy projects hosted in gnome bugzilla</td><td>8</td></tr>
</table>
</center>


<h3>
Current Releases
</h3>

<h4>Latest development versions</h4>
<p>
0.9.5 of all of the development modules is being released as this
newsletter goes to press. The API and ABI of these modules will not
change until 21 November.
</p>

<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.9.5</td></tr>
<tr><td>gst-plugins-base</td><td>0.9.5</td></tr>
<tr><td>gst-plugins-good</td><td>0.9.5</td></tr>
<tr><td>gst-plugins-bad</td><td>0.9.5</td></tr>
<tr><td>gst-plugins-ugly</td><td>0.9.5</td></tr>
<tr><td>gst-ffmpeg</td><td>0.9.5</td></tr>
<tr><td>gst-python</td><td>0.9.5</td></tr>
</table>
</center>

<h4>Upcoming releases</h4>

<center>
<table width="50%">
<tr><td>21 November</td><td>0.9.6</td></tr>
<tr><td>28 November</td><td>0.9.7 (the 0.10.0 prerelease)</td></tr>
<tr><td>05 December</td><td>0.10.0</td></tr>
</table>
</center>

<h4>Latest stable versions</h4>

<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.8.11</td></tr>
<tr><td>gst-plugins</td><td>0.8.11</td></tr>
<tr><td>gst-ffmpeg</td><td>0.8.7</td></tr>
<tr><td>gst-python</td><td>0.8.2</td></tr>
</table>
</center>

<h3>
Featured Application: Flumotion
</h3>

<p>
Christian Ferrari Schaller is our reporter on location, bringing us
these words of wisdom.
</p>

<blockquote>
<p>
    Flumotion is just out today with a new release so I thought I would
    make it this week's featured application. Flumotion is a distributed
    streaming server using GStreamer. It supports the free Ogg Vorbis,
    Ogg Theora and Ogg Speex protocls and also jpeg video streaming.
    Today's new version supports both GStreamer 0.8 and the new sparking
    GStreamer 0.9 version. You find more information about Flumotion at:
</p>

<p>
    http://www.flumotion.net/
</p>
</blockquote>

<p>
Christian also notes that the new Flumotion release might not be out
when you read this, but it will be out before the end of the day. Word
is bond.
</p>


<p>
So kids, a little over three weeks until the big 0.10.0. Keep hacking,
keep porting, and stay away from drugs, ok? Thanks. We'll totally make
it there together. Peace.
</p>
    </content>
  </item>
  <item>
    <title>GStreamer status, 24 November 2005</title>
    <date>2005-11-24 15:27</date>
    <content>
<p>
Fala hackers,
</p>

<p>
E ai? GStreamer rages on, stealing our days and nights. One release
down, one to go, and then the oh ten oh. Catch the audiotestsrc sound
while we break the week down yo.
</p>


<h3>
Kicking Ass And Taking Names
</h3>

<p>
The amount of hacking done in the last 10 days on GStreamer has been
astounding. If concentrated and properly channeled, it could power the
island nation of Australia for 3 full weeks. Intense is the word.
</p>


<h3>
Interesting Additions
</h3>

<p>
Jan Schmidt is not only a hacker's hacker, but he works hard too. Many
people have thought that framerate in GStreamer should be expressed as a
fraction, but only Jan actually took the time to sit down, add the
needed core functionality, *and* change all of the plugins (with some
help from Mike Smith).
</p>

<p>
API-wise, the core now supports fraction ranges (<tt>'framerate=(fraction)[2/3,
17/4]'</tt>), including range intersections and unions, as well as some new
convenience functions for dealing with fractions in caps and structures.
</p>

<p>
Another longstanding wishlist item was finally completed last week as we
implemented a framework for synchronizing multiple clocks. Whenever you
capture from or output to multiple devices, there are different clocks
at work -- one provided by each hardware device, and possibly a
different one for the pipeline as a whole.
</p>

<p>
In this situation, to ensure that buffer timestamps are relative to the
same clock, one clock (the <i>master</i>) needs to provide the definitive
time, and the other ones (the <i>slaves</i>) try to match their time to the
master. This enables the possibility of synchronized capture from
multiple sound cards, among other things.
</p>

<p>
Interestingly enough the same framework can be used to syncronize clocks
over the network. A GstClock running on one machine can now export its
time over the network [0], allowing specialized GstNetClientClock [2]
instances on other machines to slave their clocks it. Most excellent.
These network clocking components are part of a new GStreamer core
package, found in the gst/net directory of GStreamer core, called
gstreamer-net. This package has its own library, its own headers, and
its own pkg-config information, so that you can link it in to your
application only if you need it.
</p>

<p>
[0] &site;/data/doc/gstreamer/head/gstreamer/html/GstNetTimeProvider.html
<br />
[1] &site;/data/doc/gstreamer/head/gstreamer/html/GstNetClientClock.html
</p>


<h3>
API Freeze Breakage
</h3>

<p>
As everyone is I'm sure aware, our schedule [2] specified that API
changes filed in bugzilla were to be applied for our latest release,
0.9.6. Work started on merging in these changes on Saturday, but did not
finish until Wednesday, almost 900 lines of ChangeLog later. Most of the
changes can be seen on the bugs that blocked #319388 [3].
</p>

<p>
Application authors will note that framerates for video are now
fractions; thus any caps filters should be updated. Note that integers
also parse as fractions, so <tt>'framerate=(fraction)25'</tt> should work.
</p>

<p>
Also be aware that the tag setter interfaces changed so that the verb
stem of the function name is more descriptive, e.g. gst_tag_setter_merge
changed to gst_tag_setter_merge_tags. There is a script to automate
these updates, run as:
</p>

<pre>
$ find myprojdir -name '*.[ch]' -exec gstreamer/scripts/update-funcnames {}\;
</pre>

<p>
Plugin developers will find the update-macros script in the same
directory useful for automatically renaming some macros that changed.
gst_caps_structure_fixate_* was renamed to gst_structure_fixate_*, and
value arrays should now only be accessed via the gst_value_array API and
not the gst_value_list API.
</p>

<p>
Plugin authors should also note that it is no longer necessary to take
the stream lock in event functions; any instances of GST_STREAM_LOCK or
GST_STREAM_UNLOCK should probably be removed unless they are part of a
source pad's seek implementation. Ask on the channel if you need more
help.
</p>

<p>
Finally, the '0.9' major-minor number will change to '0.10' starting
with the next GStreamer release. Anyone who makes applications or
plugins with GStreamer should look at the migration mail [4].
</p>

<p>
[2] http://article.gmane.org/gmane.comp.video.gstreamer.devel/14038
<br />
[3] http://bugzilla.gnome.org/showdependencytree.cgi?id=319388
<br />
[4] http://article.gmane.org/gmane.comp.video.gstreamer.devel/14251
</p>


<h3>
Tick Tick Tick
</h3>

<p>
There are 11 days left until the stable release of GStreamer 0.10.0.
Woot! Note that we're pushing the 0.9.7 release forward by one day.
</p>

<center>
<table width="50%">
<tr><td>29 November</td><td>0.9.7 (the 0.10.0 prerelease)</td></tr>
<tr><td>05 December</td><td>0.10.0</td></tr>
</table>
</center>


<h3>
Plums In The Icebox
</h3>

<p>
Aside from the stable-cleaning involved in updating the plugins for the
API renames and fractional framerates, we did manage to hack in some
more substantial changes.
</p>

<p>
Authors of video players will be interested in these notes on the XOverlay
interface by Julien Moutte:
</p>

<blockquote>
<p>
    XOverlay now only focuses on providing a way to set your own window
    on or get the generated window from the video sink element. It also
    provides a way to force the video sink to expose the latest frame to
    handle expose events while being PAUSED. The desired-size features
    are gone because you are supposed to get that in another way.
</p>
</blockquote>

<p>
Thanks, Julien.
</p>

<ul>
<li>
  base: audioclock supports master/slave operation, sinesrc removed in
        favor of audiotestsrc, xoverlay interface changes, xvimagesink
        handles aspect ratio/navigation/expose in PAUSED, vorbisenc
        bugfixes, ximagesink doesn't flicker any more and can keep
        aspect ratio, updates for the new segment helper API, lots of
        pad template leaks fixed, baseaudiosink bugfixes,
        oggmux/vorbisenc leaks plugged
</li>

<li>
  good: Julien "video hero" Moutte ported videofilter ported to use
        basetransform and updated the effectv, videoflip, and
        navigationtest plugins, goom got a bugfix, cutter ported,
        dv1394src and udpsrc now properly handle URIs, wavenc fixes,
        speex rtp elements added, avidemux bugfixes.
</li>

<li>
   bad: initial port of musepackdec, tremor vorbis decoder can operate
        in streaming mode
</li>

<li>
  ugly: Better seeking in mad, mpeg2dec modernization, mpegstream plugin
        ported by Joser Zlomek.
</li>
</ul>


<h3>
Digits
</h3>

<center>
<table width="50%">
<tr><td>Core files changed this week</td><td>174</td></tr>
<tr><td>Lines added this week</td><td>8236</td></tr>
<tr><td>Lines removed</td><td>3214</td></tr>
<tr><td>New change in core value according to sloccount(1)</td><td>+$148,554.69 AUD</td></tr>
<tr><td>Total number of GStreamer bugs as of today</td><td>206</td></tr>
<tr><td>Number opened in the last week</td><td>+32</td></tr>
<tr><td>Number closed in the last week</td><td>-68</td></tr>
<tr><td>Net change</td><td>-36</td></tr>
<tr><td>Rank among most buggy projects hosted in gnome bugzilla</td><td>10</td></tr>
</table>
</center>

<p>
Fully 4 of top 15 bug closers are hacking GStreamer -- wingo, __tim,
msmith, and bilboed. With 68 bugs closed this week [5], we are really
starting to take a bite out of Bugzilla. Let's keep it up!
</p>

<p>
[5] http://tinyurl.com/8v3rw
</p>


<h3>
Current Releases
</h3>

<h4>Latest development versions</h4>

<p>
0.9.6 of all of the development modules was released yesterday, the
24th. Barring emergencies, the API and ABI is now frozen.
</p>

<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.9.6</td></tr>
<tr><td>gst-plugins-base</td><td>0.9.6</td></tr>
<tr><td>gst-plugins-good</td><td>0.9.6</td></tr>
<tr><td>gst-plugins-bad</td><td>0.9.6</td></tr>
<tr><td>gst-plugins-ugly</td><td>0.9.6</td></tr>
<tr><td>gst-ffmpeg</td><td>0.9.6</td></tr>
<tr><td>gst-python</td><td>0.9.6</td></tr>
</table>
</center>

<h4>Latest stable versions</h4>

<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.8.11</td></tr>
<tr><td>gst-plugins</td><td>0.8.11</td></tr>
<tr><td>gst-ffmpeg</td><td>0.8.7</td></tr>
<tr><td>gst-python</td><td>0.8.2</td></tr>
</table>
</center>


<h3>
Featured Application: Muine
</h3>

<p>
Christian Vander Schaller comes down from the mountain, bringing us
these tablets of truth.
</p>

<blockquote>
<p>
    This week we spotlight the Muine Music player created by Jorn
    Baayen. Muine is a Music player written in C#. Its tries to take a
    different approach with its user interface than iTunes or WinAmp,
    unlike most other players out today. The organization is organized
    around albums and is kept small and efficient. Thanks to the work of
    Iain Holmes there is even a patch porting Muine to GStreamer
    0.9/0.10 available [6]. Check out Muine at:
</p>

<p>
    http://muine.gooeylinux.org/
</p>
</blockquote>

<p>
[6] http://mail.gnome.org/archives/muine-list/2005-November/msg00016.html
    Iain notes this patch is preliminary and might molest the pooch.
</p>


<p>
These days with 0.10 on the way it's time to stop hacking libraries and
start making applications people love to use. Take your old ideas down
from the shelf, dust them off with something new, and let's make 2006
the year of GStreamer sound and video.
</p>
    </content>
  </item>
  <item>
    <title>GStreamer status, 16 December 2005</title>
    <date>2005-12-16 17:45</date>
    <content>
<p>
Mwa pendukeni oohacker yo GStreamer,
</p>

<p>
I know it's been a long time since I rapped at ya, but we had some very
crucial details to take care of, such as releasing a stable GStreamer.
So amigos let's see what's been up over the past three weeks already.
</p>


<h3>
A to the P to the I
</h3>

<p>
We are most totally and definitely stable! December 5 saw the 0.10.0
release of all modules, from core on out to python and ffmpeg. Check out
the hyped-up release notes [0] if you haven't already.
</p>

<p>
As the last edition of your favorite GStreamer news product was released
two weeks before 0.10.0, there were still a number of lines of ChangeLog
that made it into the core before we went stable. And that number is
1360. 
</p>

<p>
There weren't all that many features added. The identity element got a
new property, "single-segment", that will cause it to re-stamp the
buffers passing through it, so that e.g. a looping segment can appear to
downstream elements as one continuous stream. This is especially useful
if you want to encode a stream whose source is a looping file. Wim got a
bit bored and implemented high-precision scaling of 64-bit integers.
GstBaseTransform got an event vmethod implemented, and Jan Schmidt added
seek support to fdsrc. Stefan added code to GstController so it could
control enums, and Edward Hervey made the gst-launch output slightly
less cryptic.
</p>

<p>
API-wise, functions in gstvalue.h were changed to use GLib-style types
only, e.g. gchar instead of char. Yes they are the same thing, but such
is our attention to consistency that we can't bear seeing non-GLib types
in the API. gst_pad_alloc_buffer was changed so it never sets caps, and
a new function was added: gst_pad_alloc_buffer_and_set_caps. I bet you
can guess what it does.
</p>

<p>
Do take some time today to mourn the removal of bash completion support
for gst-launch. gst-complete was a noble friend, but unmaintained, and
required its own XML cache to be kept up-to-date via running the
gst-compprep utility. A patch to port gst-complete to 0.10 would
certainly be accepted, if it can work without gst-compprep, for the same
reasons that we removed gst-register.
</p>

<p>
As a source package, GStreamer core itself saw a lot of loving from its
favorite consort, Thomas Vander Stichele. Directories moved around,
--disable-gst-debug and related options now work again, the queue
element is out of the core (finally), and the normal
dist/distcheck/visual studio fixes were applied. Aside from all that,
object padding was updated, leaks were plugged, and there were
documentation updates all around.
</p>

<p>
Also, welcome to our new translations: Bulgarian and Traditional
Chinese. Dobre doshli! Huan yin!
</p>

<p>
[0] &site;/releases/gstreamer010.html
</p>


<h3>
Post Oh Ten Oh
</h3>

<p>
After a short continuation of the CVS freeze, in case a new release
needed to be rolled out quickly, the core opened again for commits. One
of the first was an ABI test that makes sure our structures do not
change in size. gstparse handling of the { and } characters (which make
GstThread bins) was removed, as GstThread is no more, and Wim fixed the
"sync" fakesrc property. Obsolete configure.ac checks for makecontext
were removed, and Mike Smith fixed a leak in the typefind element. Tim
spent some time updating the manual for 0.10, and Stefan ported some of
the old examples to the current API.
</p>

<p>
BaseSrc finally got support for seeks, position, and queries in any
format -- before, it only provided hooks for byte positions. The net
time provider can be deactivated, in which state it will not reply to
time messages. The typefind element was bugfixed some more, and Julien
fixed threadsafety bugs in GstCollectPads.
</p>

<p>
Other than that there wasn't anything to speak of -- a relaxed week and
a half. This is how it should be, minor bugfixes as we concentrate on
making applications users will enjoy using.
</p>


<h3>
Seven Noses, Seven Cheeses
</h3>

<p>
Leading up to the 0.10.0 releases, there was a lot of last-minute
polish being applied to the plugins. Here's the changes between 23
November and 5 December:
</p>

<ul>
<li>
 base: multifdsink threadsafety fixes, oggdemux made more robust,
  audiorate respects flow returns, ximagesink, xvimagesink, and the
  xoverlay interface polished and documented by video hero Julien,
  decodebin got some queues, audio clock supports operating in
  master/slave mode, playbin polishes and support for multiple audio
  streams, rtp plugin names made more consistent, xoverlay stress test
  added, pango plugin ported nicely and moved from -good, audioresample
  fixed (finally!)
</li>

<li>
 good: navigation, stride, and passthrough fixes in videoflip, quarktv
  crasher fix, documentation added for autovideo, audioaudio, and
  flacdec added, dvdec fixes for pixel aspect-ratio, matroska muxer
  updates, video filters use a base class from plugins-base, event
  support added to the navseek and progressreport debug plugins,
  multipart muxer and demuxer ported, dvdemux seeking fixes, rtp plugin
  renaming.
</li>

<li>
 ugly: mpegstream work, mad gracefully handles unlinked source pads,
  a52dec supports streams with special DVD headers, real media demuxer
  EOS fix, id3tag removed.
</li>

<li>
 bad: wavpack ported (no correction file support yet though), qtdemux
  state change fixes, faad robustness fix, libmms plugin ported to 0.10
  by Edgard
</li>
</ul>

<p>
After the initial rest that everyone took after 0.10.0, the bug reports
started to pour in. Since then there have been a number of fixes that
will come out in our next release:
</p>

<ul>
<li>
 base: ogm support added to the ogg plugin, playbin fixes for glib 2.6,
  gst-launch-ext removed (it wasn't working and isn't useful), bugfixes
  in the subtitle parser, cdparanoia ported to 0.10 (made possible by
  basesrc changes), videorate bugfixes, plugged massive leak in
  audioresample, audiotestsrc and videotestsrc seeking support,
  GstPropertyProbe support added back to the alsa elements.
</li>

<li>
 good: Memleak and crasher fixes in wavparse and avidemux, docs added
  to multipart muxer/demuxer, flacdec bugfixes, OSS portability fixes,
  flxdec endianness fix, fix totally ironic crash in the electric fence
  debugging element, auparse beautification and crasher fix,
  mastroskademux timestamping fix, videomixer capsnego fixed, RTP
  payloader/depayloader caps fixes, speex rtp elements set clock rate
  properly, rtsp portability fix.
</li>

<li>
 ugly: more mpegstream work, mad query/position fixes, plug leak in
  rmdemux
</li>

<li>
 bad: qtdemux EOS and 64-bit fixes, swfdec ported to 0.9 by Edgard,
  mmsh support in libmms, dtsdec, xviddec and xvidenc ported to 0.10
  also by Edgard.
</li>
</ul>

<h3>
Introducing the Media Test Suite
</h3>

<p>
Edward Hervey recently gave birth to a beautiful HTML baby. Tell us
about your baby, Edward!
</p>

<blockquote>
<p>
    Fixing bugs in GStreamer plugins has always been a tedious task.
    Sometimes fixing playback for one file breaks it for other files.
    Testing files playback/seeking by *hand* is repetitive and no
    developer likes it. And finally, nobody (apart maybe for the main
    developer of a plugin) ever knows at one given point how well some
    media formats are supported, or how well the API is implemented in
    each plugins.
</p>

<p>
    In order to solve all these issues, a new testsuite is born :
    gst-media-test. It currently contains two tests : typefindtest (Can
    we read this file and all the media streams contained within ?) and
    playtest (does playback/seeking work properly?). The tests check
    that complete and correct API-compliance is respected for every
    file. HTML reports of the tests are then generated, with complete
    debug logs, exact reasons why the test failed, backtraces if the
    test crashed, plugins used, etc...
</p>

<p>
    We currently run the testsuite about everyday on over 20Gbytes of
    test files with the latest cvs version of GStreamer and the results
    are available online [1]. Pick your bug and fix it :)
</p>

<p>
    All buggy media files that land in the GStreamer bugzilla should
    also be added to the list of files tested here, so users can also
    see if the current cvs version of GStreamer solved their issue.
</p>
<p>
    [1] http://core.fluendo.com/gst-media-test/
</p>
</blockquote>

<p>
We're all impressed, Edward. Nice work!
</p>


<h3>
Um... So Like What Are We Doing And Stuff
</h3>

<p>
It seems we've lost our direction, inasmuch as we spent the last 10
months looking to the day of 0.10.0 and now it has passed. What now?
</p>

<p>
So your editor sent a clandestine reporter to the GStreamer IRC channel,
asking people that same question. Here's what they said:
</p>

<p>
OK so they didn't say anything, so given the pressure of the story's
deadline our clandestine reporter just left the editor with a link to a
mailing list discussion [2] started by Thomas.
</p>

<p>
[2] http://news.gmane.org/find-root.php?group=gmane.comp.video.gstreamer.devel&amp;article=14432
</p>


<h3>
114 Gs Down
</h3>

<p>
Thomas removed a bunch of outdated examples, which combined with his
previous thefts is probably enough to buy a large plasma TV. Have him
buy your drinks at the bar!
</p>

<center>
<table width="50%">
<tr><td>Core files changed this week</td><td>266</td></tr>
<tr><td>Lines added this week</td><td>9303</td></tr>
<tr><td>Lines removed</td><td>7860</td></tr>
<tr><td>New change in core value according to sloccount(1)</td><td>-$114,303</td></tr>
<tr><td>Total number of GStreamer bugs as of today</td><td>228</td></tr>
<tr><td>Number opened in the last week</td><td>+12</td></tr>
<tr><td>Number closed in the last week</td><td>-2</td></tr>
<tr><td>Net change</td><td>+10</td></tr>
<tr><td>Rank among most buggy projects hosted in gnome bugzilla</td><td>Tied for 8</td></tr>
</table>
</center>

<p>
Our bug count is shooting back up. Your editor is waiting for the new
bugzilla to be installed before going back to looking at bugs. Of course
that means that after Monday, there will be no excuse.
</p>


<h3>
Current Releases
</h3>

<h4>Latest stable versions</h4>

<p>
No more 0.8, no more 0.9, 0.10 is the new stable series!
</p>

<center>
<table width="50%">
<tr><td>gstreamer</td><td>0.10.0</td></tr>
<tr><td>gst-plugins-base</td><td>0.10.0</td></tr>
<tr><td>gst-plugins-good</td><td>0.10.0</td></tr>
<tr><td>gst-plugins-bad</td><td>0.10.0</td></tr>
<tr><td>gst-plugins-ugly</td><td>0.10.0</td></tr>
<tr><td>gst-ffmpeg</td><td>0.10.0</td></tr>
<tr><td>gst-python</td><td>0.10.0</td></tr>
</table>
</center>


<h3>
Featured Application: bmpX
</h3>

<p>
Christian Schaller brings us this week's featured application.
</p>

<blockquote>
<p>
    This weeks featured application is bmpX, a music player with a Winamp
    and XMMS compatible user interface. The bmp project started its life
    as a GTK+ 2 port of XMMS, but is today a fully separate project.
    bmpX CVS has working GStreamer 0.10 support and will soon bring
    bliss to the world among those who never fell in love with
    iTunes-style user interfaces. A big thanks to Milosz Derezynski and
    the rest of the bmpX team for this cool project.
</p>

<p>
    You find more information about this project at:<br/>
    http://beep-media-player.org/index.php/BMPx_Homepage
</p>
</blockquote>

<p>
Well that brings this most lengthy newsletter to a close. Everyone
should pull out those dusty personal projects, update them for the new
API, and give the world a nice present for the new year. Word is bond.
Peace.
</p>
    </content>
  </item>
</status>