[Bug 666312] New: subparse fails to play subtitle after executing seek() on video

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Dec 15 10:52:21 PST 2011


https://bugzilla.gnome.org/show_bug.cgi?id=666312
  GStreamer | gst-plugins-base | 0.10.35

           Summary: subparse fails to play subtitle after executing seek()
                    on video
    Classification: Platform
           Product: GStreamer
           Version: 0.10.35
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: maxphil at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=203599)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=203599)
Subparse debug output.

This issue occurs with gstreamer 0.10.35 and subparse 0.10.35.

After playing the video and veryfing that audio/video/subtitles are good,
sending a seek() event to the pipeline to change the position of the video
makes subparse fail to display the subtitle, while audio and video performs as
expected. This behavior seems to be completely random, sometimes the subtitle
is displayed after a seek() and sometimes it doesn't.

This issue was initially reported on gstreamer-devel list, there's some extra
info/logs in that thread that might be helpful:
http://lists.freedesktop.org/archives/gstreamer-devel/2011-December/034306.html

I also noticed that the same problem happens when I try to change the playback
rate. I'm using QtGstreamer and this is the code that changes the playback
rate:

    QGst::PositionQueryPtr query =
QGst::PositionQuery::create(QGst::FormatTime);
    if (!_pipeline->query(query))
    {
        qDebug() "Aborting request!";
        return;
    }

    QGst::SeekEventPtr evt = QGst::SeekEvent::create(_playback_rate,
                                                     QGst::FormatTime,
                                                     QGst::SeekFlagFlush,
                                                     QGst::SeekTypeNone,
                                                     query->position(),
                                                     QGst::SeekTypeNone,
                                                     QGst::ClockTime::None);

    _pipeline->sendEvent(evt);


and the following instructions are used for seek():

    QGst::SeekEventPtr evt = QGst::SeekEvent::create(_playback_rate,
                                                     QGst::FormatTime,
                                                     QGst::SeekFlagFlush,
                                                     QGst::SeekTypeSet,
                                                    
QGst::ClockTime::fromTime(QTime().addMSecs(pos)),
                                                     QGst::SeekTypeNone,
                                                     QGst::ClockTime::None);

    _pipeline->sendEvent(evt);
    _pipeline->setState(QGst::StatePlaying);


I thought about writing a minimal application to reproduce this behavior but I
figured it would be much easier to test this issue if I found a way to
reproduce it in gst-launch. The difficulty was finding a native way to set the
video to start at a specific position. I finally found out about gnonlin, so
the command below uses the element gnlfilesource to do exactly that:

gst-launch filesrc location=/data/videos/tbbt_s05e01.srt ! subparse ! bot.
gnlfilesource location=file:///data/videos/tbbt_s05e01.avi
duration=10000000000000 media-start=100000000000 ! ffmpegcolorspace !
textoverlay name=bot valignment=bottom  ! xvimagesink

When the property media-start is set to 0, the video starts playing from the
beginning of the file and the subtitle is OK. But if media-start is set to an
arbitrary position, like the middle of the file, than the subtitle is not
showed anymore.

The fact is that the log (attached) clearly shows that after a seek() operation
subparse starts reading the file from the beginning again, to search for the
desired timestamp, but after a few seconds it simply gives up searching and
there's no indication of why.

-- 
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