--- /dev/null
+0.11 status 1 jun 2011
+----------------------
+
+Hello again GStreamer hackers,
+
+
+Here's another status update from the 0.11 branch. This one is packed
+with new stuff because it really took too long between the last
+update, but well..
+
+
+Misc Core Changes
+-----------------
+
+The first set of big core change was done by über hacker Sebastian Dröge.
+He removed our special GST_BOILERPLATE macro. Because of some API strangeness
+we needed to do actions in the base_init method, which the GST_BOILERPLATE
+macro set up for us. The base_init concept is unfortunately not supported
+by almost all language bindings so we wanted to clean this up and use the
+regular G_DEFINE_TYPE macros. By inheriting metadata and pad templates
+from the parent, the GST_BOILERPLATE macro could be removed.
+
+
+Removal of gst_pad_alloc_buffer
+-------------------------------
+
+The next big change was the removal of gst_pad_alloc_buffer along with
+all the pad_alloc functions. The pad_alloc function were used to both
+implement allocation of buffers and notify upstream elements of new media
+formats. The functionality is replace by 3 new things: GstBufferPool (as
+noted in the previous status update), a new ALLOCATION query and a new
+RECONFIGURE event.
+
+The ALLOCATION query is used to query the downstream elements about the
+buffer properties they would like. These properties include the size,
+prefix and alignment of the memory. The downstream element can also propose
+a GstBufferPool. It is then the upstream element that decides how it
+will allocate buffers. This allows us, for example, to make the video
+decoders specify their required memory alignment to the videosink.
+
+Since new format suggestions are no longer piggybacked upstream with the
+allocation, something new was needed to notify upstream elements of a
+format change. It started with bringing in the new RENEGOTIATE event
+that Thiago Santos had been experimenting with in the 0.10 branch. The
+new event basically lets upstream elements know that new formats are
+possible somewhere downstream and it would make them renegotiate a new
+format before pushing a new buffer.
+
+New format changes can also happen when new elements are linked, so
+gst_pad_link() will also send this RENEGOTIATE event upstream. As it turns
+out, adding new elements could also signal the availability of a new
+bufferpool or different ALLOCATION properties. The RENEGOTIATE event was
+thus renamed to the more generic RECONFIGURE event.
+
+The most impressive result of these changes is that most of the
+complicated code in GstBaseTransform could simply be removed.
+
+
+Sticky Events
+-------------
+
+The idea for the sticky events comes from the observation that a lot of the
+serialized downstream events (SEGMENT, EOS, TAGS, ..) are really context
+for the buffers that follow. The design called for making these events
+sticky on the pads, meaning that they become a property of the pads
+they travel over.
+
+The result is that the current timing information (SEGMENT event) or the
+current stream medatadata (TAG event) that is handled by the pad are
+directly accessible by looking at the last event that traveled on the pad.
+
+By making the events stick on the pads, we can propagate them downstream
+automatically when new pads are linked. This should solve one of the
+biggest 0.10 problems when dealing with dynamic pipelines, the loss of
+events (mostly NEWSEGMENT events).
+
+It was then only natural to also make the CAPS event a sticky downstream
+serialized event. CAPS are indeed also context for the buffers that follow.
+The caps property was also removed from GstBuffer, making caps negotiation
+separate from the buffer dataflow again.
+
+
+GstSegment changes
+------------------
+
+For the sticky events to work with SEGMENT events, we needed to change
+the SEGMENT event so that it became selfcontained. The complicated segment
+accumulation logic of 0.10 was simply removed and replaced with pad offsets.
+
+It is now possible to tweak the timing of the data comming from a pad by
+using the pad offset property.
+
+
+GstCaps optimizations
+---------------------
+
+It doesn't look like we'll be able to implement GstCaps iterators to 0.11 so
+Sebastian was looking for other ways to improve caps performance. One of the
+lowhanging fruits was to pass the complete GstCaps structure to the
+GstBaseTransform transform_caps method. This allows for better and smarter
+implementations of the function at the cost of marginally more complex code.
+
+Sebastian also added a filter caps parameter to the gst_pad_get_caps()
+function. This allows the caller to pass preferences and possible caps to
+the function. The result is that the pad can make much better negotiation
+decisions.
+
+Sebastian also optimized gst_caps_is_subset()in the 0.10 branch and ported
+the results to 0.11 as well.
+
+with the still planned caps simplifications later, these changes should
+substantially improve caps negotiation speed.
+
+
+Pad probes
+----------
+
+Quite a few iterations were needed to reimplement the pad blocking and pad
+probes. The new infrastructure allows you to add callbacks for the various
+stages in the data transfer on a pad.
+
+It's now possible to be notified when no data is going over a pad with the
+IDLE probe. This should also fix one of the big problems with implementing
+dynamic pipelines and the old pad blocking.
+
+Not all features that we want to add to the new probes are implemented yet
+but they can be added later without much trouble.
+
+
+Other gems
+----------
+
+A new SCHEDULING query was added to get more information about the upstream
+elements scheduling properties.
+
+Tim-Philipp Müller finally removed our dependency on libxml2. Back in the
+day, we used XML for serialization of objects and the registry. Object
+serialization had long been deprecated and the XML registry was replaced
+with a much faster binary registry.
+
+Tim also removed the unversioned gst-launch, gst-inspect and gst-typefind
+scripts. They were always confusing and annoying for packagers and users,
+it is just easier
+
+Edward Hervey spent some time keeping the unit tests working and making
+sure the API docs are up to data.
+
+GstIterator was made more binding friendly By Johan Dahlin and Sebastian.
+
+
+And what about the plugins..
+----------------------------
+
+As usual, all -base plugins are kept in sync with the core API updates and
+the new features. They are always a good place to see how the new API can
+be used and how to port things.
+
+
+What's next
+-----------
+
+Almost all of the features laid out in the GStreamer conference last year
+are now implemented. We also have quite a few new cool features that
+slipped in. Things are shaping up indeed.
+
+The last big missing piece is the redesign of the caps fields for raw audio
+and video. We plan to finish that in the next weeks.
+
+There are also a few smaller things we would like to do: use GstQuery
+for the various caps functions, do GstFlowReturn for the query/event
+functions, ...
+
+Meanwhile we start the stabilization phase and we will do a first prerelease
+of 0.11 this week to bring things to a wider audience. Now is the time to
+catch up and start porting your plugins to 0.11.
+
+There is still a lot of work to be done to port plugins to 0.11 before we
+can release 1.0. I ask everyone again (and especially maintainers) to help
+us porting plugins, it's really a lot of work!
+
+
+Have a nice hacking week,
+
+Wim
+
+
+
+
+
+
+
+
projects / platform / upstream / gstreamer.git / commitdiff