After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791093 - add OMX_PERFORMANCE debug category
add OMX_PERFORMANCE debug category
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-omx
git master
Other Linux
: Normal enhancement
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-12-01 15:31 UTC by Guillaume Desmottes
Modified: 2018-01-29 17:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
add OMX_PERFORMANCE debug category (3.06 KB, patch)
2017-12-01 15:32 UTC, Guillaume Desmottes
none Details | Review
add OMX_PERFORMANCE debug category (4.17 KB, patch)
2018-01-29 15:21 UTC, Guillaume Desmottes
committed Details | Review

Description Guillaume Desmottes 2017-12-01 15:31:57 UTC
.
Comment 1 Guillaume Desmottes 2017-12-01 15:32:13 UTC
Created attachment 364765 [details] [review]
add OMX_PERFORMANCE debug category

Can be used to log buffers exchange between OMX and gst-omx to profile
performances of the OMX component.
Ideally this should be done using tracer hooks but it's currently not
possible to define custom hooks outside of core.

Use GST_DEBUG="OMX_PERFORMANCE:8" to enable it.
See also
https://github.com/gdesmott/gst-log-parser/blob/master/src/bin/omx-perf.rs
as a simple program consuming those logs to generate gnuplot files and
stats.
Comment 2 Nicolas Dufresne (ndufresne) 2018-01-29 11:35:23 UTC
Review of attachment 364765 [details] [review]:

What's the use for this if you cannot match the buffers ? Should't you print the buffer pointer, or some ID / Handle ?
Comment 3 Tim-Philipp Müller 2018-01-29 11:46:38 UTC
Can't you easily get this info from the existing debug log output by matching function names?
Comment 4 Nicolas Dufresne (ndufresne) 2018-01-29 12:06:24 UTC
If so, that commit message should say something since it's not trivial.
Comment 5 Guillaume Desmottes 2018-01-29 14:09:34 UTC
(In reply to Tim-Philipp Müller from comment #3)
> Can't you easily get this info from the existing debug log output by
> matching function names?

Kind of, but not for all events.

My goal here was to provide an experience very similar to the hooks/tracer system. Having a specific debug domain make it easier to turn on/off and allow us to enable only those logs (which can be useful to reduce the logs overhead when profiling performances).

I also wanted to make those more parser than human reader friendly. My vague plan was to use serialized GstStructure if I ever need to pass more infos (like tracers do).

(In reply to Nicolas Dufresne (stormer) from comment #2)
> Review of attachment 364765 [details] [review] [review]:
> 
> What's the use for this if you cannot match the buffers ? Should't you print
> the buffer pointer, or some ID / Handle ?

We were only interested in the events rate and timing but indeed that could be useful. I'll add that using the parser friendly syntax suggested above.
Comment 6 Guillaume Desmottes 2018-01-29 15:21:21 UTC
Created attachment 367578 [details] [review]
add OMX_PERFORMANCE debug category

Can be used to log buffers exchange between OMX and gst-omx to profile
performances of the OMX component.
Ideally this should be done using tracer hooks but it's currently not
possible to define custom hooks outside of core.

Use GST_DEBUG="OMX_PERFORMANCE:8" to enable it.
See also
https://github.com/gdesmott/gst-log-parser/blob/master/src/bin/omx-perf.rs
as a simple program consuming those logs to generate gnuplot files and
stats.
Comment 7 Nicolas Dufresne (ndufresne) 2018-01-29 15:40:08 UTC
Review of attachment 367578 [details] [review]:

Yep, likes it.
Comment 8 Nicolas Dufresne (ndufresne) 2018-01-29 17:17:06 UTC
Attachment 367578 [details] pushed as 65cc312 - add OMX_PERFORMANCE debug category