I'm trying to setup a media processing server. I've done a lot of research for FFMPEG and wrote a command. The command is as follows.
ffmpeg -y -i "bbb_sunflower_2160p_60fps_normal.mp4" -c:v libx264 \
-threads 7 -profile:v main -preset ultrafast -vf scale=1920:-1 \
"process/video/1080p.mp4" -c:v libx264 -threads 7 -profile:v main \
-preset ultrafast -vf scale=1280:-1 "process/video/720p.mp4" -c:v \
libx264 -threads 7 -profile:v main -preset ultrafast -vf \
scale=854:-1 "process/video/480p.mp4" -vf fps=5/60 \
process/image/thumb_%d.jpg
This command works and runs perfectly, but it is dirt slow. My server, which is dedicated to just running ffmpeg has the following specs:
12 core intel Xeon X5650 (Hyperthreading enabled)
64 GB ECC DDR3 RAM
250 GB SSD Drive
But when I use this command, the server CPU load hangs around 250-300%, which I would like it to hang around 2,000% while processing the video. Currently when processing the video, the server is rendering around 17 frames per second. This would take a very long time to process a 10 minute video that's 60fps.
It's the scaler. The scaler in ffmpeg is single threaded, it is a bottleneck on a system with that many threads. Try running a different process for each output.
If you are running windows, try again with defender (and any other virus checker) disabled. It can make a huge difference.
Let us know the outcome please...
This worked for me on a windows 10 machine (which then processed up to ten times faster ) and is therefore a possible answer to the above problem. Clarification (of any sort) is not requested, but it would be good to know if it helped.
This is a very complicated commandline with little to no useful information. For example, you're not providing FFmpeg stdout/stderr (which contains lots of useful information). Possible causes:
video encoding is simply too slow (try 1 encode instead of 3, w/o screenshots)
maybe your bottleneck is audio (test with -an)
something else?
I'd encourage you to test simpler versions and provide stdout/stderr.
Related
I recently upgraded to Windows 11, just in case that matters, and I went to encode a series of images into a video with FFmpeg like I usually would. For some reason seemingly randomly it just stops. No error is given, the frame that it stops on is random, the amount of time it's encoding for is random, and starting from a different frame doesn't change anything.
Here is the code I'm using:
ffmpeg -r 59.94 -f image2 -start_number 0 -i "%06d.png" -vcodec libx265 -crf 18 -preset medium -tune grain -pix_fmt yuv420p10le "Encode/S2005E14.mp4"
The version of ffmpeg I'm using is the newest git-full version from https://www.gyan.dev/ffmpeg/builds/
The CPU being used to encode it is a Ryzen 3900x.
Log: https://pastebin.com/EnyWs7cL
The problem was caused by an unstable overclock. After reducing the overclock everything worked normally.
I wrote the following script to record an X screen for a specified amount of time, to make sure that it's lossless I've separated it into two steps
record for the specified amount in a codec that requires almost no compression (so there's no overhead that might cause frames to be dropped)
re-encode the original video into HEVC to make the filesize significantly smaller
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -vsync 1 -f x11grab -probesize 128M -s 1920x1080 -r 60 -i :0.0 -qscale 0 -vcodec huffyuv -t 00:01:13 "$video.avi" # record the screen losslessly
ffmpeg -hwaccel cuvid -vsync 1 -i "$video.avi" -map 0:0 -c:v:0 hevc_nvenc -crf 23 -preset medium "$video-clean.mp4"
This works just like I expect it to some of the time, but very often it drops a lot of frames (I've seen as many as 10000 frames dropped on occasion)
The gpu is a 1080 TI that's being used just for rendering an X server with a chrome window and recording it, according to nvidia-smi the usage never goes to higher than 50% even in the most extreme cases.
I don't know what else to try, I thought about using a ramdisk to write the file to as it might be an IO problem, but ffmpeg refuses to write to tmpfs (for some reason I can't explain)
Solved it, recording to a tmpfs turned out to be the solution for me, however because I was using the snap version of ffmpeg I couldn't directly write to ram (because of permission issues), so I just compiled ffmpeg myself (needed support for cuda, and since this script runs on an ubuntu-based machine and the apt version of ffmpeg doesn't have access to cuda for some specific encoders I just compiled ffmpeg myself)
The output of this script is just fine; it's pretty much what I want. But it seems to terminate randomly. My next step will be to try this on another computer to see if the issue persists.
My configuration:
Dell Precision laptop, m4400
2x Intel(R) Core(TM)2 Duo CPU P8600 # 2.40GHz
Linux Mint 18.3 Sylvia
Kernel: Linux 4.4.0-116-generic (x86_64)
Card: NVIDIA G96GLM [Quadro FX 770M]
ffmpeg version 2.8.11-0ubuntu0.16.04.1
USB Camera-B4.09.24.1 Sony Playstation Eye
And this is the script that I'm running - the last time it recorded for about three hours and forty-five minutes, before that it was about 55 minutes; once it ran five and a half hours:
#!/bin/bash
echo "This is a shell script to make a timelapse video."
ffmpeg \
-f v4l2 -input_format yuyv422 -video_size 640x480 -framerate 5 -t 09:00:00 -i /dev/video0 \
-vf "select=not(mod(n\,5)),setpts=N/(60*TB),fps=60, drawtext=fontfile=/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf:text='%{localtime\:%T}':x=20:y=20:fontcolor=white" \
-c:v libx264 -preset superfast -crf 23 -pix_fmt yuv422p -g 15 -keyint_min 15 \
-f mpegts /media/dkm/OneTB/Video/Timelapse_$(date +%Y-%m-%d_%H.%M.%S).ts
Any suggestions would be appreciated. Thanks!
Overnight, I ran this script on three other computers, one of which was run with crontab, and it worked fine on all all three, so I have to conclude that it's outside the mandate of Stackflow and probably a configuration issue. I thought that I might just delete the post, but the code does work, so I offer it up for what it's worth. Hope I'm with the boundaries of etiquette by handling it this way. Thanks to those who had a looksee.
I've been using ffmpeg quite a lot in the past few weeks, and recently I've encountered a very annoying issue - when I use ffmpeg with an input stream (usually, just a url as the input) and try to set a start time (with -ss option), I always get a warn message that says "could not seek to position: XXX".
Then, ffmpeg just starts to download the file, and it ouputs nothing until it has downloaded enough data and got to my desired start time.
I'll give an example:
I use this command to execute ffmpeg:
ffmpeg -ss 50 -re -i https://ascent.usbank.com/acp/videos/041114ascent.flv -b:a 128k -ac 2 -acodec libvorbis -b:v 1024k -vcodec libtheora -strict 2 -preset ultrafast -tune zerolatency -pix_fmt yuv420p -f ogg pipe:1
and I get the warn message
https://ascent.usbank.com/acp/videos/041114ascent.flv: could not seek to position 50.000
Then, it takes about 30 seconds until ffmpeg starts to output data to stdout. And when I try this with longer videos (and longer seek times), it takes even longer.
My question is, what can I do? I guess it's impossible for ffmpeg to seek when it haven't got the whole input stream... Am I wrong? Or is there any other solution?
Of course I try to avoid downloading the entire file from the web...
Thanks in advance!
Roee.
I guess you can't do really anything about it other than to buffer the FLV locally and (eventually) seek that.
Whether or not a http resource allows seeking largely depends on the capabilities of the server, unfortunately...
My computer (Intel Core 2 Duo T9300, 2.5GHz) can usually play any Full HD file, and Blu-Rays perfectly.
However, when I encode a Full HD file myself, the CPU is struggling and frames are dropped.
Here's my command line:
ffmpeg.exe -r 24 -f concat -i list_of_png_files.txt -i w:\audio.wav -acodec copy -c:v libx264 -preset medium -b:v 10000k -shortest output.avi
I tried adding -maxrate 13000k after "-preset medium". However, x264 doesn't seem to honor this - the framerate still reaches 20MBit at parts.
How can I encode videos in such a way as to reduce CPU usage during decoding?
There is an x264 tuning option for exactly this purpose. I believe -tune fastdecode is what you are looking for. But this will disable some compression features, so the video may not look as good without increasing the bitrate.