Just finished building a new app that can automatically compress your entire video library, or just a file if you want. It uses algorithms to find the best way to compress each file, is capable of removing all of the pesky extra non-English audio and subtitles, and can encode quickly using an nvidia card or other hardware. I just compressed my entire Full Metal Alchemist library from 166gb to 6gb, without any noticeable loss in quality. (8 mins spent encoding per episode with file size going from ~3.6gb to ~130mb. With nvidia enabled, it takes about 2 mins, but only reduces to ~300mb)
I’ve had similar results across tens of thousands of movies, and hundreds of thousands of episodes. Originally, I designed this for myself as my library had exceeded 1pb, and used this to compress it to all around 100tb. I’ve now added a gui and packaged it for public release.
Let me know if this works great for you, and if you’d like me to add any new features. It requires .NET 4.8, so make sure you’ve got that runtime installed.
How do you determine what the best compression method is? Does it know to use different methods, say live action vs animation?
A few enhancement ideas –
It would be great to see the ffmpeg command line used for compression in the log. A picky user may want to do a manual re-encode after tweaking some parameters.
If it is possible to estimate the space savings for a run, then a “preview” function would be cool.
Some people insist on keeping separate 4k and 1080p libraries. You could add toggles to allow for creating 1080p files from 4k files, if they are missing.
Some people like to add stereo tracks to all files, while leaving the surround sound tracks in place. That could also be a toggle.
Some people may wish to use the audio and subtitle features without re-encoding the video. Video re-encoding is kind of the point of the tool but you are well on the way to making a more broadly useful ffmpeg front end.
A possible bug–
During conversion the thumbnail does not update as expected, it’s stuck on an image from the opening credits.
A comment–
I am nervous about the options to remove non-English content because I fear a poorly configured file may not tag the languages properly, resulting in good content getting wiped. This may be an unrealistic concern!
Great suggestions. I’ll definitely implement some shortly. To answer the concerns: the preview is just a frame from 30 seconds in. I hadn’t thought of doing an animated one, but I suppose I could if that it was wanted.
As far as remove non-English options, it specifically looks for eng tagged ones. If they improperly tagged the audio or subtitles, it defaults to passing all of those through, rather than potentially removing good content.
As far as video, it’s designed to be a generalist. I’ve tested it on pretty much every type of content, and it seems to be “mostly” indistinguishable from the source. It does dynamically gather rate information before deciding if/what it should encode to. It doesn’t bother with stuff thats already a low bitrate or wouldn’t result in savings.
Somebody that knows ffmpeg really well and optimizes encodes for each file may not necessarily benefit from this, but I figured this would be a good tool for people without a huge knowledge of compression techniques and parameters. I could probably add in some content recognition to further optimize encoding for certain types of media, but it seems to do pretty well for me.
I’m definitely excited to see more people try it, so I can get a lot feedback and improve anything that could use it.
AMD and Intel hardware encode support.
The option to manually set the temp directory (Ramdrive)
x265 output support
How does Snacks determine which videos need conversion? I put 9 files which I’ve already converted manually using FFMPEG via MCE Buddy to see how it compares.
Out of those 9, it only found 3 to convert - How is it coming to that conclusion?
Also, I really don’t know WHY anyone who is going to convert their video collection would still choose to convert to h264. HEVC/h265 can really be played back my most if not all streaming sticks/Plex Plex Player apps.
It seems like a lot of effort for an old and inefficient video codec when newer ones have surpassed it in quality and ease of streaming.
update: A way to end/cancel an encoding would be helpful too.
I’m happy to test with various file types, and content types (water, waves, fast motion, trees/leaves, etc) to help you finetune your software, but since transcode EVERYTHING into x265 in my collection, it wouldn’t be useful to me.
Very cool, thank you for your efforts and for sharing your tool.
While my library is not near pb size, its getting large enough that I have (re)considered re-encoding a majority of the stuff that I don’t care so much about having super HQ.
But echoing above, I’d rather re-encode to x265 or AV1, to future proof the process, so to speak.
I just allowed it to run all the way through transcoding one file - it actually does appear to encode to x265 - but very slowly since neither of my systems use nVidia.
So it still leverages hardware even without an nvidia card, and it ONLY outputs to x265. That’s literally the point: to convert entire libraries into hevc. I don’t have a radeon card to test encoding with a similar speed to nvenc. Regardless, leveraging gpu exclusively results in a larger file size, so it’s worth the extra few mins per file if size reduction is the end goal.
I’m happy to add additional flags and hardware support if you prefer high speed encodes instead of smaller sizes.
Also, when batch converting, it specifically avoids x265 files with a sub-3000 bitrate. The reference target range is around that, so converting a 2500 bitrate x265 to 2500 bitrate x265 wouldn’t make a lot of sense, it would just potentially result in artifacts from running a pointless second almost-identical compression routine. There’s a lot more thought going into it than you think.
The goal is an absolute minimum file size while retaining as much quality as possible, which it achieves.
Just so you know, while it may work with Nvidia hardware transcode, it does not work with Radeon hardware x265.
For each video loaded, it says there is a file length mismatch, over and over.
software encoding works well but is terribly slow.
Yep, already added in AMD/Radeon, Intel QuickSync, as well as a target bitrate option. The code has been pushed, but I haven’t packaged a release yet. I’ll do that later today; got a job interview to head to first.
Hey guys, just made a new release to fix a bug that could potentially remove all audio tracks if the English tracks were tagged improperly. I’ll be adding in some new features soon like ram drive support. Also considering adding in the ability to merge same named local subtitle files. Let me know what you think or if you have more suggestions.
I know this is going to sound like a dumb (backward) request, but I would love a toggle option for MKV or MP4 file creation.
There are a majority of video files that I store in the MP4 extension so I can add/edit the metadata so that Plex can read the files, studio, distributor, genre, actors, description, etc.
Also, an 1800 target bitrate would be appreciated too. Certain videos I try to encode to be Comcast upload/stream friendly. ** Actually, I compared the file sizes between 1800 and 2000, and its very minor.
I can of course run it through Avidemux after the conversion has been completed, but that’s another manual step I would rather not introduce into my library duties.
I’m currently running Snacks side-by-side with my other transcoder and I’m really liking you results - especially with difficult to encode scenes - leaves blowing in trees, etc.
These are all great suggestions. I’ll start implementing them soon. And to answer your question, Snacks does indeed pass through audio unprocessed unless you select stereo audio only and no stereo track is available–in that case, it would convert any surround audio into a stereo format of 320kbps to maximize audio clarity.
An mp4 option has a few limits as far as which audio and subtitle formats work, so it may eliminate the ability to pass through certain things if you’re converting from another format. It mostly may require audio encoding which will add a small amount of time to the conversion, but I’ll definitely cool with baking in that feature.
While x265 really does save space when compared to h264 or h263 etc, I stopped thinking about it as only “space savings” when nearly all of my friends and family who stream have h265 decode capability.
While I still have quite a few movies and series with HBR h264 that require transcoding before delivery, it’s not because of the format (Plex will already transcode to h264) it purely becuase of their size compared to my upload speeds.
In your situation, I’d ask the people streaming to invest in a $30-60 Firestick, Roku etc, and transcode to h265.
It’s not like you can keep transcoding/converting videos in your collection everytime a new standard comes out - very quickly, all the “quality” of the video will be stripped from your videos and they will stop becoming enjoyable to watch.
I was using my AMD APU for years reliably until I got serious about quality and bought the cheap Intel A380 card.
Now in cases where a file needs transcoding, I’m able to stream with better quality and bitrates and not be concerned with harming my original videos.
Plus, Plex already has the capability you’re asking for built into the server, it’s called, Optimize.
