Recherche avancée

Sur d’autres sites (7289)

• FFMPEG hanging on a frame while streaming to YouTube (streaming incomplete video) - no errors

  12 janvier 2024, par ThePrince

  I have a Flask application that is running an FFMPEG command.

  


  

  1. I extract frames from a local video file (7 seconds long, 235 frames) and process each frame into a JPEG format. I then restream the images one by one to youtube through the pipe (stdin).

  


  2. Simultaneously, I extract the video from the original file and I use -copy to just use the audio from the original file.

  


  


  Here is my command which I run in python :

  


  command = [
    'ffmpeg',
    '-loglevel', 'trace',  # detailed log level
    
    # VIDEO STREAM
    '-f', 'image2pipe',
    '-c:v', 'mjpeg',
    '-i', '-',  

    # AUDIO STREAM
    '-i', f"{input_folder}{filename}",  

    # MAPPING
    '-map', '0:v',  # video from the pipe
    '-map', '1:a',  # audio from original file

    # OUTPUT STREAM
    '-c:v', 'libx264',  # video codec
    '-c:a', 'copy',  # copy from original
    
    '-f', 'flv',
    f'{youtube_url}{stream_key}'
]


  


  I get all the debugging info in the console.
It stops on frame 179 out of 235 frames and just hangs there.

  


  frame=  179 fps=4.2 q=28.0 size=    1020kB time=00:00:07.08 bitrate=1180.8kbits/s speed=0.165x


  


  Ignore the FPS and speed since these are just the effect of it hanging. The FPS and speed will decrease gradually each second that passes.

  


  After I Ctrl+C out of it, I see that all 235 frames were encoded and only 180 were muxed.

  


  I increased the buffer size in case that was the issue and it seemed to mux all of them, but the content was still cut short.

  


  To be clear, in my YouTube stream I only got the first 5 out of 7 seconds of video before cutting off.

  


  When I increased the buffer, it hung only on the very last frame... and showed no errors, but again the output video was 7 seconds and was cut short.

  


  A typical output from the log is this :

  


  [libx264 @ 0000021e913b67c0] frame= 233 QP=25.95 NAL=2 Slice:P Poc:106 I:21   P:310  SKIP:1289 size=3403 bytes
[mjpeg @ 0000021e913f9240] marker=d8 avail_size_in_buf=68061
[mjpeg @ 0000021e913f9240] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000021e913f9240] marker=e0 avail_size_in_buf=68059
[mjpeg @ 0000021e913f9240] marker parser used 16 bytes (128 bits)
[mjpeg @ 0000021e913f9240] marker=db avail_size_in_buf=68041
[mjpeg @ 0000021e913f9240] index=0
[mjpeg @ 0000021e913f9240] qscale[0]: 3
[mjpeg @ 0000021e913f9240] marker parser used 67 bytes (536 bits)
[mjpeg @ 0000021e913f9240] marker=db avail_size_in_buf=67972
[mjpeg @ 0000021e913f9240] index=1
[mjpeg @ 0000021e913f9240] qscale[1]: 6
[mjpeg @ 0000021e913f9240] marker parser used 67 bytes (536 bits)
[mjpeg @ 0000021e913f9240] marker=c0 avail_size_in_buf=67903
[mjpeg @ 0000021e913f9240] sof0: picture: 852x480
[mjpeg @ 0000021e913f9240] component 0 2:2 id: 1 quant:0
[mjpeg @ 0000021e913f9240] component 1 1:1 id: 2 quant:1
[mjpeg @ 0000021e913f9240] component 2 1:1 id: 3 quant:1
[mjpeg @ 0000021e913f9240] pix fmt id 22111100
[mjpeg @ 0000021e913f9240] marker parser used 17 bytes (136 bits)
[mjpeg @ 0000021e913f9240] marker=c4 avail_size_in_buf=67884
[mjpeg @ 0000021e913f9240] class=0 index=0 nb_codes=12
[mjpeg @ 0000021e913f9240] marker parser used 31 bytes (248 bits)
[mjpeg @ 0000021e913f9240] marker=c4 avail_size_in_buf=67851
[mjpeg @ 0000021e913f9240] class=1 index=0 nb_codes=162
[mjpeg @ 0000021e913f9240] marker parser used 181 bytes (1448 bits)
[mjpeg @ 0000021e913f9240] marker=c4 avail_size_in_buf=67668
[mjpeg @ 0000021e913f9240] class=0 index=1 nb_codes=12
[mjpeg @ 0000021e913f9240] marker parser used 31 bytes (248 bits)
[mjpeg @ 0000021e913f9240] marker=c4 avail_size_in_buf=67635
[mjpeg @ 0000021e913f9240] class=1 index=1 nb_codes=162
[mjpeg @ 0000021e913f9240] marker parser used 181 bytes (1448 bits)
[mjpeg @ 0000021e913f9240] escaping removed 740 bytes
[mjpeg @ 0000021e913f9240] marker=da avail_size_in_buf=67452
[mjpeg @ 0000021e913f9240] component: 1
[mjpeg @ 0000021e913f9240] component: 2
[mjpeg @ 0000021e913f9240] component: 3
[mjpeg @ 0000021e913f9240] marker parser used 66711 bytes (533681 bits)
[mjpeg @ 0000021e913f9240] marker=d9 avail_size_in_buf=0
[mjpeg @ 0000021e913f9240] decode frame unused 0 bytes
[libx264 @ 0000021e913b67c0] frame= 234 QP=26.34 NAL=2 Slice:P Poc:108 I:23   P:368  SKIP:1229 size=3545 bytes


  


  There really are no errors other than not finding end of file when it hangs and I Ctrl+C.

  


  I have tested the following :

  


  

  1. I decided to loop Frame #1 repeatedly to make sure it wasn't the actual frame content that was the issue (problem still remained).

  


  2. I adjusted buffer size, fps, re, FPS on both sources and target.

  


  3. I even switched to another video and it still hung.

  


  4. When I tried a higher definition video it would hang at a later frame (since there were more frames to work with) but it still would hang close to the 5 second mark on a 7 second video.

  


  5. I also changed the audio to a silent stream and it didn't work (same issue happened).

  


  6. I even changed the output target to an actual mp4 file instead of a youtube stream, and the output video was cut off !

  


  


  Note : I notice the default FPS is 25 for the video stream, yet the original FPS from video was 30 FPS so I don't know if this might be causing the issue.

  


  Guys I'm ready to throw in the towel here. I read the ffmpeg documentation in detail and nothing helped (also the online chatrooms for ffmpeg don't work). Looked at video tutorials and learned deeply about MPEG. I am lost for what to do and ready to move on to another tool.

  


• Why is one ffmpeg webm dash stream much larger than the others ?

  5 janvier 2017, par ranvel

  Over the summer, I worked on putting together a script which took a x264 video/mp3 stream and broke it up into the different streams so that it would work via MSE-DASH. (Based heavily on the instructions on the webmproject.org website) Those same scripts have ceased to work, turning a 6GB video into several 25 Gb videos. I kept up with updates of ffmpeg and so I don’t know when it stopped working, but I am guessing it was due to the way that their DASH Webm implementation was updated.

  I found new method which works better, but still has a major problem with one stream. I was hoping someone could explain how this encoding works so that I could understand the underlying cause.

  #!/bin/bash
  
  COMMON_OPTS="-map 0:0 -an -threads 11 -cpu-used 4 -cmp chroma"
  
  WEBM_OPTS="-f webm -c:v vp9 -keyint_min 50 -g 50 -dash 1"
  
  
  
  ffmpeg -i $1 -vn -acodec libvorbis -ab 128k audio.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 500k -vf scale=1280:720 -y vid-500k.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 700k -vf scale=1280:720 -y vid-700k.webm & 
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 1000k -vf scale=1280:720 -y vid-1000k.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 1500k -vf scale=1280:720 -y vid-1500k.webm  

  The transcode is not yet complete, but you can see where this is headed :

  -rw-r--r--  1 user  staff    87M Jan  4 23:27 audio.webm
  
  -rw-r--r--  1 user  staff    27M Jan  4 23:42 vid-1000k.webm
  
  -rw-r--r--  1 user  staff   285M Jan  4 23:42 vid-1500k.webm
  
  -rw-r--r--  1 user  staff    15M Jan  4 23:42 vid-500k.webm
  
  -rw-r--r--  1 user  staff    20M Jan  4 23:42 vid-700k.webm

  The 1500k variant is disproportionately larger than the other streams.

  The other problem is that when I use a shorter video, lets say eight or nine minutes, the above configuration runs as expected and everything is perfect. I don’t know where the limit for this is since each test costs a lot of processing power and time, but if it’s less than ten minutes, it works and if its longer than an hour, it produces massive files.

• Change file format from flv to anything android will play

  19 octobre 2011, par Bilthon

  I need to take this file which encoded is in h264 but in a flv container and just put it in a mp4, 3gp or whatever file format the android MediaPlayer will understand.

  I want to do this natively. As I will not be decoding nor encoding anything I think I will not be wasting a lot of power (am I wrong ?)

  I followed the instructions from here http://www.roman10.net/?p=394 and could sucessfully compile and use ffmpeg and use it with mp4 and 3gp files.

  But when it comes to flv files it fails. I understand there is no format definition for flv files in that specific port of ffmpeg for android.

  There is no libavformat/flv.h header file for instance.

  Maybe that's why this works :

  extern AVInputFormat ff_mov_demuxer ;
  av_register_input_format(&ff_mov_demuxer) ;

  While this fails :

  extern AVInputFormat ff_flv_demuxer;
  
  av_register_input_format(&ff_flv_demuxer);

  Question is, is there a light at the end of the tunnel ? has someone done something similar ? is it useful ? I mean, I can always just throw the flv media file into a flash player and voila.. the thing is that this would be a parcial solution, as it will not work for all those folks running slower devices that can't yet run Flash.

  Nelson

  PS. Just in case. Here's some info about the file I'm talking about :

  ffmpeg -i rio.flv 
  
  ffmpeg version N-32624-gea8de10, Copyright (c) 2000-2011 the FFmpeg developers
  
    built on Sep 15 2011 23:31:42 with gcc 4.5.2
  
    configuration: --enable-libfaac --enable-libmp3lame --enable-librtmp --enable-libtheora --enable-libx264 --enable-libxvid --enable-gpl --enable-nonfree
  
    libavutil    51. 16. 0 / 51. 16. 0
  
    libavcodec   53. 15. 0 / 53. 15. 0
  
    libavformat  53. 12. 0 / 53. 12. 0
  
    libavdevice  53.  3. 0 / 53.  3. 0
  
    libavfilter   2. 42. 0 /  2. 42. 0
  
    libswscale    2.  1. 0 /  2.  1. 0
  
    libpostproc  51.  2. 0 / 51.  2. 0
  
  
  
  Seems stream 0 codec frame rate differs from container frame rate: 2000.00 (2000/1) -> 14.99 (15000/1001)
  
  Input #0, flv, from 'rio.flv':
  
    Duration: 00:01:00.06, start: 0.000000, bitrate: 783 kb/s
  
      Stream #0.0: Video: h264 (Main), yuv420p, 704x480 [SAR 10:11 DAR 4:3], 14.99 tbr, 1k tbn, 2k tbc