Advanced search

On other websites (9175)

• How can I quantitatively measure gstreamer H264 latency between source and display?

  10 August 2018, by KevinM

  I have a project where we are using gstreamer , x264, etc, to multicast a video stream over a local network to multiple receivers (dedicated computers attached to monitors). We’re using gstreamer on both the video source (camera) systems and the display monitors.

  We’re using RTP, payload 96, and libx264 to encode the video stream (no audio).

  But now I need to quantify the latency between (as close as possible to) frame acquisition and display.

  Does anyone have suggestions that use the existing software?

  Ideally I’d like to be able to run the testing software for a few hours to generate enough statistics to quantify the system. Meaning that I can’t do one-off tests like point the source camera at the receiving display monitor displaying a high resolution and manually calculate the difference...

  I do realise that using a pure software-only solution, I will not be able to quantify the video acquisition delay (i.e. CCD to framebuffer).

  I can arrange that the system clocks on the source and display systems are synchronised to a high accuracy (using PTP), so I will be able to trust the system clocks (else I will use some software to track the difference between the system clocks and remove this from the test results).

  In case it helps, the project applications are written in C++, so I can use C event callbacks, if they’re available, to consider embedding system time in a custom header (e.g. frame xyz, encoded at time TTT - and use the same information on the receiver to calculate a difference).

• How can I quantitatively measure gstreamer H264 latency between source and display?

  16 December 2014, by KevinM

  I have a project where we are using gstreamer , x264, etc, to multicast a video stream over a local network to multiple receivers (dedicated computers attached to monitors). We’re using gstreamer on both the video source (camera) systems and the display monitors.

  We’re using RTP, payload 96, and libx264 to encode the video stream (no audio).

  But now I need to quantify the latency between (as close as possible to) frame acquisition and display.

  Does anyone have suggestions that use the existing software?

  Ideally I’d like to be able to run the testing software for a few hours to generate enough statistics to quantify the system. Meaning that I can’t do one-off tests like point the source camera at the receiving display monitor displaying a high resolution and manually calculate the difference...

  I do realise that using a pure software-only solution, I will not be able to quantify the video acquisition delay (i.e. CCD to framebuffer).

  I can arrange that the system clocks on the source and display systems are synchronised to a high accuracy (using PTP), so I will be able to trust the system clocks (else I will use some software to track the difference between the system clocks and remove this from the test results).

  In case it helps, the project applications are written in C++, so I can use C event callbacks, if they’re available, to consider embedding system time in a custom header (e.g. frame xyz, encoded at time TTT - and use the same information on the receiver to calculate a difference).

• x86: Serialize rdtsc in read_time()

  8 July 2015, by Henrik Gramner

  x86: Serialize rdtsc in read_time()
  Improves the accuracy of measurements, especially in short sections.
  To quote the Intel 64 and IA-32 Architectures Software Developer’s Manual:
  
  "The RDTSC instruction is not a serializing instruction. It does not necessarily
  
  wait until all previous instructions have been executed before reading the counter.
  
  Similarly, subsequent instructions may begin execution before the read operation
  
  is performed. If software requires RDTSC to be executed only after all previous
  
  instructions have completed locally, it can either use RDTSCP (if the processor
  
  supports that instruction) or execute the sequence LFENCE;RDTSC."
  SSE2 is a requirement for lfence so only use it on SSE2-capable systems.
  
  Prefer lfence;rdtsc over rdtscp since rdtscp is supported on fewer systems.
  Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
  

  • [DBH] libavutil/x86/timer.h