#811 System clock does not resync to live video clock

open
None
7
2012-12-05
2012-07-05
Jack Jansen
No

If there is a live video feed and no audio feed then the system clock should resync to the video clock, similar to how it works for audio.

This requires prioritization of clocks (which we don't have yet) so the audio clock takes precendce, etc etc etc.

In addition, it requires the video renderer to sync the system clock. Unfortunately this also doesn't work. The attached patch tries to do this, but it makes the video (and system clock) slow down. I am not sure I understand, we will have to investigate some time. I think it may have to do with re-inventing timstamps in rtsp_datasource::run().

Discussion

  • Jack Jansen

    Jack Jansen - 2012-07-05

    Further experiments by Kees and Bo show that the problem does not occur when streaming from QTSS, only when streaming from VLC or gstreamer with RTSP.

    It could be that it is an ideosyncracy in the gstreamer rtsp server or so. That still makes it a bug in Ambulant (VLC can display the stream just fine), but it may lower the importance.

     
  • Kees Blom

    Kees Blom - 2012-08-20

    In particular, rtsp webcam streams cannot be played (show black screen) because all frames are judged 'too late' and thus dropped. This was 'fixed' by disabling the frame dropping algorithm in ffmpeg_video.cpp by commenting out line 676.

    Note that 'mplayer' has a command line option '-noframedrop'.

    A webcam rtsp server is available on the 'exp-kees-sdl2' branch in:
    sandbox/gst-rtsp-0.10.8/example/testwebcam.c (streams on linux with a webcam (/dev/video0) to localhost:8554/test).

     
  • Kees Blom

    Kees Blom - 2012-08-20
    • priority: 5 --> 8
    • assigned_to: nobody --> jackjansen
     
  • Jack Jansen

    Jack Jansen - 2012-12-05
    • priority: 8 --> 7
     

Log in to post a comment.