[gstreamer-bugs] [Bug 612717] New: Experiencing gaps in unrelated playbacks when starting a new playback, or even using playbin2's "gapless" playback with about_to_finish

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Mar 12 08:52:44 PST 2010


https://bugzilla.gnome.org/show_bug.cgi?id=612717
  GStreamer | don't know | 0.10.28

           Summary: Experiencing gaps in unrelated playbacks when starting
                    a new playback, or even using playbin2's "gapless"
                    playback with about_to_finish
    Classification: Desktop
           Product: GStreamer
           Version: 0.10.28
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: don't know
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: llyly at cc.hut.fi
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Easiest way to reproduce would be to

1. Have one video playing with GStreamer, using e.g. playbin or playbin2.
2. Set an unrelated (audio or video) playbin2 (or playbin1) to playing state
from another state, whether it's been played back previously, stopped in
between, or none of the previous.

The video will momentarily stop. With audio, it's a short gap, but in case of
the new file being played back being huge, it may be longer.

Otherwise the videos and audio files play nicely together without disturbing
eachother. The gap might be related to the creation of a new thread instead of
just the switch to "playing" state, which I deduce from the following:

I tried to have a video playing (without sound) and then starting so called
"gapless" playback of audio files with playbin2, so that the about_to_finish
signal would launch a new URI.

With 0.10.28 there was no state switch, but there *WAS* a visible gap induced
in the unrelated video playback.

I don't know if there is a gap also in the audio, because the first file
happened to be completely silent.

The behavior is not related to the whole program being locked in some kind of
I/O operation, because otherwise the program doesn't experience any delays -
everything happens in gstreamer's own threads. Also I would like to note that
it doesn't matter how many videos or similar you have playing. They *all* will
experience a gap whenever a new playback is started.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list