Clock selection and slave hardware clock

[Arnaud Vrac]

Ok I can confirm that in gstreamer 0.11 the system clock is still used
instead of the hardware renderer clock.

On Wed, Jul 18, 2012 at 4:10 PM, Arnaud Vrac <rawoul at gmail.com> wrote:
> Please also note that the tests were run on gstreamer 0.10.32, I'm
> trying to update my elements to 0.11 to see if it works better now
> (the clock class has not changed so issue 1 is still valid at least).
>
> On Wed, Jul 18, 2012 at 3:43 PM, Arnaud Vrac <rawoul at gmail.com> wrote:
>> Hi all,
>>
>> I have two problems related to the clock in my pipeline which includes
>> hardware accelerated elements:
>>
>> 1/ I cannot slave the clock provided by the hardware renderer element
>> to the system clock, because of GstClock limitations. The clock
>> adjustment algorithm only applies an offset to the time returned by
>> gst_clock_get_time, so this offset is effective when the hardware
>> driver uses its clock directly. Instead it would be nice if GstClock
>> could adjust the hardware clock frequency directly to match the master
>> clock.
>>
>> 2/ When using playbin and playing an RTSP stream, the system clock
>> provided by the rtpbin is selected instead of the clock provided by
>> the hardware renderer. This cannot work because the hardware clock
>> cannot be slaved to the system clock. The hardware renderer explicitly
>> refuses the system clock but it is still used anyway.
>>
>> This works:
>> gst-launch rtspsrc location=rtsp://... ! rtpdepay ! hwaudiosink
>>
>> This fails:
>> gst-launch playbin2 uri=rtsp://...
>>
>> In the first case the hwaudiosink already is added to the pipeline
>> when the clock selection algorithm is run, so it is the one that is
>> selected. When using playbin the pipeline is already playing when the
>> audio sink is added, and the clock is not selected again when the
>> audio sink refuses the system clock.
>>
>> Please tell me if it is possible to fix this and how.
>>
>> Thanks !
>>
>> --
>> Arnaud Vrac
>
>
>
> --
> Arnaud Vrac



-- 
Arnaud Vrac