Marth64 changed the topic of #ffmpeg to: Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: https://ffmpeg.org/bugreports.html | Wiki: https://trac.ffmpeg.org/ | This channel is publically logged | FFmpeg 7.1 is released
<bray90820>
How much ram is recommended for ffmpeg
ryoskzypu has joined #ffmpeg
yakubin has quit [Ping timeout: 265 seconds]
minimal has quit [Quit: Leaving]
<BtbN>
however much the stuff you want to do needs
<kepstin>
if you're encoding high resolution video using software video encoders with deep lookahead, "lots"
<bray90820>
I'm encoding 1080P video from mp4 and mkv to mp4 I currently have 32gb ram is that eough?
<kepstin>
why would you even be encoding video for that? in many cases the codecs would be compatible so you can just copy
<bray90820>
Spesifically I'm using ffmpeg -i "input.mp4" -c:a copy "output.mp4"
<kepstin>
you could get by with a few hundred mb of ram then
<kepstin>
er, wait, "-c:a copy"? why not "-c copy"?
<kepstin>
"-c:a copy" only copies audio, meaning video will be re-encoded. You can probably copy everything.
<kepstin>
if you _do_ want to re-encode the video, then you should make sure to specify which encoder you want to use, and options to use it with.
<kepstin>
(assuming you want h.264 video at 1080p encoded with libx264, that's still probably something which would need a few gigs of ram)
gchound has quit [Quit: WeeChat 4.1.1]
<aaabbb>
32gb is fine for most things, at least most user type workloads
<Marth64>
-max_interleave_delta is a ram sensitive option careful with that if you ever need it
<bray90820>
What's a normal speed for ffmpeg as well
<aaabbb>
there's no such thing. it depends on your hardware, the video content and type, what you're encoding to and from etc
<aaabbb>
but if you are doing remuxing, ie "-c copy", then it should be about as fast as your disk speed
<aaabbb>
but a "normal speed" that i come across in my workloads range from 300x realtime to 0.05x realtime. so lots of variation...
<aaabbb>
bray90820: you probably don't want to just do "-c:a copy" because if you are re-encoding the video, you will cause a quality loss
<bray90820>
aaabbb: I have peen using -c:a copy for years it really saves space and unless I put them side by side I can't tell the difference in video quality
<aaabbb>
you can save even more space by using good presets or a better codec
<bray90820>
My average sped is 3.00X
<aaabbb>
3x for 1080p means you're both losing a lot of quality and not gaining nearly as much space savings as you otherwise could
<bray90820>
I'm ok with what I get
<aaabbb>
ok, but you could be getting 50% smaller and probably twice as good quality with the right settings :)
Muimi__ has joined #ffmpeg
<bray90820>
How?
<aaabbb>
using libsvtav1 or libx265 instead of the default (libx264)
<bray90820>
I'll look into that
<bray90820>
Would I get faster speeds?
<aaabbb>
you can even precisely control the size of the resulting file
Muimi__ has quit [Remote host closed the connection]
<aaabbb>
you wouldn't get faster speeds, *but* at the same speed you'll still get better quality. generally slower means better quality
<aaabbb>
i've had some source videos in older formats that were 3gb shrink to 200mb with almost no noticible quality change
<bray90820>
Damn ok that's amazing
<aaabbb>
the default for ffmpeg for mp4 is the libx264 encoder with the "medium" preset, which is pretty low quality (and that encoder uses a 20 year old format!)
^Neo has quit [Ping timeout: 276 seconds]
<Traneptora>
well H.264 has been battle tested for 20 years
<Traneptora>
it's like JPEG. it's a good standard
<aaabbb>
it is, and it's mature and has great compatibility. but if it's just for personal watching and you don't need to be compatible on 10yo smart tvs and kindle fire tablets, then you can go with something more efficient
vulpine has quit [Read error: Connection reset by peer]
vulpine has joined #ffmpeg
vulpine has quit [Max SendQ exceeded]
vulpine has joined #ffmpeg
vulpine has quit [Excess Flood]
vulpine has joined #ffmpeg
vulpine has quit [Excess Flood]
vulpine has joined #ffmpeg
vulpine has quit [Excess Flood]
vulpine has joined #ffmpeg
vulpine has quit [Excess Flood]
vulpine has joined #ffmpeg
vulpine has quit [Max SendQ exceeded]
<Traneptora>
idk I like the low complexity
<Traneptora>
hard drive space saved by recompressing stuff to av1 is not worth it to me to have to wait for it to encode
vulpine has joined #ffmpeg
vulpine has quit [Max SendQ exceeded]
<aaabbb>
generally yes but if your goal is to save space then it's worth it
<aaabbb>
and if you're re-encoding a library to save space it certainly is
<aaabbb>
the thing i like about h264 is that it is often the best at almost lossless encodes, with no smoothing
vulpine has joined #ffmpeg
vulpine has quit [Excess Flood]
<Marth64>
I also just find myself circling back to h264 (although I don't need to maximize space savings as my goal which is understandable)
<aaabbb>
h264 was the first "good video format" and coincided with x264 being the first "good encoder"
vulpine has joined #ffmpeg
vulpine has quit [Excess Flood]
vulpine has joined #ffmpeg
vulpine has quit [Excess Flood]
vulpine has joined #ffmpeg
NotWarcop has joined #ffmpeg
Warcop has quit [Ping timeout: 276 seconds]
olndrxyz has quit [Quit: Quit]
vtorri_ has joined #ffmpeg
MisterMinister has quit [Ping timeout: 252 seconds]
yakubin has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
Marth64 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg
zsoltiv_ has quit [Ping timeout: 248 seconds]
Marth64 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg
System_Error has quit [Remote host closed the connection]