current-level-time property of GstQueue plugin

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

current-level-time property of GstQueue plugin

Vikram

Hi Folks,

I am working on a bin which has a ‘souphttpsrc’ and ‘queue’ as children. I am

connecting this bin in the following pipeline to play an avi file with xvid encoding.

 

gst-launch httpplugin location=http://…/sample.avi ! avidemux name=avd avd.video_00 ! xviddec ! ffmpegcolorspace ! ximagesink

 

The pipeline works fine and the application shows the video.

 

Now I want to know the amount of data present in the queue at any point during playback in terms of ns. I checked the queue properties and found that there is a property current-level-time’ which should give current amount of data in the queue (in ns). But it gives me some unexpected value (18446744073709551615)

 

But if try to get ‘current-level-bytes’ property value, I am able to get values properly.

 

Now my query is

Is there some property that I need to set for the queue to give correct value in terms of time?

 

 Regards,
Vikram 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: current-level-time property of GstQueue plugin

saepia
I suggest capturing bitrate from decoder's tags and using them and value of bytes in the queue to calculate that.

m.

2012/7/24 Vijay Vikram <[hidden email]>

Hi Folks,

I am working on a bin which has a ‘souphttpsrc’ and ‘queue’ as children. I am

connecting this bin in the following pipeline to play an avi file with xvid encoding.

 

gst-launch httpplugin location=http://…/sample.avi ! avidemux name=avd avd.video_00 ! xviddec ! ffmpegcolorspace ! ximagesink

 

The pipeline works fine and the application shows the video.

 

Now I want to know the amount of data present in the queue at any point during playback in terms of ns. I checked the queue properties and found that there is a property current-level-time’ which should give current amount of data in the queue (in ns). But it gives me some unexpected value (18446744073709551615)

 

But if try to get ‘current-level-bytes’ property value, I am able to get values properly.

 

Now my query is

Is there some property that I need to set for the queue to give correct value in terms of time?

 

 Regards,
Vikram 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: current-level-time property of GstQueue plugin

Vikram
Hi Marcin,
First thanks for your response.
I can understand your point and it would be valid when playing media in a constant bit rate channel and in the follwing pipeline too its quite valid.
 
But if we think in the perspective of adaptive streaming where the bit rate might vary(something like DASH), it would become too complex to handle. First of all data is segmented and we have multiple copies of same data with multiple bit rates. The decoder at any time during playback time will just give the segment being played curently.
 
In this situation, what can be the best way to get the current amount of data buffered?
 
Regards,
Vikram

On Tue, Jul 24, 2012 at 8:35 PM, [hidden email] <[hidden email]> wrote:
I suggest capturing bitrate from decoder's tags and using them and value of bytes in the queue to calculate that.

m.

2012/7/24 Vijay Vikram <[hidden email]>

Hi Folks,

I am working on a bin which has a ‘souphttpsrc’ and ‘queue’ as children. I am

connecting this bin in the following pipeline to play an avi file with xvid encoding.

 

gst-launch httpplugin location=http://…/sample.avi ! avidemux name=avd avd.video_00 ! xviddec ! ffmpegcolorspace ! ximagesink

 

The pipeline works fine and the application shows the video.

 

Now I want to know the amount of data present in the queue at any point during playback in terms of ns. I checked the queue properties and found that there is a property current-level-time’ which should give current amount of data in the queue (in ns). But it gives me some unexpected value (18446744073709551615)

 

But if try to get ‘current-level-bytes’ property value, I am able to get values properly.

 

Now my query is

Is there some property that I need to set for the queue to give correct value in terms of time?

 

 Regards,
Vikram 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: current-level-time property of GstQueue plugin

saepia
Hi,

for instance, if I open variable bitrate MP3 file and pass it through
decodebin2, I receive a lot of "bitrate" tags, every time bitrate
changes, so it's no problem to handle variable bitrate - it just needs
a rather simple algorithm.

I see no problem in the fact that decoder will give you info about
currently playing part - that should be the most important to you. But
if for some reason you still want to get such information about all
segments and copies - just create a few other pipelines with fakesinks
and run them in parallel.

m.



2012/7/25 Vijay Vikram <[hidden email]>:

> Hi Marcin,
> First thanks for your response.
> I can understand your point and it would be valid when playing media in a
> constant bit rate channel and in the follwing pipeline too its quite valid.
>
> But if we think in the perspective of adaptive streaming where the bit rate
> might vary(something like DASH), it would become too complex to handle.
> First of all data is segmented and we have multiple copies of same data with
> multiple bit rates. The decoder at any time during playback time will just
> give the segment being played curently.
>
> In this situation, what can be the best way to get the current amount of
> data buffered?
>
> Regards,
> Vikram
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel