GNOME Bugzilla – Bug 304758
[PATCH] Seeking in pipelines with mad mp3 decoder introduces noise in the audio
Last modified: 2008-05-06 12:14:25 UTC
Testcase will be attached.
Created attachment 46636 [details] Testcase for this problem. Use make to generate an mp3 file to test the program on.
Created attachment 46641 [details] [review] Proposal for avoiding this behaviour While this is probably considered as a dirty hack, it add's sample accurate seeking with mad. It add's a sync-timeout parameter which defines a sync timeframe. When doing a normal seek, we actually seek to seek_time - sync-timeout and set the segment_start. In the chain function we check if the newly decoded data timestamp and duration agains the segment_start and discard, cut or just pass the decoded data.
Created attachment 47020 [details] [review] Same patch but this one applies on gst-plugins-0.8.9 release
You duplicate a lot of code by doing this. Can you do that nicer by refactoring that part into its own function?
Thanks for sending in. Raising priority to make maintainers aware of patch.
Created attachment 47746 [details] [review] cleaned up the code Cleaned up the code as suggested
Hi Wouter, Thanks for the patches. A few comments: 1) Try to avoid whitespace changes 2) New code should be in GStreamer style (see the faq) 3) 0.8 is unmaintained now; could you take a look at 0.10 and see what needs to be done? Thanks!
I suspect that the noise you're experiencing actually stems from MAD synchronising on a false synch-sequence in the mp3 data. I know I had some trouble making the Fluendo mp3 plugin synch detection robust enough to avoid this problem. The seeking output there is considerably different. There's some sample output seeking around on the sample sine wave mp3 from the testcase here, to compare the output from mad and flump3dec: http://noraisin.net/~jan/gst/mad_seek_problem/
Wouter, can you please try to answer Andy's comment?
I lost track of this bug completely. Currently I'm looking into what needs to be done, but my spare time is scarce as is my knowledge of 0.10. I'm not sure on how to transform the seek in the segment philosophy of 0.10. I would appreciate any input on this.
This bug should be fixed by mp3parse in gst-plugins-ugly 0.10.7. It supports accurate seeking and correctly resyncs on mp3 frames in almost every case. If you believe that this bug is still valid please reopen :)