Clock selection and slave hardware clock
Locked
Clock selection and slave hardware clock
 
|
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 _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Clock selection and slave hardware clock
|
|
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 <[hidden email]> 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 _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Clock selection and slave hardware clock
|
|
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 <[hidden email]> 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 <[hidden email]> 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 _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |