Will have to be the next path to try. Im not home tonight though
1 Like
Ahhhh, ok. We can make that work. Iāll take a stab at it at some point this week. You giving me this info really helps me diagnose this quick 
My camera records at constant bit-rate, but that is like 600MB (Byte!) per minuteā¦
VBR with very high (or uncapped) is handy, I am facing skill issues with getting consistent image quality when recording in VBR though, so I am sticking to CBR.
I am encoding all my movie-rips using VBR and live with minor blocking.
Do we want arch, or is Ubuntu acceptable? Arch doesnāt tend to do super well for containers. Honorable mention to Alpine. Lightweight, fast to build with, etcā¦
2 Likes
Yeah as far as I can tell its about having the correct base distro, libs and drivers
Arch probably easiest?
Oh fuck yeah alpine if we can
Alpine + s6 or runit any day 
ā¦ Minimal container sounds great
Alright, as prep, can anyone get me a list of libs, drivers and dependencies? Like anything special. The obvious ones can be left out.
Yes.
I imagine weāre more concerned about ffmpeg right now.
1 Like
tdarr, proper intel nvidia and amd gpu drivers, ffmpeg, handbrakecli, mkvpropedit. I think tdarr has a proper updater app that downloads tdarr and stuff. Not sure about ffmpeg or handbrake though.
What would be the best way to pull these for you. (It usually defers per OS)
Ahh yeah this for meta data sarge. Argone and I found out you cant inject the proper metadata without it
1 Like
I guess it depends on the medium it is recording to and how that entire stack is set up? I mean recording is effectively streaming, just not to a network location but rather to some kind of medium, so depending on the medium used it might be problematic with VBR (similar to VBR in network-streaming applications).
Depending what kind of encoder they use (probably hardware) that might also be a limitation.
Regardless, in 90% of usecases that is going to be way overkill (i.e. the aforementioned waste of space). At that point you might as well just record in a lossless codec which would probably even be more efficient.
For post-process encoding you can just do Multipass and avoid a lot of the quality pitfalls. But regardless thereās not really a one-size-fits-all encoder setting for good quality vs. reasonable filesize.
AFAIK BlackmagicRAW is lossless.
ā¦visually lossless. Itās like DSC for DisplayPort. Youāre still losing some info but itās designed to be visually lossless.
HuffYUV and FFV1 are truly lossless.
1 Like
Arenāt there different profiles? I seem to remember reading BM RAW has actual lossless too (although I wouldnāt be surprised if thatās just people mixing up terms).
I found that to be not great for recording, I found utvideo to be more useable for real-time encoding, but that probably varies on the usecase. Only downside was that I couldnāt load the utvideo files in Blender so I had to transcode them to FFV1 and that worked 
No, the ratios tell you how much itās compressed. Thereās no true lossless as it goes by the ratios, like DSC always uses a 4:1 ratio.
I am going to post results of video encode vs svt (cpu) for av1 in a bit. Will compare same crf settings. Will post vmaf, ssim an psnr results.
What I am finding with qsv is it doesnāt handle grain/noise very well. Older sources pre 2012 have to have a higher crf set for better sizes. I would advise you either set cbr or have an input folder separate from your jellyfin library. Move easier to encode sources first and then stuff like breaking bad and the walking dead. Older sources when blurays started being more popular are generally worse sources. Require more bitrate to look better because they have heavy grain/noise.
I am finding icq(crf) of 22 is optimal for newer sources and 25 for older sources.
Why not use this across the board?