mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-07-26 00:08:21 +00:00
tracing: restore some formatting
Some bullet lists where converted into a block.
This commit is contained in:
parent
033cc24135
commit
f0f2371af9
|
@ -130,7 +130,7 @@ tool that processes the log.
|
|||
## tracer event classes
|
||||
|
||||
Most tracers will log some kind of *events* : a data transfer, an event,
|
||||
a message, a query or a measurement. Every tracers should describe the
|
||||
a message, a query or a measurement. Every tracer should describe the
|
||||
data format. This way tools that process tracer logs can show the data
|
||||
in a meaningful way without having to know about the tracer plugin.
|
||||
|
||||
|
@ -165,52 +165,48 @@ gst_tracer_record_new ("thread-rusage.class",
|
|||
```
|
||||
|
||||
|
||||
A few ideas that are not yet in the above spec: - it would be nice to
|
||||
describe the unit of values - putting it into the description is not
|
||||
flexible though, e.g. time would be a guint64 but a ui would reformat it
|
||||
to e.g. h:m:s.ms - other units are e.g.: percent, per-mille, or kbit/s -
|
||||
we’d like to have some metadata on scopes - e.g. we’d like to log the
|
||||
thread-names, so that a UI can show that instead of thread-ids - the
|
||||
stats tracer logs *new-element* and *new-pad* messages - they add a
|
||||
unique *ix* to each instance as the memory ptr can be reused for new
|
||||
instances, the data is attached to the objects as qdata - the latency
|
||||
tracer would like to also reference this metadata - right now we log the
|
||||
classes as structures - this is important so that the log is self
|
||||
contained - it would be nice to add them to the registry, so that
|
||||
gst-inspect can show them
|
||||
A few ideas that are not yet in the above spec:
|
||||
|
||||
We could also consider to add each value as a READABLE gobject property.
|
||||
The property has name/description. We could use qdata for scope and
|
||||
flags (or have some new property flags). We would also need a new
|
||||
"notify" signal, so that value-change notifications would include a
|
||||
- it would be nice to describe the unit of values
|
||||
- putting it into the description is not flexible though, e.g. time
|
||||
would be a guint64 but a ui would reformat it to e.g. h:m:s.ms
|
||||
- other units are e.g.: percent, per-mille, or kbit/s
|
||||
- we’d like to have some metadata on scopes
|
||||
- e.g. we’d like to log the thread-names, so that a UI can show
|
||||
that instead of thread-ids
|
||||
- the stats tracer logs *new-element* and *new-pad* messages
|
||||
- they add a unique *ix* to each instance as the memory ptr can be
|
||||
reused for new instances, the data is attached to the objects as qdata
|
||||
- the latency tracer would like to also reference this metadata
|
||||
|
||||
Right now we log the classes as structures, this is important so that the log
|
||||
is self contained. It would be nice to add them to the registry, so that
|
||||
gst-inspect can show them. We could also consider to add each value as a
|
||||
READONLY gobject property. The property has name/description. We could use
|
||||
qdata for scope and flags (or have some new property flags). We would also
|
||||
need a new "notify" signal, so that value-change notifications would include a
|
||||
time-stamp. This way the tracers would not needs to be aware of the
|
||||
logging. The core tracer would register the notify handlers and emit the
|
||||
log. Or we just add a gst_tracer_class_install_event() and that
|
||||
mimics the g_object_class_install_property().
|
||||
|
||||
Frontends can: - do an events over time histogram - plot curves of
|
||||
values over time or deltas - show gauges - collect statistics (min, max,
|
||||
avg, …)
|
||||
|
||||
We can have some under gstreamer/plugins/tracers/
|
||||
Frontends can:
|
||||
- do an events over time histogram
|
||||
- plot curves of values over time or deltas
|
||||
- show gauges
|
||||
- collect statistics (min, max, avg, …)
|
||||
|
||||
## latency
|
||||
|
||||
- register to buffer and event flow
|
||||
|
||||
- send custom event on buffer flow at source elements
|
||||
|
||||
- catch events on event transfer at sink elements
|
||||
|
||||
## meminfo (not yet implemented)
|
||||
|
||||
- register to an interval-timer hook.
|
||||
- call mallinfo() and log memory usage
|
||||
|
||||
rusage
|
||||
|
||||
- call mallinfo() and log memory usage rusage
|
||||
- register to an interval-timer hook.
|
||||
|
||||
- call getrusage() and log resource usage
|
||||
|
||||
## dbus (not yet implemented)
|
||||
|
@ -226,13 +222,11 @@ We can have some under gstreamer/plugins/tracers/
|
|||
## topology (not yet implemented)
|
||||
|
||||
- register to pipeline topology hooks
|
||||
|
||||
- tracing UIs can show a live pipeline graph
|
||||
|
||||
## stats
|
||||
|
||||
- register to buffer, event, message and query flow
|
||||
|
||||
- tracing apps can do e.g. statistics
|
||||
|
||||
## refcounts (not yet implemented)
|
||||
|
@ -244,7 +238,6 @@ We can have some under gstreamer/plugins/tracers/
|
|||
## opengl (not yet implemented)
|
||||
|
||||
- upload/download times
|
||||
|
||||
- there is not hardware agnostic way to get e.g. memory usage info (gl
|
||||
extensions)
|
||||
|
||||
|
|
Loading…
Reference in a new issue