After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 338292 - MAD plugin hangs when performing non-flushing seek.
MAD plugin hangs when performing non-flushing seek.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-13 02:36 UTC by Артём Попов
Modified: 2009-03-06 09:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
The test program for this bug (4.66 KB, text/x-python)
2006-04-13 02:37 UTC, Артём Попов
Details

Description Артём Попов 2006-04-13 02:36:13 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:
Comment 1 Артём Попов 2006-04-13 02:37:23 UTC
Created attachment 63354 [details]
The test program for this bug

I've attached the same program to test bug #338290
Comment 2 Edward Hervey 2006-05-11 10:57:06 UTC
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...

Comment 3 Edward Hervey 2009-03-06 09:21:35 UTC
works fine now. Hard to say what/when this was fixed :(