forked from GStreamer/gstreamer
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathstatus-0.11-14-jun-2011.txt
192 lines (130 loc) · 7.17 KB
/
status-0.11-14-jun-2011.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
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