rate change not very responsive

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

rate change not very responsive

arturo castro-2
Hi

I'm one of the developers of the openframeworks project:
http://openframeworks.cc , a framework for creative coding. Since now
we've been using some object oriented wrapper around FFMPEG as our video
backend in the linux version but it's being problematic and super slow
so i've decided to give gstreamer a try.

With the new version of appsink in base everything has gone more or less
smooth except for one little problem. When i try to change a video
playing speed from a gui control like a slider or just mapping that
property to the mouse position, the video stops playing while speed is
changing and only continues playing again when speed stops changing.

I'm using a pipeline like:

filesrc location=... ! decodebin ! ffmpegcolorspace ! appsink

also using signals in appsink to notify new buffers and polling the
pipeline for messages with:

while(gst_bus_have_pending(bus)){
   GstMessage* msg = gst_bus_pop(bus);
   ...

as i cannot get callbacks from the bus since i cannot run in the
gstreamer loop because our framework already has it's own.

I've tried with diferent seek flags but have more or less the same
result.

This is the code i'm using to change speed directly mapped to gui
control:

void ofVideoPlayer::setSpeed(speed)
    GstFormat format = GST_FORMAT_TIME;
    GstSeekFlags flags = (GstSeekFlags) (GST_SEEK_FLAG_FLUSH|GST_SEEK_FLAG_ACCURATE);

    if(!gst_element_seek(GST_ELEMENT(gstPipeline),speed, format,
                        flags,
                        GST_SEEK_TYPE_NONE,
                        0,
                        GST_SEEK_TYPE_NONE,
                        -1)) {
                        ofLog(OF_WARNING,"GStreamer: unable to seek");
   }
}


also attached is the full code for our videoPlayer class.

Is there anything i can do to make speed change more responsive, or is
this just a limitation of the current implementation of gstreamer?

thanks and keep the good work


//------------------------------------------
arturo castro

oF core developer
barcelona
       

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

ofVideoPlayerOnlyGst.cpp (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rate change not very responsive

Jan Schmidt-6
On Mon, 2009-01-19 at 14:48 +0100, arturo castro wrote:

> Hi
>
> I'm one of the developers of the openframeworks project:
> http://openframeworks.cc , a framework for creative coding. Since now
> we've been using some object oriented wrapper around FFMPEG as our video
> backend in the linux version but it's being problematic and super slow
> so i've decided to give gstreamer a try.
>
> With the new version of appsink in base everything has gone more or less
> smooth except for one little problem. When i try to change a video
> playing speed from a gui control like a slider or just mapping that
> property to the mouse position, the video stops playing while speed is
> changing and only continues playing again when speed stops changing.
>
> I'm using a pipeline like:
>
> filesrc location=... ! decodebin ! ffmpegcolorspace ! appsink
>
> also using signals in appsink to notify new buffers and polling the
> pipeline for messages with:
>
> while(gst_bus_have_pending(bus)){
>    GstMessage* msg = gst_bus_pop(bus);
>    ...
>
> as i cannot get callbacks from the bus since i cannot run in the
> gstreamer loop because our framework already has it's own.
>
> I've tried with diferent seek flags but have more or less the same
> result.
>
> This is the code i'm using to change speed directly mapped to gui
> control:
>
> void ofVideoPlayer::setSpeed(speed)
>     GstFormat format = GST_FORMAT_TIME;
>     GstSeekFlags flags = (GstSeekFlags) (GST_SEEK_FLAG_FLUSH|GST_SEEK_FLAG_ACCURATE);
>
>     if(!gst_element_seek(GST_ELEMENT(gstPipeline),speed, format,
> flags,
> GST_SEEK_TYPE_NONE,
> 0,
> GST_SEEK_TYPE_NONE,
> -1)) {
> ofLog(OF_WARNING,"GStreamer: unable to seek");
>    }
> }
>
>
> also attached is the full code for our videoPlayer class.
>
> Is there anything i can do to make speed change more responsive, or is
> this just a limitation of the current implementation of gstreamer?
>

How responsive it's going to be is a function of the pipeline mostly.
You might want to check out the 'scrubby' example in
gst-plugins-base/tests/examples/seek/scrubby.c - it does pretty much
what you're looking for.

There has been some discussion of how we might perform
rate-changes-that-don't-change-the-playback-direction more quickly, but
nothing has come of that yet.

J.

--
Jan Schmidt <[hidden email]>


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: rate change not very responsive

arturo castro-2
Hi Jan

thanks very much for your answer.

the thing is i've been trying the scrubby example and at least for me
it's super unresponsive. when trying to seek or change speed the app
freeze for some seconds. also tried that code in my app and the result
is more or less the same.

in my code I've managed to have a very responsive speed change (even
with negative speeds) by always seeking to the current position on speed
changes, don't know if this is very correct in gstreamer terms though :)

something like:

GstFormat format = GST_FORMAT_TIME;
GstSeekFlags flags = (GstSeekFlags) (GST_SEEK_FLAG_FLUSH |
GST_SEEK_FLAG_ACCURATE);
gint64 pos;

gst_element_set_state (gstPipeline, GST_STATE_PLAYING);
if(speed>0){
        gst_element_seek(GST_ELEMENT(gstPipeline),speed, format,
                                        flags,
                                        GST_SEEK_TYPE_SET,
                                        pos,
                                        GST_SEEK_TYPE_SET,
                                        -1))
}else{
        gst_element_seek(GST_ELEMENT(gstPipeline),speed, format,
                                        flags,
                                        GST_SEEK_TYPE_SET,
                                        0,
                                        GST_SEEK_TYPE_SET,
                                        pos))
}

i've also tried this code with the scrubby example, with same results,
no freezes and almost immediate response to the slider even for negative
speeds. I've attached a modified scrubby.c

thanks


El mar, 20-01-2009 a las 11:17 +0000, Jan Schmidt escribió:

> On Mon, 2009-01-19 at 14:48 +0100, arturo castro wrote:
> > Hi
> >
> > I'm one of the developers of the openframeworks project:
> > http://openframeworks.cc , a framework for creative coding. Since now
> > we've been using some object oriented wrapper around FFMPEG as our video
> > backend in the linux version but it's being problematic and super slow
> > so i've decided to give gstreamer a try.
> >
> > With the new version of appsink in base everything has gone more or less
> > smooth except for one little problem. When i try to change a video
> > playing speed from a gui control like a slider or just mapping that
> > property to the mouse position, the video stops playing while speed is
> > changing and only continues playing again when speed stops changing.
> >
> > I'm using a pipeline like:
> >
> > filesrc location=... ! decodebin ! ffmpegcolorspace ! appsink
> >
> > also using signals in appsink to notify new buffers and polling the
> > pipeline for messages with:
> >
> > while(gst_bus_have_pending(bus)){
> >    GstMessage* msg = gst_bus_pop(bus);
> >    ...
> >
> > as i cannot get callbacks from the bus since i cannot run in the
> > gstreamer loop because our framework already has it's own.
> >
> > I've tried with diferent seek flags but have more or less the same
> > result.
> >
> > This is the code i'm using to change speed directly mapped to gui
> > control:
> >
> > void ofVideoPlayer::setSpeed(speed)
> >     GstFormat format = GST_FORMAT_TIME;
> >     GstSeekFlags flags = (GstSeekFlags) (GST_SEEK_FLAG_FLUSH|GST_SEEK_FLAG_ACCURATE);
> >
> >     if(!gst_element_seek(GST_ELEMENT(gstPipeline),speed, format,
> > flags,
> > GST_SEEK_TYPE_NONE,
> > 0,
> > GST_SEEK_TYPE_NONE,
> > -1)) {
> > ofLog(OF_WARNING,"GStreamer: unable to seek");
> >    }
> > }
> >
> >
> > also attached is the full code for our videoPlayer class.
> >
> > Is there anything i can do to make speed change more responsive, or is
> > this just a limitation of the current implementation of gstreamer?
> >
>
> How responsive it's going to be is a function of the pipeline mostly.
> You might want to check out the 'scrubby' example in
> gst-plugins-base/tests/examples/seek/scrubby.c - it does pretty much
> what you're looking for.
>
> There has been some discussion of how we might perform
> rate-changes-that-don't-change-the-playback-direction more quickly, but
> nothing has come of that yet.
>
> J.
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

scrubby.c (14K) Download Attachment