How to get FFMPEG to use more GPU when encoding - encoding

so the situation is as following
Im receiging 20/30 uncompressed image per second. format is either PNG or Bitmap. Each individual photo size is between 40 and 50 mb (all have same size since uncompressed).
I want to encode them to a 265 lossless video and stream them to a http server using FFMPEG.
The output video is 1920x1080, so there is some downsampling.
Compression is allowed but nothing is allowed to be lost other than the down sampling.
now i m still in the testing phase. i have a 500 sample image. and i m tryng to encode them as effeciently as possible.
Im using commands such as :
ffmpeg -hwaccel cuvid -f image2 -i "0(%01d).png" -framerate 30 -pix_fmt p010le -c:v hevc_nvenc -preset lossless -rc vbr_hq -b:v 6M -maxrate:v 10M -vf scale=1920:1080 -c:a aac -b:a 240k result.mp4
I have a powerfull modern quadro GPU and a 6 cores intel CPU and an Nvme hard drive.
The usuage of the GPU when encoding is exactly 10%, CPU is circa 30-40%
How can i get GPU usuage to 80% ? The machine on which im going to run the code will have at leat a quadro 4000 (maybe stronger) and i want to use it to the fullest

That’s not how it works. GPUs do not use the standard vector processing units for video encoding. (Well, it does a little, for things like color conversion and scaling, but not not for everything). The GPU has dedicated circuitry for video encoding primitives. When those are full, it doesn’t matter how many GPU cores you have, they will be idle.
So to to use “more” GPU, you don’t get a beefy GPU, you buy a card that has more NVENC cores.

If your ffmpeg was compiled with --enable-libnpp then consider using the GPU based scale_npp filter instead of scale which is CPU only. Example from FFmpeg Wiki: Hardware Acceleration:
ffmpeg -hwaccel cuda -i input -vf scale_npp=1920:1080 -c:v h265_nvenc output.mp4
You may see an improvement in performance or GPU utilization.

Related

What kind of encoder is suitable for AVIREAD in Matlab?

I have a raw video (no header, just Y-channel).
I want do some denoise algorithm on this video.
I convert this raw video by useing ffmpeg with several encoders.
But fail to open with function AVIREAD.
Error using aviread, Unable to locate decompressor to decompress video stream
r210 Uncompressed RGB 10-bit
v210 Uncompressed 4:2:2 10-bit
v308 Uncompressed packed 4:4:4
v410 Uncompressed 4:4:4 10-bit
y41p Uncompressed YUV 4:1:1 12-bit
yuv4 Uncompressed packed 4:2:0
mjpeg MJPEG (Motion JPEG)
ffmpeg -f rawvideo -vcodec rawvideo -s 1920x1080 -r 25 -pix_fmt gray -i WKA00002.y -c:v v308 WKA00002_UnCompAVI.avi
What kind of encoder is suitable for AVIREAD in Matlab?
Thanks a lot
AVIREAD has been removed from the latest versions of MATLAB. Use VIDEOREADER instead.
Motion JPEG AVI is supported by VideoReader.
if you want to try other formats, first check that the file can be opened using Windows Media Player? If so, use VideoReader to try and read the file. If this does not work, can you provide a link to the file that you are using?
Hope this helps.
Dinesh

Apple Quick Time Mov Files Slow Down Playback Rate Via Command Line

I am looking for commmandline to slow down Quick Time formated MOV files. Most likely using FFMPEG. I do not mind converting to MP4 format either.
To slow down your video, you have to use a multiplier greater than 1:
ffmpeg -i input.mov -filter:v "setpts=2.0*PTS" output.mov
I am not sure if this works right now.
batch slow down .mov speed (No answer here either)
Almost impossible without full reencoding (or transcondig).
If the source is video only, it can be easily done by simple hex editing. Just change the track timescale value in the MDHD box =>
http://wiki.multimedia.cx/?title=QuickTime_container#mdhd
The lower timescale the slower play rate.
I've tested it works as following:
1) find out current frame rate with Mediainfo tool
2) Open the file with HxD
3) Recklessly search 'mdhd'
4) Between 'mdhd' and 'hdlr', find 16 bit big endian hex representation of frame rate and change it
I'm not sure but this kind of hacking seems not supported by ffmpeg.
But if it also has audio track, changing its timescale will produce noisy sound, therefore reencoding is unavoidable.
Transcoding is rather straightforward work. I'd recommend HandBreak or other GUI frontends.
Use this line
ffmpeg -i input.mkv -filter_complex "[0:v]setpts=0.5*PTS[v];[0:a]atempo=2.0[a]" -map "[v]" -map "[a]" output.mkv
I used this link
https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20video

Converting mp4 to webm in a batch

I have a large batch (400+) of mp4 files I wish to convert to webm.
I've tried:
ffmpeg -i myfile.mp4 -c:v libvpx -minrate 1M -maxrate 1M -b:v 1M myfile.webm
but the file is corrupt when I try to play it. Could anyone help? Here is input data for one of the mp4 files... I'm not really good enough with these things to know what it all means, but I tried my best to pull out bits I thought might be relevant.
Format : MPEG-4
File size : 2.18 MiB
Duration : 1s 857ms
Overall bit rate mode : Variable
Overall bit rate : 9 829 Kbps
Video
Codec ID : 20
Bit rate mode : Constant
Bit rate : 9 808 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 fps
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.178
Stream size : 2.15 MiB (99%)
Writing library : Lavc54.59.100
When I do that with an MP4 file of my own, the output actually plays fine in both mplayer and vlc; you might want to read ffmpegs official examples on this.
You should define the audio format you want to use; whatever tells you the file is "broken" maybe doesn't like what it sees, which probably is what was in the MP4 container to begin with:
ffmpeg -i input.mp4 -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 1M -c:a libvorbis output.webm

Why does FFMPEG always make large WebM files?

I'm trying to encode my movies into WebM:
ffmpeg -i input.MOV -codec:v libvpx -quality good -cpu-used 0 -b:v 10k
-qmin 10 -qmax 42 -maxrate 10k -bufsize 20k -threads 8 -vf scale=-1:1080
-codec:a libvorbis -b:a 192k
output.webm
I want to encode at a couple of different bit rates (video and audio combined):
2192 kbps
1692 kbps
1000 kbps
The problem is that no matter which bit rates I enter, I always get a file with a bit rate higher than 1900 kbps. (1914 kbps with the code example above.)
What am I doing wrong?
libvpx is a little complicated with regard to rate control and quality settings. Please refer to the vpx Encoding Guide and the VP8 Encode Parameter Guide for more info. It took me an hour of digging through the source code to understand it.
If you want to set constant bitrate, you will have to set b:v, maxrate and minrate to the same values, for example like so (note that I left out the audio options here for brevity):
ffmpeg -i input.mov -c:v libvpx -b:v 1900K -maxrate 1900K -minrate 1900K output.webm
If instead you want to use variable quality and just specify the upper bound for the bitrate, then you need to set both b:v and crf. If you leave out crf, the specified bitrate will just be taken as an average. Only with crf, the encoder changes the meaning of b:v to the maximum allowed rate.
ffmpeg -i input.mov -c:v libvpx -b:v 1900K -crf 10 output.webm
A value of 10 for the CRF is a good starting point, but libvpx may change the quality per frame within the bounds of qmin ≤ q ≤ qmax, which you can also specify if you want. Setting a lower bound of 10 for qmin seems a little high to me, but in essence you'll have to do some trial and error anyway, since if the maximum bitrate is too low, you'll constantly saturate it.

ffmpeg vstats problems, Missing frames and misleading information!

The Problem I have is when using ffmpeg to encode a YUV using libx264 I don't get all the frame information in -vstats output. It raises the question of how reliable ffmpeg is, and therefore can any 'codec benchmark' review based on ffmpeg be trusted?
I am analysing codec's to determine how they perform. I am using ffmpeg and its -vstats option to look at an encoded movie frame by frame. the process I use:
RAW YUV -> bar-code each frame with frame number -> Bar-coded YUV
Bar-coded YUV -> encoded (e.g. with libx264) -> MKV -> Decoded to YUV
I can compare the two outputs ('Bar-coded YUV' & 'Decoded to YUV') using the bar-code in each frame. I can then compare, exactly, an original frame with an encoded frame using PSNR etc.
When encoding using libx264 and libdirac, there are some frame information which is missing. Other codecs, such as mpeg2video or even libvpx, don't have this problem.
I have found that libx264 vstats are missing for the first 40 to 50 frames. I have since proved that the missing information is actually the last 40 to 50 frames.
It also looks like ffmpeg calculates average bitrate based on the information in vstats. But as there is missing frames the average bitrate is less than what it should be.
Below are links to the average bitrate error example:
http://dl.dropbox.com/u/6743276/ffmpeg_probs/ffmpeg_av_bitrate_error.png
http://dl.dropbox.com/u/6743276/ffmpeg_probs/ffmpeg_av_bitrate_error.xlsx
Below is a link to the PSNR & f_size graph:
http://dl.dropbox.com/u/6743276/ffmpeg_probs/frame_mismatch.png
Below is a link to the output & command line options:
http://dl.dropbox.com/u/6743276/ffmpeg_probs/stderr.txt
I think this is also a bug, anyone clever enough to work it out might want to follow this tracker:
http://roundup.ffmpeg.org/issue2248
I have just discovered something which makes me very red in the face!! quite annoyed, but never mind :)
A fellow ffmpeg user pointed out that ffprobe should output more frame info, which it did. here is a link to his handy tip:
http://forums.creativecow.net/thread/291/71
Using this I found the following:
Actual average bitrate (ffprobe data): 8355.2776056338
Actual average bitrate (ffmpeg vstats data): 8406.23275471698
Ffmpeg -vstats avg_br: 7816.3
Reproduced above: 7816.32168421053
Ffmpeg standard error output 'bitrate=': 8365.8
Below is a link to my workings out:
http://dl.dropbox.com/u/6743276/ffmpeg_probs/ffprobe_vs_ffmpeg-vstats.xlsx
What I have discovered is I should have been using the average bitrate info from ffmpeg standard error output, it looks like the most reliable!