[gst-devel] handling seeking in audio decoder plugin

Sameer Naik sameer.subscriptions at damagehead.com
Mon Nov 30 11:50:04 CET 2009


Hi,
I have developed an audio decoder plugin for gstreamer that uses TI's
dsp decoders that decode the audio frames on the dsp.

An overview of the plugin architecture:
In the plugin i am parsing the audio stream (if the stream is not
packetized) so as to feed entire audio frames to the dsp decoder. Due
to the parsing code i store some of the input data to parse with the
next input buffer. in the stream once i have sync'd to an audioframe,
i calculate the encoded framelength and start copying the data into an
internal buffer that is designated as the dsp decoders  input buffer.
Only after the entire frame has been copying, the DSP algorithm is
fired up to decode the encoded audio frame.

Regarding seeking i have a few questions.
Firstly, on an seek event i will need to clear the data in the
decoders input buffer as well as the data that i store for parsing
with the next input buffer. I want to know whether
1] the plugin could receive a buffer (_chain process) and an event
(_event_handler) at the same time.  What i mean to say is if the
_chain function is called, could the pad _event handler be called
while the _chain function is still processing the input buffer.
2] Or does this happen in an orderly fashion, where if the _chain
function is currently processing data, then the pad _event  handler
will not be called until the _chain has finished its processing.
Currently i have specified locks on the dsp decoders input buffers,
which is required if case 1 true, while it is absolutely unnecessary
if case 2 is true.

Secondly, as mentioned above i clear the decoders input buffer and the
other buffers on a seek event. Should i do this buffer cleanup on a
seek event or should i handle this in a new segment event or both.

Currently seeking is working most of the time. however it does fail
sometimes. Your response will help me in narrowing things down.

Please comment
~Sameer




More information about the gstreamer-devel mailing list