Recherche avancée

Sur d’autres sites (12384)

• configure : speed up print_enabled_components()

  30 juillet 2018, par Avi Halachmi (:avih)

  configure : speed up print_enabled_components()
  x4 - x10 faster.
  Inside print_enabled components, the filter_list case invokes sed
  
  about 350 times to parse the same source file and extract different
  
  info for each arg. This is never instant, and on systems where fork is
  
  slow (notably MSYS2/Cygwin on windows) it takes many seconds.
  Change it to use sed once on the source file and set env vars with the
  
  parse results, then use these results inside the loop.
  Additionally, the cases of indev_list and outdev_list are very
  
  infrequent, but nevertheless they're faster, and arguably cleaner, with
  
  shell parameter substitutions than with command substitutions.
  Tested-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Tested-by : Helmut K. C. Tessarek <tessarek@evermeet.cx>
  
  Tested-by : Dave Yeo <daveryeo@telus.net>
  
  Tested-by : Reino Wijnsma <rwijnsma@xs4all.nl>
  
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] configure

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

  10 août 2018, par 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).

• libavutil/encryption_info : Allow multiple init info.

  23 avril 2018, par Jacob Trimble

  libavutil/encryption_info : Allow multiple init info.
  It is possible for there to be multiple encryption init info structure.
  
  For example, to support multiple key systems or in key rotation.  This
  
  changes the AVEncryptionInitInfo struct to be a linked list so there
  
  can be multiple structs without breaking ABI.
  Signed-off-by : Jacob Trimble <modmaker@google.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavutil/encryption_info.c
  • [DH] libavutil/encryption_info.h