| 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 |
| low hanging 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 |
| |
| |
| |
| |
| |
| |
| |
| |