mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-10 03:19:40 +00:00
85 lines
3.5 KiB
Text
85 lines
3.5 KiB
Text
Fixing Performance
|
|
------------------
|
|
|
|
1) Observations
|
|
|
|
The following observations are made when considering the current (17/11/2004)
|
|
problems in gstreamer.
|
|
|
|
- startup time.
|
|
Most of the time is spend in reading the xml registry. Several methods exist
|
|
for not using a registry (see testsuite/plugin/).
|
|
Since registries are pluggable, one can also write a binary registry which
|
|
should significantly reduce the size and the load time.
|
|
|
|
- Performance in state changes
|
|
State changes are pretty heavy currently because negotiation happens at
|
|
each state change. The PAUSED->PLAYING state change in particular is
|
|
too heavy and should be made more 'snappy'.
|
|
|
|
- Performance in data passing.
|
|
Too much checking is done in the push/pull functions. Most of these checks
|
|
can be performed more efficiently in the plugins, like checking if the
|
|
element is sufficiently negotiated. The discont event 'invent' hack used
|
|
for fixing the synchronisation has to go away.
|
|
|
|
We also propose a get_range based method for pads so that random-access
|
|
in file-based sources can happen more efficiently (typical for muxers).
|
|
|
|
- Scheduling overhead.
|
|
The current default opt scheduler has extensive data-structures and does
|
|
uses fairly complicated algorithms for grouping and scheduling elements.
|
|
This has performance impact on pipeline constructions and pipeline
|
|
execution.
|
|
|
|
- Events in dataflow.
|
|
Because events are put inside the dataflow, a typical chain function has
|
|
to check if the GstData object is an event of a buffer.
|
|
|
|
|
|
2) Proposed solutions
|
|
|
|
- startup time.
|
|
Volunteers to implement a binary registry?
|
|
|
|
- The changes listed in the separate document 'threading' will greatly
|
|
reduce the number of negotiation steps during state changes. It will
|
|
also reduce the latency between PAUSED<->PLAYING since it basically
|
|
involves unlocking a mutex in the sinks.
|
|
|
|
- adding return values to push/pull will offload some checks to the plugins
|
|
that can more efficiently and more accuratly handle most error cases.
|
|
With the new sync model in 'threading' it is also not needed to have
|
|
the 'invented' events in the pull function.
|
|
|
|
- The following scheduling policies should be made possible for pads:
|
|
|
|
1) get_range <-> pull-range-based
|
|
2) get <-> pull based
|
|
3) push <-> chain-based
|
|
|
|
The scheduling policies are listed in order of preference. A pad should
|
|
export what scheduling it supports and the core will select what
|
|
scheduling method to use. It is possible for a pad to support more than
|
|
one scheduling method.
|
|
|
|
It is possible that two elements cannot connect when they do not support
|
|
compatible scheduling policies. We require that pull-based pads also
|
|
support the chain based methods, at minimal, using a helper function to
|
|
queue a buffer and that get-based pads also support a push based implementation.
|
|
|
|
- With the changes listed in 'threading' the scheduler will be a lot more
|
|
simple since it does not have to keep track of groups and connected
|
|
elements. Starting and scheduling the pipeline will be a matter of
|
|
starting the source/loop GstTasks and they will from there on take
|
|
over.
|
|
|
|
- move events out of the dataflow. Different methods will be used to
|
|
send/receive events. This will also remove some of the checks in
|
|
the push/pull functions. Note that plugins are still able to serialize
|
|
buffers and events because they hold the streaming lock.
|
|
|
|
3) detailed explanation
|
|
|
|
TO BE WRITTEN
|
|
|