mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2025-02-07 15:02:40 +00:00
Code Issues 1 Projects Releases Wiki Activity

tracing: restore some formatting

Browse source 
Some bullet lists where converted into a block.
This commit is contained in:
Stefan Sauer 2016-12-13 13:22:23 +01:00
parent 033cc24135
commit f0f2371af9
1 changed files with 63 additions and 70 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

59
markdown/design/tracing.md
View file

@ -130,7 +130,7 @@ tool that processes the log.
## tracer event classes ## tracer event classes
Most tracers will log some kind of *events* : a data transfer, an event, 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 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. 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 A few ideas that are not yet in the above spec:
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 READABLE gobject property. - it would be nice to describe the unit of values
The property has name/description. We could use qdata for scope and - putting it into the description is not flexible though, e.g. time
flags (or have some new property flags). We would also need a new would be a guint64 but a ui would reformat it to e.g. h:m:s.ms
"notify" signal, so that value-change notifications would include a - 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 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 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 log. Or we just add a gst_tracer_class_install_event() and that
mimics the g_object_class_install_property(). mimics the g_object_class_install_property().
Frontends can: - do an events over time histogram - plot curves of Frontends can:
values over time or deltas - show gauges - collect statistics (min, max, - do an events over time histogram
avg, …) - plot curves of values over time or deltas
- show gauges
We can have some under gstreamer/plugins/tracers/ - collect statistics (min, max, avg, …)
## latency ## latency
- register to buffer and event flow - register to buffer and event flow
- send custom event on buffer flow at source elements - send custom event on buffer flow at source elements
- catch events on event transfer at sink elements - catch events on event transfer at sink elements
## meminfo (not yet implemented) ## meminfo (not yet implemented)
- register to an interval-timer hook. - register to an interval-timer hook.
- call mallinfo() and log memory usage - call mallinfo() and log memory usage rusage
rusage
- register to an interval-timer hook. - register to an interval-timer hook.
- call getrusage() and log resource usage - call getrusage() and log resource usage
## dbus (not yet implemented) ## dbus (not yet implemented)
@ -226,13 +222,11 @@ We can have some under gstreamer/plugins/tracers/
## topology (not yet implemented) ## topology (not yet implemented)
- register to pipeline topology hooks - register to pipeline topology hooks
- tracing UIs can show a live pipeline graph - tracing UIs can show a live pipeline graph
## stats ## stats
- register to buffer, event, message and query flow - register to buffer, event, message and query flow
- tracing apps can do e.g. statistics - tracing apps can do e.g. statistics
## refcounts (not yet implemented) ## refcounts (not yet implemented)
@ -244,7 +238,6 @@ We can have some under gstreamer/plugins/tracers/
## opengl (not yet implemented) ## opengl (not yet implemented)
- upload/download times - upload/download times
- there is not hardware agnostic way to get e.g. memory usage info (gl - there is not hardware agnostic way to get e.g. memory usage info (gl
extensions) extensions)