GNOME Bugzilla – Bug 697074
The level element doesn't respect accurately the "interval" property.
Last modified: 2013-04-04 13:03:33 UTC
As shown by such a pipeline: gst-launch-1.0 uridecodebin uri=file:///path/to/sound ! audioconvert ! level interval=10000000 ! fakesink -m | grep level | wc -l the number of messages does not respect the interval. There are more messages, but not ten times more as expected (default value is 100000000). The patch attached should solve that.
Created attachment 240336 [details] [review] patch for frame accurate level detection
Is this still needed after: commit 2e56032031e7dda0d654bddd59efad22bb8b1183 Author: Stefan Sauer <ensonic@users.sf.net> Date: Wed Apr 3 19:05:38 2013 +0200 level: subdivide buffers for sample accurate interval handling Previously we would skip level message when processing buffers > the requested interval. Also the message frequency would contain quite some jitter due to only considering them at the end of buffers. Cleanup the tests while we're at it.
Hi ! No this patch does the job, cool ! The wc -l at the end gives the exact same results, which is a good sign that the fixes are both correct. Have a good day.
Ah on a second thought there actually is one problem which this commit does not fix and mine does : the messages could be timestamped more precisely, for now if you send 2 messages for one buffer they all have the exact same timestamp, whereas the second should have buffer_timestamp + duration_of filter->interval_frames.
Hm, I think Stefan's change did that... did I miss something? :) It doesn't use the buffer's timestamp directly but calculates the real timestamp from the offset... code should be more or less the same as in the spectrum element. If that's missing here feel free to provide a new patch to do that :)
Mathieu, if you feel the change is not good yet, it would be awesome if you could write a (failing) test.
Oh sorry my bad, misread timestamps as they were like : 13926734690 13936734690 Only looked at the end and thought they were the same, actually the current commit takes care of re-timestamping so everything is fine !