lusciouslover has quit [Ping timeout: 260 seconds]
waleee has quit [Ping timeout: 240 seconds]
whupdup has quit [Quit: Going offline, see ya! (www.adiirc.com)]
waleee has joined #ffmpeg
chowbok has joined #ffmpeg
halvut has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 260 seconds]
waleee has joined #ffmpeg
halvut has joined #ffmpeg
Shuriko has quit [Ping timeout: 252 seconds]
Shuriko has joined #ffmpeg
waleee has quit [Ping timeout: 264 seconds]
minimal has quit [Quit: Leaving]
waleee has joined #ffmpeg
halvut has quit [Quit: quit]
waleee has quit [Ping timeout: 248 seconds]
bertieb has quit [Ping timeout: 240 seconds]
waleee has joined #ffmpeg
bertieb has joined #ffmpeg
Shine has joined #ffmpeg
<aaabbb>
with libx264, using a higher preset for a given crf reduce file size at the expense of encode speed
<aaabbb>
but with libx265, why does the file size generally increase?
<aaabbb>
does this mean that i'll have to increase the crf when slowing down the x265 presets if i want it to have the same behavior as x264?
<aaabbb>
i'm looking for a way to tell libx265 "keep the quality the same but reduce the file size even if it takes longer to encode"
hightower4 has joined #ffmpeg
Shine has quit [Read error: Connection reset by peer]
hightower3 has quit [Ping timeout: 258 seconds]
<BtbN>
higher crf does not mean "reduce file size"
<BtbN>
It means reduce quality
<aaabbb>
i'm aware, but for a given preset, it also happens to reduce filesize
<BtbN>
not neccesarily, no
<aaabbb>
but it's true in the general case right?
<BtbN>
Something that achieves better quality might in turn also reduce the file size. And in the other direction, when that feature gets turned off by the higher value, size can go up
<BtbN>
it's not an exact science at all
<aaabbb>
as for presets, with x264 i'll increase the preset as high as i'm comfortable with and i see that as meaning "take more time to make the file small, giving me whatever quality i asked for from the crf"
<aaabbb>
is that a wrong interpretation?
<BtbN>
that's generally what it does, but again, lots of details
<BtbN>
a preset is literally what the name says: A preset for A LOT of little knows of the encoder
<BtbN>
*knobs
<BtbN>
And crf is some magic x264 thing, that associated "something something quality" to a number
<aaabbb>
i've played around with the individual knobs a lot and i know the basics behind how most of them work, but what i don't get is why x264 and x265 don't behave the same with presets
<BtbN>
Cause they're totally different encoders? Not sure what you mean with "behave the same"
<BtbN>
crf is pretty much an invention of x264. And a lot of other encoders adopted the idea, but it's not any defined thing, they all interpret it however they like
<aaabbb>
so if i want to keep the quality for x265 the same, but decrease the file size at the expense of encoding performance, what would i do if not use presets?
<BtbN>
Quality the same as compared to what?
<BtbN>
And how do you define quality?
<aaabbb>
crf is a meh approximation, psnr and vmaf are better ones i guess
<BtbN>
Again, the meaning of a specific "crf" is vastly different with just x264
<BtbN>
crf 20 at slow-preset will produce a different result than crf 20 at ultrafast
qaph has joined #ffmpeg
<BtbN>
It's an entirely arbitrary number
<BtbN>
All that's sure is the lower it is, the better the quality, by whatever definition the encoder uses for that.
<aaabbb>
if i use a slower preset, is there any chance the quality will go down (ignoring pathological cases)?
kron has quit [Ping timeout: 258 seconds]
<aaabbb>
like if slower is 10% larger than slow for a given crf
<BtbN>
It's at least possible that the same crf value for a slower preset will result in worse quality. Not by a large margin usually, but it's absolutely possible
<aaabbb>
but only for pathological cases, right? not typical ones?
<aaabbb>
i can imagine that there are situations where me=star is actually worse than me=hex but not the typical ones
<BtbN>
no, it's arbitrary
<aaabbb>
oh
<BtbN>
the meaning of the crf values can change if a slower preset turns on more advanced features
<BtbN>
like I said, the number is absolutely arbitrary
<BtbN>
If you want to achieve a certain quality reliably, the only thing you can do is to manually experiment your way towards it
<BtbN>
and you need some good quality score, first of all
<BtbN>
Or you can just eyeball it, "looks good enough to me"
<aaabbb>
i have a large number of videos that are all encoded using different encoders, codecs, frame rates, dimensions etc and i've been trying to find a good heuristic to maximize quality while keeping file size low, and taking advantage of my fast processor
<BtbN>
And you'll of course need to do that again for every video you encode, cause the encoder might behave differently depending on what it's dealing with
<aaabbb>
what i do right now is set the slowest preset that i can tolerate (which is usually what i've read is best practice), and reduce crf until the video looks good enough and the file size isn't too big
<aaabbb>
should i be doing something different?
<BtbN>
The best thing you can do to optimize quality is to not re-encode a video that's already encoded with a lossy codec
<BtbN>
Quality can only ever go down, never up
kron has joined #ffmpeg
<BtbN>
But what you've been doing is the usual way to do that, yeah
<aaabbb>
when i have a 400mb mpeg1video using pcm audio where 6 out of 7 frames are near duplicates, there's pretty much no reason not to encode it to hevc with mpdecimate and opus to bring it down to 4mb with no noticiable quality problems
<BtbN>
If you re-encode a lossy video, quality will always go down. Even if you use a better encoder, at the same bitrate than the input file. That's just the nature of lossy encoding.
<BtbN>
If you got videos like that, any modern encoder at near lossless settings will decimate its size, yeah
qaph has quit [Ping timeout: 264 seconds]
<aaabbb>
and most of my videos are like that, mpeg1video, mjpeg, xvid, so i have to reencode it
<BtbN>
well... storage is cheap :D
<aaabbb>
true, but when i give these videos to other people, if the size is high, they're gonna transcode it themselves, and they won't know how to do it right
qaph has joined #ffmpeg
<BtbN>
I could even see an actual lossless encoding of stuff like that to turn out tiny
<aaabbb>
haha yeah, one of the videos shrunk by half when using i think it was vp9 lossless!
thilo has quit [Ping timeout: 260 seconds]
<BtbN>
I'd probably run it through x264, some slowish preset, and crf 10 or something. Quality will be fine, and it's still gonna be much smaller
<aaabbb>
but since most of the videos have already been transcoded up to 8 times by people who have no clue how videos work, it's actually beneficial to preserve video quality when i transcode it myself, because the smaller size will tempt people less into thinking they need to reduce it
<aaabbb>
why x264?
<BtbN>
Cause absolutely everything plays h264
kron has quit [Ping timeout: 255 seconds]
<BtbN>
almost nothing plays hevc
<aaabbb>
everyone who needs to watch these videos will be able to play hevc so that's not a worry
thilo has joined #ffmpeg
<BtbN>
(depending on what you do, hevc can also be a patent hellhole)
<BtbN>
So if you need to worry about that, stay clear of hevc
<aaabbb>
it's not commercial luckily
<aaabbb>
so is my current strategy (slowest preset i can handle, lowest crf that doesn't give me a file that is too large, mpdecimate if needed) a good heuristic when i have a large number of videos to transcode?
<BtbN>
Unless you want to manually tune settings for every video, yeah
<BtbN>
I wouldn't worry about mpdecimate really
<BtbN>
a ton of identical frames will compress down to nearly nothing anyway
<BtbN>
just make sure you got decently long gops, not 2s or something
<aaabbb>
mpdecimate helps a lot, it can reduce it by sometimes up to 50%, especially because a lot of these videos come from vhs, so there are lots of portions that are frozen
<BtbN>
video encoders whole job is to detect changes, and use those changes to compress
<BtbN>
so if you feed them two identical frames, the second one will be basically nothing
<aaabbb>
they're never exactly identical because there are idiots who have transcoded them half a dozen times already
qaph has quit [Ping timeout: 264 seconds]
<aaabbb>
so sometimes i even have to tweak mpdecimate so it knows that two subsequent frames really are supposed to be dupes. as good as hevc is, i usually save 10% to 50% space using mpdecimate (and confirming that it's not dropping frames that it shouldn't drop)
bertieb has quit [Ping timeout: 264 seconds]
Capstan has quit [Ping timeout: 248 seconds]
<BtbN>
Doesn't mpdecimate result in a vfr video? I'm not sure I'd want that.
<aaabbb>
it doesn't have to result in vfr, but it's most efficient if you do (otherwise it just duplicates frames)
<aaabbb>
what's wrong with vfr? mkv and mp4 support that
<BtbN>
a lot of players have massive struggles
<BtbN>
Or flat out don't support it at all
<aaabbb>
i think that's only the case with mp4, anything that can play mkv can usually do vfr right? well even so, everyone who wants to view the videos i'm transcoding will be using the same few video players
<BtbN>
I wouldn't bet on it
<BtbN>
If you can re-duplicate those frames back to the original framerate, so the encoder can then properly ignore them... I'd strongly prefer that over vfr videos at least.
<aaabbb>
actually they're required to, if they aren't then they aren't permitted to have the videos anyway
<BtbN>
It's just an avoidable trouble-maker
<aaabbb>
maybe i should write a script that takes several seconds (or maybe several gops) from each video, transcode them with different settings, then compare the vmaf
<BtbN>
Then you are betting on the first couple seconds being representative of the whole video
<aaabbb>
random several seconds, not the first. like 5 seconds at 2 seconds in, 5 at 112 seconds in, 5 at 260 seconds in etc
<BtbN>
And specially the beginning is often very different than the rest, depending on what those videos are
<BtbN>
I think you are overthinking this really
<aaabbb>
from manual testing i've found that a few video are actually smaller and have a better psnr (didn't test vmaf) when i used me=umh for hevc instead of the usually superior me=star
<aaabbb>
hm
<BtbN>
just run it through your favourite encoder with quality settings that are definitely good enough, and call it a day
<BtbN>
As long as you don't intend to throw away the originals, you can always do it again for a specific video anyway, if the need arises
<aaabbb>
i'm tasked with maximizing quality since the originals are likely going to be discarded, which is why i'm not just encoding and forgetting
<BtbN>
well... that's a bit too arbitrary of a goal sadly
<BtbN>
The "maximize quality" move would be to losslessly re-encode all of them, and then pick the smallest between original and new one
<aaabbb>
i guess maximizing is the wrong word
<aaabbb>
maybe maximizing within the constraints of keeping a reasonable file size and encode time
<BtbN>
Then you are back to where you were. Either pick some reasonable "good enough" settings, and go with them
<aaabbb>
but certainly not maximizing because i have to denoise them and downscale them occasionally
<BtbN>
or hand-optimize for each individual video
<aaabbb>
ok so i guess i just have to spend more time learning how the various knobs work so i can hand optimize most effectively
<BtbN>
not really. Pretty much just pick a preset and crf value
<BtbN>
touching the literally hundreds of tunable x264 and friends have is not worth the time
<aaabbb>
because the improvement for hand optimization is so small?
<aaabbb>
another: so if i specify soxr then it'll use that instead of swr
<aaabbb>
in which case is there any reason to use precision=28 for 16-bit input (16 bit, but generated from adpcm)
Vedaa58193 has joined #ffmpeg
<another>
no idea. though opus' design philosophy is: if you actually worry about this, you shouldn't use a lossy codec
<aaabbb>
i know i'm just curious because i want to learn more about how these things work
<aaabbb>
i'm using -b:a 40k so quality isn't a big deal
l4yer has quit [Ping timeout: 255 seconds]
<termos>
https://trac.ffmpeg.org/ticket/4141 any patch pending for this? it's been open for a long time, and just had this issue, that's how i stumbled upon this ticket
<aaabbb>
another: -v debug is saying that SWR is used even when i have -af aresample=48000:resampler=soxr, is this because libopus is overriding what resampler is used?
<aaabbb>
[Parsed_aresample_0 @ 0x5fb4c3dc6f80] Setting 'resampler' to value 'soxr'
<aaabbb>
[Parsed_aresample_0 @ 0x5fb4c3dc6f80] [SWR @ 0x5fb4c3dc7740] Using s16p internally between filters
<aaabbb>
it can't be that because that message is there when saving as a wav, does ffmpeg call any resampler SWR, and both libswresample and libsoxr are reported as "SWR"?
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
fling has joined #ffmpeg
Blacker47 has joined #ffmpeg
l4yer has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
l4yer has quit [Ping timeout: 248 seconds]
Vedaa58193 has quit [Read error: Connection reset by peer]
billchenchina has quit [Remote host closed the connection]
hbbs has quit [Quit: bye]
hbbs has joined #ffmpeg
hbbs has joined #ffmpeg
hbbs has quit [Changing host]
shibboleth has joined #ffmpeg
sonicrules1234 has quit [Remote host closed the connection]
markkastoun has quit [Read error: Connection reset by peer]
Nik- has joined #ffmpeg
flom84 has quit [Quit: Leaving]
YuGiOhJCJ has joined #ffmpeg
markkastoun has joined #ffmpeg
sonicrules1234 has joined #ffmpeg
onla has joined #ffmpeg
<onla>
Not sure what is the right place to ask, but I am trying to batch use ffmpeg -i file -ss <start> -to <end> -c copy out.opus but for some reason something goes wrong at some point https://bpa.st/LZSA
<Trel>
onla: Try having your variables "${likeThis}"
<Trel>
instead of "$likeThis"
Ogabaga has quit [Quit: Konversation terminated!]
Ogabaga has joined #ffmpeg
<onla>
particularly on the ffmpeg line in the code right?
function1 has quit [Ping timeout: 264 seconds]
function1 has joined #ffmpeg
<onla>
hmm, I put it running with that line being ffmpeg -i "${audio_file}" -ss "${start_time_with_colons}" -to "${end_time_with_colons}" -c copy "ru/${filename}" but still it happens.. Parse error, at least 3 arguments were expected, only 1 given in string 'ity, which killed six people
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #ffmpeg
beaver has quit []
<vlt>
onla: I’m just guessing here but maybe the problem is line 29.
<vlt>
onla: You’re piping the subtitle file to the for loop and ffmpeg seems to not like that.
<vlt>
onla: You could adapt line 12 to something like `cat "${subfile}" | while read line; do`
ZedHedTed has quit [Quit: leaving]
kasper93 has quit [Remote host closed the connection]
<Trel>
onla: You're reading lines from the file, no?
<Trel>
The time codes and the text aren't on the same line. What does your while loop try to do when the line is text?
<Trel>
I think you need to validate your inputs before calling ffmpeg with them.
<Trel>
Pretty sure your start time string in those cases is the entire line of text
<Trel>
and end time is empty
<onla>
yeah reading from file. It's supposed to run the if loop only when timestamp line matches, other lines should be ignored. The parse error had text from other than timestamp line
<Trel>
onla: what line does the check for a timestamp and doesn't call ffmpeg?
<Trel>
I don't see any such control in the code l
<Trel>
*code
<onla>
if [[ $line =~ ^[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\.[0-9]{3}.*[0-9][0-9]:[0-9][0-9]:[0-9][0-9]\.[0-9]{3}$ ]]; then <--Isn't everything under this only executed if line is a timestamp line
<Trel>
Not sure, what is that from?
<onla>
I didn't create that regex myself, but it has worked at least somewhat, this script, but just some problems
<Trel>
oh you had two links, gimme a moment
<onla>
ah, yep. The other one has the full file
<onla>
there was a mysterious problem with colons too, but once I added the code to put colons back when they were not supposed to be removed with that awk anyway, I noticed they didn't get removed in all cases either, so I had to strip them away again so it's not very optimized looking code. Something mysterious with the colons in timestamp was going on
Keshl has quit [Ping timeout: 258 seconds]
Ogabaga has quit [Quit: Konversation terminated!]
<onla>
but I got an idea I can try a bit later. I put it executing again and interrupt it immediately when I see a red message and then I see how many files it has created and try locate the subtitle portion that first creates the problem. Then I edit the subtitle file to only have small bit where the problem occurs and we can look why some part of subtitle might cause a problem. But better of course if
<onla>
something is clearly wrong in code
Ogabaga has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
taupiqueur_shiny has joined #ffmpeg
fart-omelette40 has quit [Read error: Connection reset by peer]
fart-omelette40 has joined #ffmpeg
MrZeus_ has joined #ffmpeg
kasper93 has joined #ffmpeg
MrZeus__ has quit [Ping timeout: 248 seconds]
lusciouslover has joined #ffmpeg
lavaball has joined #ffmpeg
jess has joined #ffmpeg
minimal has joined #ffmpeg
P1RATEZ has joined #ffmpeg
lusciouslover has quit [Remote host closed the connection]
lusciouslover has joined #ffmpeg
<Trel>
onla: why not drop the ffmpeg command and make it an echo so you can see what it does before you try executing it?
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
Hopeful5155 has quit [Ping timeout: 255 seconds]
lavaball has quit [Remote host closed the connection]
Nik- has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vlm has quit [Remote host closed the connection]
lusciouslover has quit [Remote host closed the connection]
lusciouslover has joined #ffmpeg
Capstan has quit [Quit: Client closed]
Capstan has joined #ffmpeg
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #ffmpeg
javabean has quit [Ping timeout: 240 seconds]
javabean has joined #ffmpeg
lusciouslover has quit [Ping timeout: 240 seconds]
Capstan has quit [Ping timeout: 248 seconds]
lavaball has joined #ffmpeg
ivanich has quit [Remote host closed the connection]
ivanich has joined #ffmpeg
ivanich has quit [Remote host closed the connection]
ivanich has joined #ffmpeg
ivanich has quit [Remote host closed the connection]
Ogabaga has quit [Quit: Konversation terminated!]
Ogabaga has joined #ffmpeg
taupiqueur_shiny has quit [Remote host closed the connection]