Thanks for the patch, could you please comment on my below design related
1) Do you know if their is any open-source element which prints arm cpu load,
bps,fps information? I guess most of these information can be easily calculated
by writing a simple gst application program. e.g
static void identity_cb (GstElement *fakesrc, GstBuffer *buffer, GstPad *pad,
/*** put logic to increment your fps/bps */
dentityElm = gst_element_factory_make("identity",
2) Have you check if gst-tracelib can be used to compute fps/bps/arm cpu load
without making any modification ?
If we are able to compute fps/bps/cpu-load using above two methods then we
should consider using either of those approaches instead of adding everything in
I like your approach to get dsp load and MemStat. But i think we should also
provide a call-back method very similar to "identify or queue"
elements - which can be used by application to query the dsp status (if needed).
E.g something like this
static void dspload_cb (GstElement *fakesrc, GstBuffer *buffer, GstPad *pad,
/* print dsp load */
static void dspmem_cb (GstElement *fakesrc, GstBuffer *buffer, GstPad *pad,
/* print memory status */
dspstatus = gst_element_factory_make("TIDspStatus",
g_signal_connect(dspstatus, "load", G_CALLBACK(dspload_cb),
g_signal_connect(dspstatus, "memory", G_CALLBACK(dspmem_cb),
I'm considering a possible use case where someone may wish to write gstreamer
application to replace dvsdk demo. Current dvsdk demo displays all of these
information on OSD window and if possible then we should try to provide these
DSP status information with callback so that user can query and display on OSD
I will look patch more closely and give you more feedback.
Thanks for the great ideas.
I do not know of any existing GStreamer element that provides this type of
information. There is a debug element we might want to look into - but for
gst-dmai testing instead of capturing performance data.
Enhancing gst-tracelib was my first choice. I contacted the author and asked
about a generalized registration / call back scheme so that element specific
data could also be added to the normal gst-tracelib captured information. This
is my long term direction. The author indicated that no such mechanism
currently exists or has been proposed before. He did say he liked the idea.
Allowing an application access to this information is intriguing. I hadn't that
of that use before. I could see adding worse case values as well.
The propose of the proposed dmaiperf element is to capture performance data so
we can track if gst-dmai is getting faster or slower with each release.
In reviewing the code:
gsttidmaiperf.c line 45:
Looks wrong and doesn't seem to be needed.
gsttidmaiperf.c line 246:
engineName = g_strdup(g_value_get_string(value))
I don't see a matching free.
gsttidmaiperf.c lines 184 and 186:
Perfance should be Performance
gsttidmaiperf.c lines 276 .. 279, 287..288
The output from dmaiperf will likely be parsed by some simple tools and dumped
into a spreadsheet or database. Please make the parsing trivial, like
key: value ; <more key: value pairs>
timestamp: <value> ; bps: <value> ; fps:
<value> ; dsp_load: <value> ;
mem_segment: %s ; base: 0x%x ; size: 0x%x ; maxblocklen: 0x%x ; used: 0x% ;
Now that I have written it, I see the entire set has one timestamp, and there
is mem_segment data for each mem_segment, so my format isn't very good either.
Maybe someone as a better suggestion. My objective is a simple command line
tool to pull the data into the test results spreadsheet.
Thanks for the patch. A couple of comments:
1. In gst_dmaiperf_init function the value for dmaiperf->hDsp is
initialized to NULL twice. You can remove one of these initializations.
2. I don't see that you are tracking the ARM CPU load as well as the DSP CPU
3. There is no property to turn off certain statistics. For example, if I want
to collect stats during an AVI decode I need to add this element to the video
and audio paths. In this case I would want to disable the report of the DSP
load and memstats in one of the instances so that I don't get duplicate
4. Following up on what Todd said perhaps just printing the stats as a comma
seperated list would be easier to parse and feed into a spreadsheet.
Overall this looks good but I think we need to add items 2 and 3 above.
I fixed all the errors that you advised me and I added new property to handle
the ARM load print.
About print DSP load, isn't necessary to put a property, because if you don't
put the Engine Name, the DSP load information is not printed.
Also, I write the new structure to show the Information, which would be easy to
I think this g_free below is causing a core dump on the DM365 platform when you
create and destroy a pipeline
with the dmaiperf element in it.
I have never used g_error_new function before but I tried freeing using
g_error_free and seems ok.
Very useful element for me Lissandro, good work!
Patch version 3. Includes Stewart's fix, the word EXPERIMENTAL in the
description, and standard GStreamer element documentation.
I didn't create the v3 patch correctly. Trying again with v4.
Sorry for the late review, Lix. I have the following comments, although they
are all minor:
1) A couple functions are missing comment blocks.
2) You use "4096" in a few places for a temporary string.
Static string-lengths always raise a red flag with me as I have debugged many
array-bound-write issues that root-caused to something like this. Given that
this is a debug element and time stamps have a fixed size, I'm not too alarmed,
but it would be good if we could do one of the following:
a. Find a way to calculate the max size of the string, and malloc/free it
instead if needed. That is probably overkill in this case.
b. See if "GST_TIME_FORMAT" has a corresponding
"MAX" macro that defines the maximum size of the value that
could get written into a time parameter (something like
GST_TIME_FORMAT_MAX_SIZE), and use that macro in place of 4096.
c. If a. and b. don't pan out, at least write a macro like:
#define GST_TIME_FORMAT_MAX_SIZE 4096
in the .c file and use that instead of 4096, so if by chance we ever need
to increase the size, we only need to increase it in once place (makes the
change less error-prone).
Otherwise, looks pretty stratight-forward and good.
Version 5 patch - Used Don's GST_TIME_FORMAT_MAX_SIZE approach to message buffer
handling, added missing headers, and removed unnecessary newline at end of
Thanks! Looks good.
Check in revision 427. I have a patch to cmem to display max usage information
and plan to extend dmaiperf to capture that information as well.
|assignee||None||Todd Fischer from RidgeRun