Recherche avancée

Sur d’autres sites (10482)

• youtube stream from ffmpeg is buffering

  1er juin 2020, par Bartonsen

  I'm using ffmpeg running on a Raspberry Pi 3B with 1GB RAM to stream live video on youtube.
In the beginning the audio+video stream is excellent, but after some minutes I see error messages in YT studio, and video starts buffering.
After some more time (could be 30 mins or 1 hr) the youtube stream is gone, although ffmpeg is still running.

  



  ffmpeg is configured like this :

  



  ./configure --arch=armel --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-omx-rpi


  



  Running ffmpeg :

  



  pi@raspberrypi:~ $ ffmpeg -thread_queue_size 512 -rtsp_transport udp -i "rtsp://10.x.x.x:554/user=user&password=password&channel=1&stream=0.sdp?real_stream" -c:v copy -c:a aac -f flv rtmp://a.rtmp.youtube.com/live2/mykey
ffmpeg version git-2020-05-01-3c740f2 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1+deb9u1) 20170516
  configuration: --arch=armel --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-omx-rpi
  libavutil      56. 43.100 / 56. 43.100
  libavcodec     58. 82.100 / 58. 82.100
  libavformat    58. 42.102 / 58. 42.102
  libavdevice    58.  9.103 / 58.  9.103
  libavfilter     7. 80.100 /  7. 80.100
  libswscale      5.  6.101 /  5.  6.101
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
[udp @ 0x3a8c370] attempted to set receive buffer to size 393216 but it only ended up set as 327680
[udp @ 0x3a9ea80] attempted to set receive buffer to size 393216 but it only ended up set as 327680
[udp @ 0x3a8c3e0] attempted to set receive buffer to size 393216 but it only ended up set as 327680
[udp @ 0x3abf4d0] attempted to set receive buffer to size 393216 but it only ended up set as 327680
Guessed Channel Layout for Input Stream #0.1 : mono
Input #0, rtsp, from 'rtsp://10.x.x.x:554/user=user&password=password&channel=1&stream=0.sdp?real_stream':
  Metadata:
    title           : RTSP Session
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 1920x1080, 20 fps, 20 tbr, 90k tbn, 180k tbc
    Stream #0:1: Audio: pcm_alaw, 8000 Hz, mono, s16, 64 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (pcm_alaw (native) -> aac (native))
Press [q] to stop, [?] for help
[aac @ 0x3ae9f00] Too many bits 8832.000000 > 6144 per frame requested, clamping to max
Output #0, flv, to 'rtmp://a.rtmp.youtube.com/live2/mykey':
  Metadata:
    title           : RTSP Session
    encoder         : Lavf58.42.102
    Stream #0:0: Video: h264 (Main) ([7][0][0][0] / 0x0007), yuvj420p(pc, bt709, progressive), 1920x1080, q=2-31, 20 fps, 20 tbr, 1k tbn, 90k tbc
    Stream #0:1: Audio: aac (LC) ([10][0][0][0] / 0x000A), 8000 Hz, mono, fltp, 48 kb/s
    Metadata:
      encoder         : Lavc58.82.100 aac


  



  In youtube studio I see this :

  



  19:36 Good transmission. The quality is excellent.
19:39 Suggestion: The current sampling rate is 0. Recommended sampling rates are 44.1 kHz and 48 kHz.
19:39 Suggestion: The current bitrate (0) of the audio stream is lower than the recommended bitrate. We recommend using a 128 Kbps bitrate for the audio stream.
19:39 Warning: The current bit rate (1974.24 kbps) is lower than the recommended bit rate. We recommend using a 4500 Kbps bitrate for the stream.
19:41 Suggestion: The current sampling rate is 0. Recommended sampling rates are 44.1 kHz and 48 kHz.
19:41 Suggestion: The current bitrate (0) of the audio stream is lower than the recommended bitrate. We recommend using a 128 Kbps bitrate for the audio stream.
19:41 Warning: The current bit rate (2151.41 kbps) is lower than the recommended bit rate. We recommend using a 4500 Kbps bitrate for the stream.
19:43 Suggestion: The current sampling rate is 0. Recommended sampling rates are 44.1 kHz and 48 kHz.
19:43 Suggestion: The current bitrate (0) of the audio stream is lower than the recommended bitrate. We recommend using a 128 Kbps bitrate for the audio stream.
19:45 Suggestion: The current sampling rate is 0. Recommended sampling rates are 44.1 kHz and 48 kHz.
19:45 Suggestion: The current bitrate (0) of the audio stream is lower than the recommended bitrate. We recommend using a 128 Kbps bitrate for the audio stream.
19:45 Warning: The current bit rate (1737.61 kbps) is lower than the recommended bit rate. We recommend using a 4500 Kbps bitrate for the stream.
...
19:54: Error: YouTube does not receive enough video to maintain consistent streaming. Viewers will therefore experience buffering.


  



  What is the problem ? How can I get rid of the buffering ?
I've also tried the below two commands, but found the output to be worse...

  



  ffmpeg -i rtsp://... -c:v libx264  -b:v 4000k -maxrate 4000k -bufsize 8000k -g 40 -preset ultrafast -vf format=yuv420p -c:a aac -f flv output
ffmpeg -i rtsp://... -c:v h264_omx -b:v 4000k -maxrate 4000k -bufsize 8000k -g 40 -preset ultrafast -vf format=yuv420p -c:a aac -f flv output


  


• Revision 33026 : Ajout des classes mots, breves, auteurs ... dans les extras

  17 novembre 2009, par shnoulle@… — Log

  Ajout des classes mots, breves, auteurs ... dans les extras

• Can I know which byte range to read from a remote mp4 file for FFMpeg to decode a keyframe ?

  12 octobre 2023, par db9117

  I need to decode a of keyframe of a video file (mp4, h264 encoded). I know the timestamp of the keyframe I want to extract/decode. I want to minimize amount of data being read in memory. For this, I need to know beforehand exactly the minimal byte range I would require that encompasses this keyframe. How do I know what is the minimal byte range in the whole mp4 byte stream I need to read in order to be able to decode the keyframe ?

  


  I currently find the appropriate keyframe in the index_entries contained in the header. I get its byte position (pos attribute) and timestamp (timestamp attribute). I calculate the range as follows :

  


  startBytes : minimum of :

  


  

  1. the pos of the keyframe

  


  2. the pos of the nearest index entry in the audio stream happening at or before the keyframe's timestamp.

  


  


  This way when it's decoding the frame, if it also needs the audio content for demuxing, it would have it.

  


  endBytes : maximum of :

  


  

  1. the pos of the next frame in the video stream's index, after the keyframe

  


  2. the pos of the next frame in the audio stream's index after the timestamp of the wished keyframe.

  


  


  This way I know that I have everything up until the next frame in the index, which theoretically should be enough to decode the keyframe only.

  


  I then read the appropriate byte range.

  


  When I try to decode the frame, I run in a loop until I succeed :

  


  

  • avcodec_read_frame

  


  • avcodec_send_packet

  


  • avcodec_receive_frame

  


  


  I ignore AVERROR(EAGAIN) errors.

  


  avcodec_receive_frame fails multiple times with error AVERROR(EAGAIN) which I ignore, until it fails saying that the memory it wants to read isn't available (wants to read after endBytes). I explicitly tell it to fail if it wants to read more than it has already read.

  


  Note : for other keyframes at other positions in other videos, it sometimes succeeds (probably because the range is big enough by chance), but it fails more often than not.

  


  My question is : Why is the end of the range not enough to be able to decode only the one keyframe ? Is there any way to more precisely calculate the exact range in bytes I would need in order to decode a particular keyframe ?