Clock selection and slave hardware clock

[Arnaud Vrac]

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