[gst-devel] When to do initial seek; segment seek problems

[Артём Попов]

Okay, I'm going to file the bugs myself.
By the way, I found a solution for starting segment playback as soon
as possible:
Seek just as soon as a message "GST_MESSAGE_NEW_CLOCK" arises in the bus :)
--Artem

27.03.06, Zaheer Merali<zaheermerali at gmail.com> написал(а):
> You dont need special access to file bugs.  Just sign up for a
> bugzilla account at http://bugzilla.gnome.org
>
> There's a link on the front page:
>
> don't have an account yet?
> register today!
>
> and it will create you an account so you can file bugs.
>
> Zaheer
>
> On 3/27/06, Артём Попов <artfwo at gmail.com> wrote:
> > Hi guys!
> > I've been trying to put together a small gstreamer app and ran into 2 problems:
> > (using gst-python, all libs and plugins from latest 0.10 tarballs)
> >
> > 1. I want to play a small chunk of a media file using playbin.
> > However, when I call the seek routine immediately after starting the
> > pipeline, element_seek returns TRUE but no seeking is done:
> >
> >         playbin.set_state (gst.STATE_PLAYING)
> >         playbin.seek (1.0, gst.FORMAT_TIME, gst.SEEK_FLAG_ACCURATE |
> > gst.SEEK_FLAG_FLUSH | gst.SEEK_FLAG_SEGMENT, gst.SEEK_TYPE_SET, 25 *
> > gst.SECOND, gst.SEEK_TYPE_SET, 35 * gst.SECOND)
> >
> > I'm calling seek too early here... So I guess that I should call seek
> > right immediately after some event has happened: a handoff,
> > notify_caps or something like that, right? I.e. when the pipeline
> > knows more of its media stream? How could I do that??
> >
> > 2. I wrote a little python script to test loop-with-segment-seek
> > behaviour (attached). It shows rather weird behaviour with any codec,
> > that I tried to test, except WAV. I shall describe the behaviour
> > below, because I'm almost sure there're bugs in the appropriate
> > plugins:
> >
> > * WAV:
> > Works okay, loops seamlessly, even with SEEK_FLAG_ACCURATE.
> >
> > * Ogg Vorbis:
> > Starts to loop, but shortly after that (~1/2 of supposed loop) sound
> > goes off and I see huge CPU load in the System Monitor Applet.
> > When time comes for the loop to start over, it starts over ok with
> > sound, then again sound goes off and I see huge CPU load again...
> >
> > * MP3 (cbr & vbr):
> > The segment starts much earlier than supposed to. Lasts also much
> > shorter than supposed to.
> > Then the playbin spawns lots of SEGMENT_DONE messages one immediately
> > after another, playback position advances far beyond stream duration
> > to infinity, no sound at all.
> >
> > * FLAC:
> > Sends EOS message instead of SEGMENT_DONE, although there's
> > FLAG_SEGMENT set during seek. This is surely a bug. Requires
> > SEEK_FLAG_FLUSH when restarting loop after that, which I think
> > controverses with this:
> > http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/part-seeking.txt?view=markup
> >
> > * Fluendo mp3 plugin from SVN:
> > I think this one does not know anything about segments. Emits neither
> > EOS nor SEGMENT_DONE upon completion and continues to play happily
> > beyond segment-end-point :(
> >
> > As, I already said, WAV works perfectly, so there're probably bugs in
> > the other plugins. Could anyone with a bugzilla access file the bugs
> > against these problems?
> >
> > Then again, maybe I'm doing something wrong, so I've attached the test
> > program for interested people to try out. Change URI and START/STOP
> > constants in the beginning of the file to test different codecs. The
> > script plays file for 5 seconds, then seeks to the specified position,
> > continuously printing current playback position.
> >
> > Thanks in advance for any hints on my problem!
> > --Artem
> >
> >
> >
>