[gst-devel] a few questions: getting total length (in seconds) of a file

[Benjamin Otte]

Quoting james at teyandei.net:

> For the record I'm using 0.6.x from Debian unstable.
> 
Disclaimer:
I don't think there's many of us remembering the idiosyncrasies of that relies 
since we're all busy preparing the 0.8 release. Developers of applications are 
encouraged to use the current cvs HEAD branch or at least the 0.7 releases.

> Keeping things simple for the moment. It works great. My first question
> is, is a filesrc object tied to whatever you set for the 'location'
> property? It seems that if I want to open another file, I need to unref
> the old filesrc, remove it from the pipeline, create a new one, and then
> readd/relink it. This is what I'm doing now and it works fine but I just
> want to make sure I'm doing the "Right Thing" here.
> 
The correct solution is to change the state of the filesrc to NULL, then 
change the location, then set it back to PLAYING.

> Second question: I want to drive a seek bar. Right now I would just like
> to have it track the current position, not actually let me seek in the
> file. I know how to use GtkAdjustments etc so using them is no problem. I
> figured out how to get the current elapsed time from the stream as well.
> What I'm having problems with is getting the total length of the file. I'm
> doing this:
> 
> gst_element_query(<element>, GST_QUERY_TOTAL, GST_FORMAT_TIME, &value);
> 
> and getting a 'false' value from gst_element_query (failed). In place of
> <element> I have tried the filesrc, autoplugger and audiosink elements and
> get the same result every time. Which part of the pipeline do I need to
> query exactly to get the total length?
> 
You need to query the element you want to know the length from. Obviously you 
want to know the length of the audio that is output, so you should query the 
audiosink.
Keep in mind that some file formats do not allow querying the length in early 
stages of playback (or even before playback has started), because figuring out 
the length of files might require quite some processing of data.
This is the reason why GstPlay tries again some time later if the query fails.

> Last, would you guys consider gstreamer-play to be a robust enough plugin
> to base an application on, or is it just considered an example plugin and
> basis for gst-player? I have re-implemented a tiny subsection of it in my
> own code for learning purposes, but I'm afraid to use it in my application
> if it's really not meant for such purposes.
> 
First allow me to be picky with terminology: GstPlay is not a plugin, but a 
library. Plugins contain elements that can be added to your pipeline. GstPlay 
contains code that eases the use of GStreamer.
That being said, GstPlay is not just some testbed for gst-player, but it is 
used as a backend to the gstreamer port of Totem and as such is going to get 
big exposure. It is definitely supposed to be a robust implementation of a 
media player library.