Recherche avancée

Sur d’autres sites (8766)

• FFMPEG convert rtp stream to rtmp - bind failed address already in use

  27 août 2020, par Leo

  I setup a server with Janus gateway and using videoroom plugin I'm trying to forward locally the rtp stream using port 5002 for audio and 5004 for video.
This is the videoroom plugin configuration

  



      room-1234: {
        description = "Demo Room"
        secret = "adminpwd"
        publishers = 6
        bitrate = 128000
        fir_freq = 1
        #fir_freq = 10
        audiocodec = "opus"
        videocodec = "vp8"
        #videocodec = "h264"
        record = false
        #rec_dir = "/path/to/recordings-folder"
}


  



  After the RTP forward I would like to convert the video to rtmp to get the video remotely using OBS Studio and I set up an nginx server with rtmp plugin. Using ffmpeg I'm trying to make this conversion and I created the sdp file with this content :

  



  v=0
o=- 0 0 IN IP4 127.0.0.1
s=RTP Video
c=IN IP4 127.0.0.1
t=0 0
a=tool:libavformat 58.29.100
m=audio 5002 RTP/AVP 111
a=rtpmap:111 OPUS/48000/2
m=video 5004 RTP/AVP 100
a=rtpmap:100 VP8/90000
a=fmtp:100


  



  And then I launched the command

  



  ffmpeg -protocol_whitelist rtp,udp,file -loglevel trace -analyzeduration 300M -probesize 300M -i config.sdp -c:v copy -c:a aac -ar 16k -ac 1 -preset ultrafast -tune zerolatency rtmp://127.0.0.1/live/1234


  



  But I got back the error bind failed address already in use. Below the complete output

  



  built with gcc 8 (Debian 8.3.0-6)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
Splitting the commandline.
Reading option '-protocol_whitelist' ... matched as AVOption 'protocol_whitelist' with argument 'rtp,udp,file'.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'trace'.
Reading option '-analyzeduration' ... matched as AVOption 'analyzeduration' with argument '300M'.
Reading option '-probesize' ... matched as AVOption 'probesize' with argument '300M'.
Reading option '-i' ... matched as input url with argument 'config.sdp'.
Reading option '-c:v' ... matched as option 'c' (codec name) with argument 'copy'.
Reading option '-c:a' ... matched as option 'c' (codec name) with argument 'aac'.
Reading option '-ar' ... matched as option 'ar' (set audio sampling rate (in Hz)) with argument '16k'.
Reading option '-ac' ... matched as option 'ac' (set number of audio channels) with argument '1'.
Reading option '-preset' ... matched as AVOption 'preset' with argument 'ultrafast'.
Reading option '-tune' ... matched as AVOption 'tune' with argument 'zerolatency'.
Reading option 'rtmp://127.0.0.1/live/1234' ... matched as output url.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument trace.
Successfully parsed a group of options.
Parsing a group of options: input url config.sdp.
Successfully parsed a group of options.
Opening an input file: config.sdp.
[NULL @ 0x5594280] Opening 'config.sdp' for reading
Probing sdp score:50 size:205
[sdp @ 0x5594280] Format sdp probed with size=2048 and score=50
[sdp @ 0x5594280] sdp: v='0'
[sdp @ 0x5594280] sdp: o='- 0 0 IN IP4 127.0.0.1'
[sdp @ 0x5594280] sdp: s='RTP Video'
[sdp @ 0x5594280] sdp: c='IN IP4 127.0.0.1'
[sdp @ 0x5594280] sdp: t='0 0'
[sdp @ 0x5594280] sdp: a='tool:libavformat 58.29.100'
[sdp @ 0x5594280] sdp: m='audio 5002 RTP/AVP 111'
[sdp @ 0x5594280] sdp: a='rtpmap:111 OPUS/48000/2'
[sdp @ 0x5594280] audio codec set to: opus
[sdp @ 0x5594280] audio samplerate set to: 48000
[sdp @ 0x5594280] audio channels set to: 2
[sdp @ 0x5594280] sdp: m='video 5004 RTP/AVP 100'
[sdp @ 0x5594280] sdp: a='rtpmap:100 VP8/90000'
[sdp @ 0x5594280] video codec set to: vp8
[sdp @ 0x5594280] sdp: a='fmtp:100'
[udp @ 0x5597980] bind failed: Address already in use
[AVIOContext @ 0x559d580] Statistics: 205 bytes read, 0 seeks
config.sdp: Invalid data found when processing input


  



  I did a lot of searches and tries but I'm really not able to figure out what's wrong. Could you please help me to understand the error ?

  



  Thank you !

  


• avcodec/aom_film_grain : add AOM film grain synthesis

  4 octobre 2023, par Niklas Haas

  avcodec/aom_film_grain : add AOM film grain synthesis
  Implementation copied wholesale from dav1d, sans SIMD, under permissive
  
  license. This implementation was extensively verified to be bit-exact,
  
  so it serves as a much better starting point than trying to re-engineer
  
  this from scratch for no reason. (I also authored the original
  
  implementation in dav1d, so any "clean room" implementation would end up
  
  looking much the same, anyway)
  The notable changes I had to make while adapting this from the dav1d
  
  code-base to the FFmpeg codebase include :
   reordering variable declarations to avoid triggering warnings
  
   replacing several inline helpers by avutil equivalents
  
   changing code that accesses frame metadata
  
   replacing raw plane copying logic by av_image_copy_plane
  Apart from this, the implementation is basically unmodified.
  

  • [DH] libavcodec/aom_film_grain.c
  • [DH] libavcodec/aom_film_grain.h
  • [DH] libavcodec/aom_film_grain_template.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)