Recherche avancée

Sur d’autres sites (13022)

• 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.

  


• Evolution #3336 : Amélioration sitemap.xml.html pour gestion des sites multilingues

  6 novembre 2014, par b b

  Salut, comme je te le disais sur IRC, il semble acquis que la dist ne doit pas prendre en charge le multilinguisme (voir les anciens tickets sur ce projet).

  Du coup, doit-on gérer le multilinguisme dans le sitemap fourni par la dist ?

  D’un côté, on pourrait dire non puisque le sitemap en question est fourni par la dist (dans ce cas, un sitemap multilingue pourrait être proposé sous forme de plugin ou de contrib). De l’autre côté, le sitemap est un élément de base du site, un peu comme le robots.txt, ce qui me fait penser que ça serait pas mal qu’il prenne en charge le multilinguisme.

  D’autres avis ?

• Xcode 12 : how to link against object files built for free standing

  1er octobre 2020, par Jean-Michaël Celerier

  The issue is about linking x86_64 macOS executables statically against libavcodec, libavdevice, etc, which have some object files built against freestanding as they use YASM which isn't able to embed the macOS "tag" in the binary (see Building for macOS, but linking in object file built for free standing for detailed information on that issue).

  


  Everything works fine under Xcode 11.6 - the following messages are here, but they are warnings.
With the Xcode 12 update they become an error.
How to make them warnings again ? I could not find anything relevant in the ld man page.

  


  


  ld : in ffmpeg/lib/libavcodec.a(aacencdsp.o), building for macOS, but linking in object file built for free standing, for architecture x86_64