mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-07-26 00:08:21 +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

133
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,113 +165,106 @@ 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
- register to an interval-timer hook.
rusage - call getrusage() and log resource usage
- register to an interval-timer hook.
- call getrusage() and log resource usage
## dbus (not yet implemented) ## dbus (not yet implemented)
- provide a dbus iface to announce applications that are traced - provide a dbus iface to announce applications that are traced
- tracing UIs can use the dbus iface to find the channels where logging and - tracing UIs can use the dbus iface to find the channels where logging and
tracing is getting logged to tracing is getting logged to
- one would start the tracing UI first and when the application is started with - one would start the tracing UI first and when the application is started with
tracing activated, the dbus plugin will announce the new application, tracing activated, the dbus plugin will announce the new application,
upon which the tracing UI can start reading from the log channels, this avoid upon which the tracing UI can start reading from the log channels, this avoid
missing some data missing some data
## 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)
- log ref-counts of objects - log ref-counts of objects
- just logging them outside of glib/gobject would still make it hard to detect - just logging them outside of glib/gobject would still make it hard to detect
issues though issues though
## 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)
## memory (not yet implemented) ## memory (not yet implemented)
- trace live instance (and pointer to the memory) - trace live instance (and pointer to the memory)
- use an atexit handler to dump leaked instance - use an atexit handler to dump leaked instance
https://bugzilla.gnome.org/show_bug.cgi?id=756760#c6 https://bugzilla.gnome.org/show_bug.cgi?id=756760#c6
## leaks ## leaks
- track creation/destruction of GstObject and GstMiniObject - track creation/destruction of GstObject and GstMiniObject
- log those which are still alive when app is exiting and raise an - log those which are still alive when app is exiting and raise an
error if any error if any
- If the GST_LEAKS_TRACER_SIG env variable is defined the tracer - If the GST_LEAKS_TRACER_SIG env variable is defined the tracer
will handle the following UNIX signals: will handle the following UNIX signals:
- SIGUSR1: log alive objects - SIGUSR1: log alive objects
- SIGUSR2: create a checkpoint and print a list of objects created and - SIGUSR2: create a checkpoint and print a list of objects created and
destroyed since the previous checkpoint. destroyed since the previous checkpoint.
- If the GST_LEAKS_TRACER_STACK_TRACE env variable is defined log - If the GST_LEAKS_TRACER_STACK_TRACE env variable is defined log
the creation stack trace of leaked objects. This may significantly the creation stack trace of leaked objects. This may significantly
increase memory consumption. increase memory consumption.
## gst-debug-viewer ## gst-debug-viewer