Pipeline state and negotiated caps.

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

Pipeline state and negotiated caps.

AxelPhi
Hi everyone!

Since a few days I'm toying around with gstreamer. Got to say,
I'm in love with the concept and the amount of language bindings.
Good job!

And of course I ran into my first dead end while trying to do
a simple transcoding application.

The problem is, that I can't reliably retrieve negotiated
capabilities from pads.

Here's what I do, using the Java bindings:

I link a filesource and a decodebin element and connect
a class to its PAD_ADDED event (signal?).

When this event fires, I link a fakesink element to each
created pad and store the pads in a list.

Then I set the pipeline to PAUSE, try to wait for it to reach that
state and then use the list of pads to retrieve their negotiated
caps.

This works sometimes, especially if I delay the retrieval
some seconds after setting the pipeline to PAUSE.

My question is, is this the right way at all to retrieve
informations such as video resolution? I suppose the
reason that I sometimes don't get the negotiated caps
properly  is the fact that they are still not set then.
The video might be still prerolling, as I understand
that setting the state is a non-blocking function.

Thanks a lot in advance!

See ya,

Axel





------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pipeline state and negotiated caps.

Stefan Sauer
Axel Philipsenburg schrieb:

> Hi everyone!
>
> Since a few days I'm toying around with gstreamer. Got to say,
> I'm in love with the concept and the amount of language bindings.
> Good job!
>
> And of course I ran into my first dead end while trying to do
> a simple transcoding application.
>
> The problem is, that I can't reliably retrieve negotiated
> capabilities from pads.
>
> Here's what I do, using the Java bindings:
>
> I link a filesource and a decodebin element and connect
> a class to its PAD_ADDED event (signal?).
>
> When this event fires, I link a fakesink element to each
> created pad and store the pads in a list.
>
> Then I set the pipeline to PAUSE, try to wait for it to reach that
> state and then use the list of pads to retrieve their negotiated
> caps.

You can get the caps when the signal fires. No need to wait. Have a look at what
transmageddon does in python.

STefan

>
> This works sometimes, especially if I delay the retrieval
> some seconds after setting the pipeline to PAUSE.
>
> My question is, is this the right way at all to retrieve
> informations such as video resolution? I suppose the
> reason that I sometimes don't get the negotiated caps
> properly  is the fact that they are still not set then.
> The video might be still prerolling, as I understand
> that setting the state is a non-blocking function.
>
> Thanks a lot in advance!
>
> See ya,
>
> Axel
>
>
>
>
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel