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 686153 - playbin: Gapless using about-to-finish appears broken
playbin: Gapless using about-to-finish appears broken
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.x
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-10-15 13:58 UTC by Morten N
Modified: 2013-08-16 10:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Shell output, playbin gapless test (6.28 KB, text/plain)
2012-10-15 13:58 UTC, Morten N
Details

Description Morten N 2012-10-15 13:58:19 UTC
Created attachment 226467 [details]
Shell output, playbin gapless test

So, appears that playbin in GStreamer1.0 never resets the seek when switching from one file to the next. Result: Playing two or more files, each longer than the other, the first file is played normally. Then, gaplessly, the next file is played from the timestamp that was used on the original file. And so on.


Attached: Shell output from the following:

1. Compile a test for about-to-finish/gapless playback using GStreamer0.10.
2. Do gapless playback, working.
3. Repeat for GStreamer1.0.
4. Do gapless playback, confirm that the audio output never seeks to the beginning of the next file.
5. Print GStreamer versions used on the system (Debian)
Comment 1 Morten N 2012-10-29 09:25:52 UTC
Detected in GStreamer 1.0.1. Still exists in GStreamer 1.0.2 – at least for that collection of wave files, found in the libreoffice-common package on a Debian machine.
Comment 2 Florian Will 2013-05-10 21:53:56 UTC
I'm observing the same problem with an URI like http://[....]/12345.dat . At the same time, http://[....]/12346.mp3 works fine. So *.mp3 works, *.dat fails.

I'm not sure what a *.dat file is. It's actually an *.ogg file served via UPnP by minidlna. Minidlna apparently serves mp3 files via mp3 URIs, but ogg files are served as *.dat. This works fine with playbin, the only issue I noticed is described by Morten N: *.dat-Songs do not start from the beginning.

I've observed that they don't always start at the timestamp where the last song ended either. Instead it seems like they start at a timestamp that is given by the time that has passed since the last seek. Or possibly something similar.

Example:
* Start listening to *.dat URI with 58 seconds duration
* Seek to 0:38 ASAP
* Wait for song to end
* Next song will start playing at 0:20

If you skip the seeking step, the next song will start playing at 0:58.


I'm using GStreamer 1.0.6 according to Gst.version_string().
Comment 3 Henner Z. 2013-05-16 01:51:28 UTC
This looks similar to bug 698750

Full example to reproduce, including sample *.wav and *.ogg files, in:

  https://github.com/hzeller/gstreamer-gapless-test

From the:
https://github.com/hzeller/gstreamer-gapless-test/blob/master/README.md

Does _not_ work:
./test-loop-1.0 http://localhost:9999/12.ogg http://localhost:9999/1234567.ogg
./test-loop-1.0 file://`pwd`/sounds/12.wav file://`pwd`/sounds/1234567.wav

Does work:
./test-loop-1.0 http://localhost:9999/12.wav http://localhost:9999/1234567.wav
./test-loop-1.0 file://`pwd`/sounds/12.ogg file://`pwd`/sounds/1234567.ogg
Comment 4 Sebastian Dröge (slomo) 2013-08-16 10:28:45 UTC
The original bug reported here does not exist anymore in latest git master at least, the HTTP bug is #698750.