GNOME Bugzilla – Bug 516041
[Jokosher] Splitting mp3 and moving stops playback at the end of first piece
Last modified: 2008-06-05 10:04:45 UTC
Please describe the problem: For some time ago last year MP3 seeking problem was fixed in Gstreamer. I tested it in January and it worked. However, now it fails. Steps to reproduce: Tradicional steps of this bug see https://bugs.launchpad.net/jokosher/+bug/191273 Actual results: Jokosher fails to play futher than end of last piece Expected results: Jokosher plays piece and plays gap as silence between pieces Does this happen every time? Yes Other information: Log 2,mad*:5,gnl*:5
Created attachment 105062 [details] GST_DEBUG=2,mad:5,gnl*:5 log of app activity, gzipped
Could you please attach a log with GST_DEBUG_NO_COLOR=1 GST_DEBUG=5? You probably have to bzip/gzip it.
Created attachment 105126 [details] GST_DEBUG_NO_COLOR=1 GST_DEBUG=mp3parse:5
Ok, it seems mp3parse doesn't handle segment seeks properly... and I wonder how it can handle them properly at all in push mode. Upstream (which runs the pipeline), is supposed to post SEGMENT_START/SEGMENT_END messages on the bus. It unfortunately only knows about bytes, not time and it doesn't even know that this is a segment seek if we do accurate seeks (as mp3parse needs all data for time tracking anyway). Any idea how to support segments seeks in push based elements at all?
Created attachment 105136 [details] [review] mp3parse.diff
Created attachment 105138 [details] [review] mp3parse.diff improve debugging
Created attachment 105141 [details] GST_DEBUG_NO_COLOR=1 GST_DEBUG=mp3parse:5 Additional log with newest patch applied.
Created attachment 105142 [details] [review] mp3parse.diff
Created attachment 105143 [details] GST_DEBUG_NO_COLOR=1 GST_DEBUG=mp3parse:5 Additional log after last patch.
slomo: Does this patch actually fix the bug?
Unfortunately not and I have no idea what exactly causes this bug yet :/ The patch is correct though, will commit after release ;)
Oh well. I'm going to make the pre-releases. Perhaps you'll be able to merge a fix before Monday.
The patch doesn't fix the issue. Actually I tested with a vorbis clip and I had the same issue. I tried to get a log with GST_DEBUG=oggdemux:4 and it worked just fine, then I tried with GST_DEBUG=oggdemux:3 and it failed the same way as with the MP3.
Interesting. I was aware that there is bug for Ogg Vorbis, which acted like this: 1) Import Ogg Vorbis file in Jokosher 2) Split it in several segments 3) move them so they have space between them, some secs 4) Do playback Result: End of each segment gets "eaten", t.i. sound gets cut off, however, next segment starts precisely on time. It bears some similarity to this bug (as in this bug, cursor gets freezen for some time), but I am not very sure that they technically the same. However, it seems Ogg Vorbis error don't mix spaces and segments starts on time. It is kinda sad that this seems to be hard to fix, because it worked in January. I will try to get CVS from that date and test it and then give some logs/info about that.
I tried exactly the same thing on my work laptop, which is much more powerful, and there are no issues with any debug level, vorbis or MP3. I hear a small segment of sound that is not supposed to be there, but that's it.
Ok, this seems to be a bug in core or base then as it also happens with ogg files. Now lets summarize the two bugs that happen here: a) Trying to play two segments of a file, for example from 0 to 5 seconds and then from 6 to 9 seconds. Between the two segments there's a pause of ~5 seconds (maybe because that's the duration of the previous segment? bug from gst-plugins-base 0.10.15 comes to mind). From the log it seems that something waits exactly that time after mp3parse returns UNEXPECTED and before it gets the next newsegment event. Question now is, whether this only happens to segment seeks or all seeks and whether the state changes matter. Peteris tries to write a simple test case for this one. This also only happens on some machines with latest CVS, probably slower ones. b) Trying to play a segment of a file in jokosher, for example going from 2 to 5 seconds. Here something weird happens now, mp3parse gets a [0,-1] newsegment, pushes ~100 ms of buffers and then finally gets the [2,5] newsegment event and does the right thing. Felipe gets this with MP3s and Oggs too and it can be seen from Peteris log.
http://launchpadlibrarian.net/11958874/jokosher-mp3-seeking-6.log.gz
For a) Ok, as rebuilding everything from CVS "fixes" this it's not exactly a bug. For b) That's a jokosher bug, it shouldn't use gnlfilesource but singledecodebin or whatever else pitivi uses. This will fix this bug and a bunch of others too probably.
Created attachment 105282 [details] oggdemux level 5 log
The issue is not fixed with latest CVS stuff from today, neither for oggdemux nor mp3parse. The problem I'm having is not a) or b) is something different. The playback stops completely before the split, as described in title of the bug. I'm attaching the last part of a log with oggdemux stopping completely. This is with latest gstreamer, gst-plugins-{base,good,ugly}.
I'm doing the 0.10.17.2 pre-release with this bug still open. It needs resolving before the release itself (which is March 17th)
I think the consensus was to wait for the new Jokosher, or Gnolin, I can't remember.
Consesnus was to port Jokosher from using gnlfilesource to gnlsource + simpledecodebin and see if it really makes bug to disappear. This is done partly, as I have ran into serveral interesting problems. However, I need some assistance to finish it. I hope to deal with it during this working week.
Felipe, Peteris? Any news on this?
Hrmn, this bug is still open - any progress?
Probably not, I've asked in #jokosher but no answer yet.
This bug is gone with newest gst cvs and Jokosher svn, as we did convertion from gnlfilesource to gnlsource + simpledecodebin. Thanks people for suggestions.