Recherche avancée

Sur d’autres sites (9108)

• libavcodec : add AV_HWACCEL_ALLOW_HIGH_DEPTH flag

  19 décembre 2014, par Rémi Denis-Courmont

  libavcodec : add AV_HWACCEL_ALLOW_HIGH_DEPTH flag
  This can be used by the application to signal its ability to cope with
  
  video surface of types other than 8-bits YUV 4:2:0.
  Signed-off-by : Rémi Denis-Courmont <remi@remlab.net>
  
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DBH] doc/APIchanges
  • [DBH] libavcodec/avcodec.h
  • [DBH] libavcodec/version.h

• avformat/mxfenc : set/force channelcount in MXF D-10

  25 juin 2014, par Gaullier Nicolas

  avformat/mxfenc : set/force channelcount in MXF D-10
  There are interoperability issues with D-10 related to the channelcount property in the generic sound essence descriptor.
  On one side, SMPTE 386M requires channel count to be 4 or 8, other values being prohibited.
  
  The most widespread value is 8, which seems straightforward as it is the actual size of the allocated structure/disk space.
  
  At the end, it appears that some vendors or workflows do require this descriptor to be 8, and otherwise just "fail".
  On the other side, at least AVID and ffmpeg do write/set the channel count to the exact number of channels really "used",
  
  usually 2 or 4, or any other value. And on the decoding side, ffmpeg (for example) make use of the channel count for probing
  
  and only expose this limited number of audio streams
  
  (which make sense but has strong impact on ffmpeg command line usage, output, and downstream workflow).
  At the end, I find it pretty usefull to simply give ffmpeg the ability to force/set the channel count to any value the user wants.
  
  (there are turnaround using complex filters, pans, amerge etc., but it is quite boring and requires the command line to be adapted to the input file properties)
  Reviewed-by : Matthieu Bouron <matthieu.bouron@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavformat/mxfenc.c

• h264 via WebRTC latency issue

  18 septembre 2024, par Lucas

  I am trying to send a video stream encoded with h264 (hardware accelerated with nvidia encoder) via WebRTC for low latency display on a browser.

  


  More precisely, I have a thread that encodes an opengl framebuffer at a fixed frame rate, the resulting AVPacket's data (I encode using ffmpeg's C api) is then forwarded via WebRTC to the client (using aiortc)

  


  The problem is that I observe significant delays, that seem to depend on the frame rate I use.
For example, running it locally, I get around 160ms delay when running at 30fps, and around 30ms when encoding at 90fps.

  


  The delay here is the measured time to encode + transmit + decode, and I have the strong impression that the issue happen when presenting the video frame, like the browser is not immediately presenting the frame... (encoding is fast, I would expect the transmission to be also rather fast on a local setup, and decoding seems to be fine as well, as reported by the RTP stats in the browser).

  


  I tried to play with RTP timestamps, but that did not change anything, the only variable that seems to impact the latency is the encoding thread 'frequency'.

  


  Any idea on what could be creating this latency ? Am I missing a parameter ?

  


  Also, here are the codec options I use : (they do not influence the latency that much from what I experimented)

  


  profile = high
preset = llhq  # low latency, high quality
tune = zerolatency
zerolatency = 1
g = 2 * FRAME_PER_SECOND  # key frame every 2s
strict-gop = 1


  


  UPDATE

  


  I have the impression that the jitter buffer on Chrome's side is kind of preventing the rtp packets to be decoded immediately, is that possible ?

  


  UPDATE 2

  


  

  • Using RTP playout-delay header extension slightly reduced the latency.

  


  • Setting playoudDelayHint in browser also seemed to help a bit

  


  


  UPDATE 3

  


  After further investigations, I came to the conclusion that it was not possible to get a lower latency by going through the standard webrtc for video streams, as there is little to no control on the video buffering, which I believe to be responsible of the observed latency.

  


  On a side note, I tried to check how google stadia is doing it, as they seem to use WebRTC as well, but they use some in-house frameworks... (plus Chrome is the only supported browser)