Recherche avancée

Sur d’autres sites (5737)

• FFMPEG update from 5.0 to 6.0 out_0_0 buffer queued [closed]

  16 mai 2023, par Kevitto

  I've been using ffmpeg 5.0 for some time, encoding an audio stream to an rtp server, but since I updated to ffmpeg 6.0 I get this :

  


  [out_0_0 @ 0x55ac187b60] 100 buffers queued in out_0_0, something may be wrong.


  


  Below is the ffmpeg call :

  


  ffmpeg -re -f alsa -i default:CARD:card1 -ac 2 -af aresample=async=1 -acodec libopus -b:a 48000 -f rtp "rtp://127.0.0.1:5002"


  


  And here is the full startup log :

  


  ffmpeg version 549430e Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 10 (Debian 10.2.1-6)
  configuration: --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib --extra-libs='-lpthread -lm -latomic' --arch=arm64 --enable-gmp --enable-gpl --enable-libopus --enable-nonfree --enable-version3 --target-os=linux --enable-pthreads --enable-openssl --enable-hardcoded-tables
  libavutil      58.  2.100 / 58.  2.100
  libavcodec     60.  3.100 / 60.  3.100
  libavformat    60.  3.100 / 60.  3.100
  libavdevice    60.  1.100 / 60.  1.100
  libavfilter     9.  3.100 /  9.  3.100
  libswscale      7.  1.100 /  7.  1.100
  libswresample   4. 10.100 /  4. 10.100
  libpostproc    57.  1.100 / 57.  1.100
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, alsa, from 'default:CARD=pisound':
  Duration: N/A, start: 1684250059.973334, bitrate: 1536 kb/s
  Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_s16le (native) -> opus (libopus))
Press [q] to stop, [?] for help
Output #0, rtp, to 'rtp://127.0.0.1:5002':
  Metadata:
    encoder         : Lavf60.3.100
  Stream #0:0: Audio: opus, 48000 Hz, stereo, s16, 48 kb/s
    Metadata:
      encoder         : Lavc60.3.100 libopus
SDP:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 127.0.0.1
t=0 0
a=tool:libavformat 60.3.100
m=audio 5002 RTP/AVP 97
b=AS:48
a=rtpmap:97 opus/48000/2
a=fmtp:97 sprop-stereo=1

size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
[out_0_0 @ 0x559f530c60] 100 buffers queued in out_0_0, something may be wrong.
size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
size=       0kB time=-00:00:00.00 bitrate=  -0.0kbits/s speed=N/A    
size=       0kB time=-00:00:00.00 bitrate=  -0.0kbits/s speed=N/A    
[alsa @ 0x559f4db460] ALSA buffer xrun.
size=       6kB time=00:00:02.81 bitrate=  16.7kbits/s speed=0.93x    
size=       6kB time=00:00:02.81 bitrate=  16.7kbits/s speed=0.797x    
size=       6kB time=00:00:02.83 bitrate=  16.6kbits/s speed=0.703x    
size=       6kB time=00:00:02.83 bitrate=  16.6kbits/s speed=0.624x    
size=       6kB time=00:00:02.83 bitrate=  16.6kbits/s speed=0.562x    
size=       6kB time=00:00:02.83 bitrate=  16.6kbits/s speed=0.511x    
[alsa @ 0x559f4db460] ALSA buffer xrun.
size=      10kB time=00:00:05.67 bitrate=  14.8kbits/s speed=0.939x    
size=      10kB time=00:00:05.67 bitrate=  14.8kbits/s speed=0.866x    
size=      10kB time=00:00:05.67 bitrate=  14.8kbits/s speed=0.805x    
size=      10kB time=00:00:05.67 bitrate=  14.8kbits/s speed=0.751x    
size=      10kB time=00:00:05.69 bitrate=  14.8kbits/s speed=0.707x    
[alsa @ 0x559f4db460] ALSA buffer xrun.
size=      13kB time=00:00:05.95 bitrate=  17.8kbits/s speed=0.696x    
size=      16kB time=00:00:08.51 bitrate=  15.2kbits/s speed=0.939x    
size=      16kB time=00:00:08.51 bitrate=  15.2kbits/s speed=0.89x    
size=      16kB time=00:00:08.53 bitrate=  15.2kbits/s speed=0.847x    
size=      16kB time=00:00:08.53 bitrate=  15.2kbits/s speed=0.806x    
size=      16kB time=00:00:08.53 bitrate=  15.2kbits/s speed=0.77x    
[alsa @ 0x559f4db460] ALSA buffer xrun.
size=      21kB time=00:00:11.37 bitrate=  14.8kbits/s speed=0.981x  


  


  I tried changing the output to -f null /dev/null to see if the rtp was the issue, but I get the same thing. I made sure the user running it was a member to the "audio" group and arecord -l and aplay -l both show the card with the right name and information. I even tried to use its hw code instead of the default name, and same issue.

  


• x264vfw - is the H.264/MPEG-4 AVC codec advisable to use ?

  26 avril 2012, par Dhaval Kariya

  I have generated a graph using the GraphEdit utility of Directshow.

  My Graph is as follow :

  osprey card -> x264vfw - H.264/MPEG-4 AVC codec -> GDCL Multiplexer -> File writer (.mp4     
  
  file)

  I used x264vfw - H.264/MPEG-4 AVC codec, downloaded from
  http://sourceforge.net/projects/x264vfw/.

  I want to know if it is advisable to use this codec to encode the live video streams ?
  And what about the support and licensing for it ?

• How to have low buffer when capturing sound with FFmpeg

  8 mai 2018, par gagz

  I’m capturing sound from the jack input of a computer and sending that to a Icecast server, using FFmpeg.

  See the line :

  /usr/bin/ffmpeg -f alsa -i plughw:1 -c:a libmp3lame -b:a 96k -ar 32000 -content_type audio/mpeg -f mp3 icecast://source:password@myserver.net:8000/live

  On the Icecast side, I use default settings, and play the stream with mplayer.

  But the bandwidth on both sides is quite low (3G connections), thus after a while, the delay goes up to a few minutes, so I have to restart ffmpeg.

  I’m quiet sure now that ffmpeg keeps collecting data when frames are dropped by the network, but it keeps them until the connection comes back and then sends them to icecast.

  How can I tell FFmpeg to stay synchronised with the sound card ? Or have a maximum of 5 seconds delay ?

  Thank you !