repeated caps renegotiation

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

repeated caps renegotiation

Stefan Sauer
hi,

I have some bigger songs in buzztard that take ages to preroll. They
also have lots of caps stuff top in the oprofile output:
11953    12.2453  g_type_is_a
10067    10.3132  gst_value_get_compare_func
7275      7.4529  gst_value_subtract
4410      4.5178  gst_value_init_and_copy
3446      3.5303  gst_value_intersect
...

If I run it with
GST_DEBUG="*:2,GST_CAPS*:4,GST_PAD*:4"
and then grep for "caps changed from" I get lots of
a) NULL to xxx changes
b) xxx to xxx changes (same caps content but different instance)

Now I am wondering why e.g. tee uses gst_pad_alloc_buffer() and not
gst_pad_alloc_buffer_and_set_caps(). The first causes the repeated
renegotiation, as the caps of the pad are NULL and are not being set
(case a)). Or does it indicate a problem in the first place that tee.src
has NULL caps?

Regarding case b), I haven't understood yet, why the same caps are set
several times.


Stefan


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeated caps renegotiation

Stefan Sauer
I am still fighting with this. Some more info below

Stefan Kost schrieb:

> hi,
>
> I have some bigger songs in buzztard that take ages to preroll. They
> also have lots of caps stuff top in the oprofile output:
> 11953    12.2453  g_type_is_a
> 10067    10.3132  gst_value_get_compare_func
> 7275      7.4529  gst_value_subtract
> 4410      4.5178  gst_value_init_and_copy
> 3446      3.5303  gst_value_intersect
> ...
>
> If I run it with
> GST_DEBUG="*:2,GST_CAPS*:4,GST_PAD*:4"
> and then grep for "caps changed from" I get lots of
> a) NULL to xxx changes
> b) xxx to xxx changes (same caps content but different instance)
>
> Now I am wondering why e.g. tee uses gst_pad_alloc_buffer() and not
> gst_pad_alloc_buffer_and_set_caps(). The first causes the repeated
> renegotiation, as the caps of the pad are NULL and are not being set
> (case a)). Or does it indicate a problem in the first place that tee.src
> has NULL caps?
>
> Regarding case b), I haven't understood yet, why the same caps are set
> several times.

I tested the negotiation stuff with older gstreamer releases, it seems to be not
a regression. its just slow and the test cases that I can play are getting more
complex.

now one thing I am wondering is this:
0:00:16.066445699 13950  0x80c6008 INFO               bt-core
song.c:711:bt_song_play: prepare playback
0:00:18.528381148 13950  0x80c6008 INFO               bt-core
song.c:726:bt_song_play: ->PAUSED needs async wait
0:00:18.529629060 13950  0x80c6008 INFO               bt-core
song.c:459:on_song_state_changed: state change on the bin: NULL -> READY
0:00:20.468663845 13950  0x80c6008 INFO               bt-core
song.c:459:on_song_state_changed: state change on the bin: READY -> PAUSED
0:00:20.478722067 13950  0x80c6008 INFO               bt-core
song.c:482:on_song_state_changed: ->PLAYING needs async wait
0:00:20.478836341 13950  0x80c6008 INFO               bt-core
song.c:459:on_song_state_changed: state change on the bin: PAUSED -> PAUSED
0:00:20.492614585 13950  0x80c6008 INFO               bt-core
song.c:459:on_song_state_changed: state change on the bin: PAUSED -> PAUSED
0:00:20.499397583 13950  0x80c6008 INFO               bt-core
song.c:459:on_song_state_changed: state change on the bin: PAUSED -> PLAYING
0:00:20.499442878 13950  0x80c6008 INFO               bt-core
song.c:489:on_song_state_changed: playback started

why do I get state-changed messages like : PAUSED -> PAUSED and why twice?

Stefan

>
>
> Stefan
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel