Recherche avancée

Sur d’autres sites (8073)

• avformat/matroskaenc : Don't implicitly mark WebVTT in WebM as English

  18 janvier 2020, par Andreas Rheinhardt

  avformat/matroskaenc : Don't implicitly mark WebVTT in WebM as English
  Writing the language of WebVTT in WebM proceeded differently than the
  
  language of all other tracks : In case no language was given, it does not
  
  write anything instead of "und" (for undefined). Because the default
  
  value of the Language element in WebM (that inherited it from Matroska)
  
  is "eng" (for English), any such track will actually be flagged as
  
  English.
  Doing it this way goes back to commit 509642b4 (the commit adding
  
  support for WebVTT) and no reason for this has been given in the commit
  
  message or in the discussion about this patch on the mailing list ; the
  
  best I can think of is this : the WebM wiki contains "The srclang attribute
  
  is stored as the Language sub-element." Someone unfamiliar with default
  
  values in Matroska/WebM could interpret this as meaning that no Language
  
  element should be written if the language is unknown. And this is wrong
  
  and this commit changes it.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c

• 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).

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

  16 décembre 2014, 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).