mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-01-20 06:08:14 +00:00
193 lines
7.2 KiB
Text
193 lines
7.2 KiB
Text
|
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
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|