From 44d45e0b63a29f1cc6cf93753ce3cde29894ae50 Mon Sep 17 00:00:00 2001 From: Wim Taymans Date: Tue, 14 Jun 2011 15:18:26 +0200 Subject: [PATCH] docs: update docs --- docs/design/part-TODO.txt | 3 +- docs/random/status-0.11-14-jun-2011.txt | 192 ++++++++++++++++++++++++ 2 files changed, 193 insertions(+), 2 deletions(-) create mode 100644 docs/random/status-0.11-14-jun-2011.txt diff --git a/docs/design/part-TODO.txt b/docs/design/part-TODO.txt index 6e5bab84bf..6b9e2a47db 100644 --- a/docs/design/part-TODO.txt +++ b/docs/design/part-TODO.txt @@ -10,8 +10,7 @@ API/ABI keyframe, after the seek you want to get the new stream time that will actually be used to update the slider bar. -- make gst_pad_push_event() return a GstFlowReturn so that we can resend - NEWSEGMENT and other events. +- make gst_pad_push_event() return a GstFlowReturn - GstEvent, GstMessage register like GstFormat or GstQuery. diff --git a/docs/random/status-0.11-14-jun-2011.txt b/docs/random/status-0.11-14-jun-2011.txt new file mode 100644 index 0000000000..a6c761ce3a --- /dev/null +++ b/docs/random/status-0.11-14-jun-2011.txt @@ -0,0 +1,192 @@ +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 + + + + + + + +