GNOME Bugzilla – Bug 338292
MAD plugin hangs when performing non-flushing seek.
Last modified: 2009-03-06 09:21:35 UTC
Please describe the problem: I try to play a short fragment within an mp3 file. When I try to loop over the fragment as recommended in http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/part-seeking.txt?view=markup (i.e. I issue another non-flushing seek immediately after catching SEGMENT_DONE message). I can watch the following behaviour: * The fragment plays okay for some time * A SEGMENT_DONE message is posted, buffered data continues to play. * When time comes for the segment to start over, the plugin starts to spew out tons of SEGMENT_DONE messages one right after another, until the pipeline is stopped. Steps to reproduce: 1. I'm going to attach a small python script (a cutout from my app) that can be used to test segment-seeking behaviour. It can be used like this: $ segment-test.py test.mp3 20 30 1 argument are: <start_seconds> <stop_seconds> <loop = 0|1> Actual results: Expected results: Does this happen every time? Other information:
Created attachment 63354 [details] The test program for this bug I've attached the same program to test bug #338290
Nice test program :) Added it to my list of test applications. The main problem is mad is reaally bad at figuring out time <=> bytes conversion and this affects segment seeking and also seeking positions. The best would be to add pull-based behaviour to mad, where mad would figure out exactly where to seek in bytes once it has enough information, etc...
works fine now. Hard to say what/when this was fixed :(