docs/random/status-0.11-14-jun-2011.txt

   1 0.11 status 1 jun 2011
   2 ----------------------
   3
   4 Hello again GStreamer hackers,
   5
   6
   7 Here's another status update from the 0.11 branch. This one is packed
   8 with new stuff because it really took too long between the last
   9 update, but well..
  10
  11
  12 Misc Core Changes
  13 -----------------
  14
  15 The first set of big core change was done by über hacker Sebastian Dröge.
  16 He removed our special GST_BOILERPLATE macro. Because of some API strangeness
  17 we needed to do actions in the base_init method, which the GST_BOILERPLATE
  18 macro set up for us. The base_init concept is unfortunately not supported
  19 by almost all language bindings so we wanted to clean this up and use the
  20 regular G_DEFINE_TYPE macros. By inheriting metadata and pad templates
  21 from the parent, the GST_BOILERPLATE macro could be removed.
  22
  23
  24 Removal of gst_pad_alloc_buffer
  25 -------------------------------
  26
  27 The next big change was the removal of gst_pad_alloc_buffer along with
  28 all the pad_alloc functions. The pad_alloc function were used to both
  29 implement allocation of buffers and notify upstream elements of new media
  30 formats. The functionality is replace by 3 new things: GstBufferPool (as
  31 noted in the previous status update), a new ALLOCATION query and a new
  32 RECONFIGURE event.
  33
  34 The ALLOCATION query is used to query the downstream elements about the
  35 buffer properties they would like. These properties include the size,
  36 prefix and alignment of the memory. The downstream element can also propose
  37 a GstBufferPool. It is then the upstream element that decides how it
  38 will allocate buffers. This allows us, for example, to make the video
  39 decoders specify their required memory alignment to the videosink.
  40
  41 Since new format suggestions are no longer piggybacked upstream with the
  42 allocation, something new was needed to notify upstream elements of a
  43 format change. It started with bringing in the new RENEGOTIATE event
  44 that Thiago Santos had been experimenting with in the 0.10 branch. The
  45 new event basically lets upstream elements know that new formats are
  46 possible somewhere downstream and it would make them renegotiate a new
  47 format before pushing a new buffer.
  48
  49 New format changes can also happen when new elements are linked, so
  50 gst_pad_link() will also send this RENEGOTIATE event upstream. As it turns
  51 out, adding new elements could also signal the availability of a new
  52 bufferpool or different ALLOCATION properties. The RENEGOTIATE event was
  53 thus renamed to the more generic RECONFIGURE event.
  54
  55 The most impressive result of these changes is that most of the
  56 complicated code in GstBaseTransform could simply be removed.
  57
  58
  59 Sticky Events
  60 -------------
  61
  62 The idea for the sticky events comes from the observation that a lot of the
  63 serialized downstream events (SEGMENT, EOS, TAGS, ..) are really context
  64 for the buffers that follow. The design called for making these events
  65 sticky on the pads, meaning that they become a property of the pads
  66 they travel over.
  67
  68 The result is that the current timing information (SEGMENT event) or the
  69 current stream medatadata (TAG event) that is handled by the pad are
  70 directly accessible by looking at the last event that traveled on the pad.
  71
  72 By making the events stick on the pads, we can propagate them downstream
  73 automatically when new pads are linked. This should solve one of the
  74 biggest 0.10 problems when dealing with dynamic pipelines, the loss of
  75 events (mostly NEWSEGMENT events).
  76
  77 It was then only natural to also make the CAPS event a sticky downstream
  78 serialized event. CAPS are indeed also context for the buffers that follow.
  79 The caps property was also removed from GstBuffer, making caps negotiation
  80 separate from the buffer dataflow again.
  81
  82
  83 GstSegment changes
  84 ------------------
  85
  86 For the sticky events to work with SEGMENT events, we needed to change
  87 the SEGMENT event so that it became selfcontained. The complicated segment
  88 accumulation logic of 0.10 was simply removed and replaced with pad offsets.
  89
  90 It is now possible to tweak the timing of the data comming from a pad by
  91 using the pad offset property.
  92
  93
  94 GstCaps optimizations
  95 ---------------------
  96
  97 It doesn't look like we'll be able to implement GstCaps iterators to 0.11 so
  98 Sebastian was looking for other ways to improve caps performance. One of the
  99 low hanging fruits was to pass the complete GstCaps structure to the
 100 GstBaseTransform transform_caps method. This allows for better and smarter
 101 implementations of the function at the cost of marginally more complex code.
 102
 103 Sebastian also added a filter caps parameter to the gst_pad_get_caps()
 104 function. This allows the caller to pass preferences and possible caps to
 105 the function. The result is that the pad can make much better negotiation
 106 decisions.
 107
 108 Sebastian also optimized gst_caps_is_subset()in the 0.10 branch and ported
 109 the results to 0.11 as well.
 110
 111 with the still planned caps simplifications later, these changes should
 112 substantially improve caps negotiation speed.
 113
 114
 115 Pad probes
 116 ----------
 117
 118 Quite a few iterations were needed to reimplement the pad blocking and pad
 119 probes. The new infrastructure allows you to add callbacks for the various
 120 stages in the data transfer on a pad.
 121
 122 It's now possible to be notified when no data is going over a pad with the
 123 IDLE probe. This should also fix one of the big problems with implementing
 124 dynamic pipelines and the old pad blocking.
 125
 126 Not all features that we want to add to the new probes are implemented yet
 127 but they can be added later without much trouble.
 128
 129
 130 Other gems
 131 ----------
 132
 133 A new SCHEDULING query was added to get more information about the upstream
 134 elements scheduling properties.
 135
 136 Tim-Philipp Müller finally removed our dependency on libxml2. Back in the
 137 day, we used XML for serialization of objects and the registry. Object
 138 serialization had long been deprecated and the XML registry was replaced
 139 with a much faster binary registry.
 140
 141 Tim also removed the unversioned gst-launch, gst-inspect and gst-typefind
 142 scripts. They were always confusing and annoying for packagers and users,
 143 it is just easier
 144
 145 Edward Hervey spent some time keeping the unit tests working and making
 146 sure the API docs are up to data.
 147
 148 GstIterator was made more binding friendly By Johan Dahlin and Sebastian.
 149
 150
 151 And what about the plugins..
 152 ----------------------------
 153
 154 As usual, all -base plugins are kept in sync with the core API updates and
 155 the new features. They are always a good place to see how the new API can
 156 be used and how to port things.
 157
 158
 159 What's next
 160 -----------
 161
 162 Almost all of the features laid out in the GStreamer conference last year
 163 are now implemented. We also have quite a few new cool features that
 164 slipped in. Things are shaping up indeed.
 165
 166 The last big missing piece is the redesign of the caps fields for raw audio
 167 and video. We plan to finish that in the next weeks.
 168
 169 There are also a few smaller things we would like to do: use GstQuery
 170 for the various caps functions, do GstFlowReturn for the query/event
 171 functions, ...
 172
 173 Meanwhile we start the stabilization phase and we will do a first prerelease
 174 of 0.11 this week to bring things to a wider audience. Now is the time to
 175 catch up and start porting your plugins to 0.11.
 176
 177 There is still a lot of work to be done to port plugins to 0.11 before we
 178 can release 1.0. I ask everyone again (and especially maintainers) to help
 179 us porting plugins, it's really a lot of work!
 180
 181
 182 Have a nice hacking week,
 183
 184 Wim
 185
 186
 187
 188
 189
 190
 191
 192