GNOME Bugzilla – Bug 324387
"Seek in ready" for Mad plugin
Last modified: 2009-03-06 11:05:55 UTC
I've attached a patch that enables mad plugin to seek in ready state. It basically stores the initial seek event until the element can use it, and then executes the seek. The patch is based on this one: http://bugzilla.gnome.org/show_bug.cgi?id=323880
Created attachment 56113 [details] [review] "seek in ready" support for mad
I have some problems with the seek in READY patches for _chain based elements. 1) you cannot sanely execute a seek in the _chain function, the upstream element might want to pause/synchronize its streaming thread, which is impossible since it's executing the seek. 2) when the seek is to be performed by an upstream demuxer, the downstream chain based elements should flush their stored seek event. There is no problem for seek-in-READY for pull based elements, so patches for that go in directly (also making the mp3 plugin support pull based scheduling+seek-in-READY is a possibility). I would like to extend the seek-in-READY to work in a complete pipeline. It would go a bit like this: you seek on the pipeline, it stores the event. When setting the elements to READY the bin issues the seek on each element (from sink to source). The elements go to PLAYING, the one driving the pipeline (source/demuxer) issues the seek to start producing data from the right position. Upon the FLUSH_STOP event all downstream elements flush the seek event. Elements activated in pull mode discard the seek event as well. If the source/demuxer cannot issue the seek for some reason, an http source that does not support time based seeks, for example, a seek might be performed by a downstream _chain based element. It's not clear to me how this seek should be performed, some options: collect info in the chain based element (mostly bitrate to do a byte seek) which can then be used to: -- ask the pipeline to issue a seek by posting a message. -- perform a seek in another thread. -- fail the seek. -- ...
Is this bug still relevant with mp3 seeking being moved to the mp3parse element? I guess it might be relevant to that plugin still, but not to the mad plugin itself?
IIRC, seek-in-ready was a crazy idea we had back then to solve the diva-not-using-gnonlin issues. Senko, wim, you're ok if we close this ?
Senko confirmed this is the wrong behaviour indeed.