Weebs of Jow Forums

I use this, maybe you can get some use out of part of it

#!/bin/bash

#time format == HH:MM:SS.Milliseconds
#$1 == (start time)
#$2 == (end time)

parseSeconds() {
splitString=(${1//:/ })
hours=${splitString[0]}
minutes=${splitString[1]}
splitArr=(${splitString[2]//./ })
seconds=${splitArr[0]}
totalSeconds=$(($((hours * 60 * 60))+$((minutes * 60))+$((seconds))))
echo $totalSeconds
}

#convert start/end time in time format to just seconds
startSeconds=$(parseSeconds $2)
endSeconds=$(parseSeconds $3)

#filesize = bitrate * duration
#bitrate = filesize / duration
targetFilesize=31948
lengthSeconds=$((endSeconds - startSeconds))
targetBitrate=$((targetFilesize/lengthSeconds))

#-y sends yes for replacing and handling 2 pass
#output debug info from first pass to /dev/null
ffmpeg -y -i "$1" -ss $2 -to $3 -c:v libvpx -an -sn -b:v $targetBitrate"k" -threads 12 -preset slower -pass 1 -f webm /dev/null && ffmpeg -i "$1" -ss $2 -to $3 -c:v libvpx -an -sn -b:v $targetBitrate"k" -threads 12 -preset slower -pass 2 $4

Sorry, forgot the (you)

Many thanks. Is it okay to omit -threads? My PC is only dual core.

Yeah, I editted it a bit to work better with longer webms, to use 2 threads, and only do single pass since double pass takes a while on a dual core

#!/bin/bash

#time format == HH:MM:SS.Milliseconds
#$1 == (start time)
#$2 == (end time)

parseSeconds() {
splitString=(${1//:/ })
hours=${splitString[0]}
minutes=${splitString[1]}
splitArr=(${splitString[2]//./ })
seconds=${splitArr[0]}
totalSeconds=$(($((hours * 60 * 60))+$((minutes * 60))+$((seconds))))
echo $totalSeconds
}

#convert start/end time in time format to just seconds
startSeconds=$(parseSeconds $2)
endSeconds=$(parseSeconds $3)

#filesize = bitrate * duration
#bitrate = filesize / duration
targetFilesize=$((30000))
lengthSeconds=$((endSeconds - startSeconds))
targetBitrate=$((targetFilesize/lengthSeconds))
targetBufSize=`bc

Is hevc worth it? Also I'm assuming anime doesn't go up to 60fps eh?

Low bitrate encodes? Yes. High bitrate? If you have the crunching power or the time and copy a good group's settings you can see a reasonable reduction in size, but less so than at low bitrates.

Is hevc = x265? I'm not an expert but I prefer that to the regular one because small filesize.

I mean as a watcher, not encoder.

Just use VBR with qmax. qmax 50 is good start as minimum quality. Calculate the bitrate based on the file size limit and the length of the footage.
video_bitrate = size_limit_in_MB * 8 * 1000 / length_in_sec - audio_bitrate

libvpx doesn't have the preset option like libx264. You can choose between deadline (or quality; both have the same effect) best, good or realtime (default is best). Good and realtime can also be used in combination with cpu-used (I think speed works as well). For good you can set it from 0 (slowest) to 5 (fastest). Realtime can go up to 15 or 16. I don't use it, so I'm not quite sure.
Usually -deadline good -cpu-used 0 is the way to go. Produces pretty much the same results as best, but can be twice as fast in some cases. For the first pass use -deadline good -cpu-used 5, as it is faster and has no negative impact.
Also -threads 12 won't be utilized. libvpx determines the number of max. threads used via the video width. width / 500 (and the result always rounded down) is the max. number of threads utilized. So e.g. for a 1920x1080 video you can use 1-3 threads, not more.

>Calculate the bitrate based on the file size limit and the length of the footage
Won't that result in a file that's always at the maximum size limit?

Is using Sony Vegas pro to convert stuff considered encoding?

>Sony Vegas pro to convert stuff
why the fuck would you do that? It's like acquiring a whole car manufacturer just to commute to work
use ffmpeg or Handbrake if you're not good with cli

Yes, and in the best quality possible in that file size.

>Won't that result in a file that's always at the maximum size limit?
Basically. It's no exact science though. You might need to adjust the video bitrate based on the footage.

>4:4:4 720p
Autism. Just stop here.
4:2:0 8bit 720p with a decent bitrate is all you need.
ffmpeg -i foo -pix_fmt yuv420p -c:v libx264 -preset slow -crf 18 bar.mkv

Try HEVC too if you can decode it.

960x721
anamorphic widescreen
1 mbps cbr
10 bit
vp9

>8bit
No.

rxmastering.wordpress.com/

Thanks, user. I don't know a shitton about encoding, I just skimmed the man pages and did some simple math to calculate the desired bitrate.

>4:2:0
Disgusting

Attached: [MD] Arpeggio of Blue Steel 01 - The Masters of the Shipping Routes (1280x720 Blu-ray AAC) [E3D44432 (1280x720, 976K)

4:4:4

Attached: 01-1 (3).mkv_snapshot_05.50.png (1280x720, 1.03M)

>order of -i and -ss determines the method of seeking
Why the fuck am I just now finding this out?

This works fairly well but I had to add variable filesize based on duration. Currently I am using

length >= 90s 28000
length >= 60s 32000
length >= 30s 35500
length

What's bufsize

"-bufsize specifies the decoder buffer size, which determines the variability of the output bitrate "

Higher value means it has more variance, lower value keeps it closer to the desired average bitrate.

HEVC is trash for anime right now and the only people that use it don't know what they're doing.

Wouldn't it be good for an older SD show like DBZ? Since it is a lower bitrate wouldn't you get a smaller filesize?

Could you please explain why?

Why? It supports 10-bit and the banding doesn't seem any worse.