question about GstClock not set

[Julien Isorce]

Hi,

I attach to this mail a minimal test to provide a gstreamer behaviour that I do not understand.

Actually, I would like to know why the clock can be not set yet whereas some buffers are dispatched.
I mean I put an identity element between a videotestsrc and a fakesink,
and I am checking the clock availability in the identity handoff callback.

Why am I able to get raw video buffers from handoff callback whereas no clock is set on identity yet ?
Moreover in this case the timestamp buffer is valid, but I assume this timestamp was set by the internal clock.
I can understand that the internal clock was already there before playing,
and I can also understand that the internal clock is affected on elements only when going to playing state (or at least ready).
But I think the clock should be always available from a handoff callback, at least if the buffer timestamp is valid.

( to compile the test: gcc -Wall $(pkg-config --cflags --libs gstreamer-0.10) main.c -o main )

(output:

identity has clock: 0, timestamp is valid: 1
pipeline is now playing
new clock set from: pipeline
identity has clock: 1, timestamp is valid: 1
identity has clock: 1, timestamp is valid: 1
identity has clock: 1, timestamp is valid: 1
identity has clock: 1, timestamp is valid: 1
identity has clock: 1, timestamp is valid: 1
identity has clock: 1, timestamp is valid: 1
identity has clock: 1, timestamp is valid: 1
identity has clock: 1, timestamp is valid: 1
identity has clock: 1, timestamp is valid: 1
End of stream

)

Sincerely

Julien

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wim Taymans]

On Tue, 2009-08-25 at 16:40 +0200, Julien Isorce wrote:

> Hi,
>
> I attach to this mail a minimal test to provide a gstreamer behaviour
> that I do not understand.
>
> Actually, I would like to know why the clock can be not set yet
> whereas some buffers are dispatched.
> I mean I put an identity element between a videotestsrc and a
> fakesink,
> and I am checking the clock availability in the identity handoff
> callback.
>
> Why am I able to get raw video buffers from handoff callback whereas
> no clock is set on identity yet ?
> Moreover in this case the timestamp buffer is valid, but I assume this
> timestamp was set by the internal clock.
> I can understand that the internal clock was already there before
> playing,
> and I can also understand that the internal clock is affected on
> elements only when going to playing state (or at least ready).
> But I think the clock should be always available from a handoff
> callback, at least if the buffer timestamp is valid.
>

The first buffer is part of preroll in PAUSED. It is only after all
sinks receive a buffer that a clock is selected and the pipeline is set
to PLAYING.

Wim

> ( to compile the test: gcc -Wall $(pkg-config --cflags --libs
> gstreamer-0.10) main.c -o main )
>
> (output:
>
> identity has clock: 0, timestamp is valid: 1
> pipeline is now playing
> new clock set from: pipeline
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> End of stream
>
> )
>
> Sincerely
>
> Julien
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Julien Isorce]

2009/8/25 Wim Taymans <[hidden email]>

On Tue, 2009-08-25 at 16:40 +0200, Julien Isorce wrote:
> Hi,
>
> I attach to this mail a minimal test to provide a gstreamer behaviour
> that I do not understand.
>
> Actually, I would like to know why the clock can be not set yet
> whereas some buffers are dispatched.
> I mean I put an identity element between a videotestsrc and a
> fakesink,
> and I am checking the clock availability in the identity handoff
> callback.
>
> Why am I able to get raw video buffers from handoff callback whereas
> no clock is set on identity yet ?
> Moreover in this case the timestamp buffer is valid, but I assume this
> timestamp was set by the internal clock.
> I can understand that the internal clock was already there before
> playing,
> and I can also understand that the internal clock is affected on
> elements only when going to playing state (or at least ready).
> But I think the clock should be always available from a handoff
> callback, at least if the buffer timestamp is valid.
>

The first buffer is part of preroll in PAUSED. It is only after all
sinks receive a buffer that a clock is selected and the pipeline is set
to PLAYING.

ok thx for the explanation.

In a more complex pipeline, it can take some times before all sinks receive a buffer.
And so an element can receive a lot of buffers
before all elements received a buffer ?
I mean a lot of handoff calls with no access to the clock inside the callback.
It could explain the behavior I have there in a use case.

Anyway, I assume i should consider the buffers only after that playing state is reached.

Sincerely

Julien
 

Wim

> ( to compile the test: gcc -Wall $(pkg-config --cflags --libs
> gstreamer-0.10) main.c -o main )
>
> (output:
>
> identity has clock: 0, timestamp is valid: 1
> pipeline is now playing
> new clock set from: pipeline
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> identity has clock: 1, timestamp is valid: 1
> End of stream
>
> )
>
> Sincerely
>
> Julien

> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel