GNOME Bugzilla – Bug 574275
flacdec ! appsink with a seek seems to drop the first buffer
Last modified: 2009-03-09 16:18:27 UTC
I created a branch where I added a test in tests/check/pipelines/flacdec The goal is to be able to get a range of decoded samples out of flacdec. The range needs to be exact, will be used for CRC'ing. I attach the log file from running the test_seek_full test, that does a seek for exactly the complete set of decoded samples. It looks like gst_pad_alloc_buffer from flacdec on appsink:sink fails because appsink is flushing. (I don't know if the seek has to be flushing in this case, but that's what normally gets done.)
Created attachment 130133 [details] debug log
what's the problem? the first sample after the seek is not the right sample?
Yes. The first buffer of decoded samples is dropped and doesn't arrive in appsink when you do a seek. Both a seek for the full file (0..total number of decodable samples) and a partial seek have the first buffer dropped. AFAIK the unit tests should pass and the two with the seek don't.
It seems the flac API also decodes the first buffer in the function that is supposed to only perform the seek.
commit 8f8e035cd5794658a359d7233fe67f48f5d77b2c Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Mar 9 17:14:12 2009 +0100 flacdec: don't lose the first buffer after a seek The flacdec API calls the write callback when performing a seek. We cannot yet push out a buffer at that time so we must keep it and push it out later. Flush out the upstream part of the pipeline when doing a seek. Fixes #574275.