GNOME Bugzilla – Bug 655276
flac, ogg: improve sample level seek accuracy
Last modified: 2018-05-04 09:46:58 UTC
this function is expected to seek to the requested position accurately, #python2 seek_simple(gst.FORMAT_TIME, gst.SEEK_FLAG_FLUSH | gst.SEEK_FLAG_ACCURATE, sample) attached python script generates test wav, flac, ogg, mp3 files and reports if seeking is correctly done. #sample output in my machine. wav requested buffer_timestamp_to_sample actual 44100 44100.0 44100 49100 49100.0000085 49100 54100 54100.000017 54100 59100 59100.0000255 59100 64100 64100.000034 64100 69100 69100.0000425 69100 74100 74100.0000069 74100 79100 79100.0000154 79100 84100 84100.0000239 84100 flac requested buffer_timestamp_to_sample actual 44100 41470.9999767 41472 49100 46078.9999803 46080 54100 50686.9999839 50688 59100 55294.9999875 55296 64100 59902.9999911 59904 69100 64510.9999947 64512 74100 73726.9999578 73728 79100 78334.9999614 78336 84100 82942.999965 82944 ogg requested buffer_timestamp_to_sample actual 44100 44100.0 44100 49100 49099.9999644 49100 54100 54099.9999729 54099 59100 59099.9999814 59100 64100 64099.9999899 64100 69100 69099.9999984 69100 74100 74099.9999628 74099 79100 79099.9999713 79100 84100 84099.9999798 84099 mp3 requested buffer_timestamp_to_sample actual 44100 44100.0 44101 49100 49099.9999644 49100 54100 55295.9979264 -1 59100 59099.9999814 59100 64100 66815.9974944 66816 69100 77183.9971056 -1 74100 74099.9999628 74101 79100 79099.9999713 79101 84100 84099.9999798 84101 column explanation (the unit of position is sample) requested : requested seek position buffer_timestamp_to_sample : buffer's timestamp position, (converted to sample unit) actual : actual buffer.data 's position. -1 means it couldn't find the position due to data mismatch. #comment only wav is successful in sample level accurate seek. Fix is needed for other formats. I think it's the decoders problem.
Created attachment 192621 [details] test code
I think it's better to dig ogg first.
What did you get in the NEWSEGMENT event? Or better, what do you get if you put an audiorate element after each decoder?
(In reply to comment #3) > What did you get in the NEWSEGMENT event? Or better, what do you get if you > put an audiorate element after each decoder? putting audiorate element, changed line 97 to pipeline = gst.parse_launch('filesrc location=' + filename + ' ! decodebin2 ! audiorate ! audioconvert dithering=0 ! appsink name=sink caps=audio/x-raw-int,rate=44100,channels=2,depth=16,width=16,signed=true,endianness=1234') output: [kkb110@myhost tmp]$ python2 test.py ** Message: pygobject_register_sinkfunc is deprecated (GstObject) wav requested buffer_timestamp_to_sample actual 44100 44100.0 44100 49100 49099.9999644 49100 54100 54099.9999729 54100 59100 59099.9999814 59100 64100 64099.9999899 64100 69100 69099.9999984 69100 74100 74099.9999628 74100 79100 79099.9999713 79100 84100 84099.9999798 84100 flac requested buffer_timestamp_to_sample actual 44100 44100.0 44101 49100 49098.9999969 49100 54100 54098.9999613 54100 59100 59098.9999698 59100 64100 64098.9999783 64100 69100 69098.9999868 69100 74100 74098.9999953 74100 79100 79098.9999597 79100 84100 84098.9999682 84100 ogg requested buffer_timestamp_to_sample actual 44100 44100.0 44100 49100 49099.9999644 49100 54100 54099.9999729 54099 59100 59099.9999814 59100 64100 64099.9999899 64100 69100 69099.9999984 69100 74100 74099.9999628 74099 79100 79099.9999713 79100 84100 84099.9999798 84099 mp3 requested buffer_timestamp_to_sample actual 44100 44100.0 44101 49100 49099.9999644 49100 54100 54098.9999613 -1 59100 59098.9999698 -1 64100 64099.9999899 64100 69100 69098.9999868 -1 74100 74099.9999628 74101 79100 79099.9999713 79101 84100 84099.9999798 84101 In my code, I compare the returned buffer to the buffer built by build_answer function which read from the first to the end without seeking, and that's 'actual' column above. Thanks for letting me know audiorate element, now it's much better.
audiorate doesn't fix the decoder bugs, but it makes it clear that there are decoder bugs. Marking as NEW.
Added a C version of the test to gst-plugins-good: commit 65ff17660b65e29e4888142009d3045825c7fa15 Author: Tim-Philipp Müller <tim@centricular.com> Date: Thu Nov 27 11:16:35 2014 +0000 tests: add interactive test for accurate seeking For some audio formats. https://bugzilla.gnome.org/show_bug.cgi?id=655276 commit 4459088c6d452b7e3e7170222b151344953d14e8 Author: Tim-Philipp Müller <tim@centricular.com> Date: Thu Nov 27 11:20:36 2014 +0000 test: use gst_util_uint64_scale_round() for timestamp to sample calculation Result: wav: requested sample per ts actual(data) 44100 44100 44100 49100 49100 49100 54100 54100 54100 59100 59100 59100 64100 64100 64100 69100 69100 69100 74100 74100 74100 79100 79100 79100 84100 84100 84100 flac: requested sample per ts actual(data) 44100 44100 44100 49100 49100 49100 54100 54100 54100 59100 59100 59099 <------- 64100 64100 64100 69100 69100 69100 74100 74100 74100 79100 79100 79100 84100 84100 84100 ogg: requested sample per ts actual(data) 44100 44100 44100 49100 49100 49100 54100 54100 54100 59100 59100 59100 64100 64100 64100 69100 69100 69100 74100 74100 74100 79100 79100 79100 84100 84100 84099 <------- mp3: requested sample per ts actual(data) 44100 44100 44100 49100 49100 49100 54100 54100 54100 59100 59100 59100 64100 64100 64100 69100 69100 69100 74100 74100 74100 79100 79100 79100 84100 84100 84100 Not sure if we want to keep this open really. Is anyone going to work on this?
> Is anyone going to work on this? Apparently not :)