Hello all,
Just recently started using MCEBuddy.
I am trying to convert some of my library of videos to x265 to save on some space.
Some of the converted videos are lower bitrate than the original and take up about 25% less space where as some other videos are higher bitrate than the original and take up about 25% more space.
Does anyone know why using the same profile some videos are lower and some higher than the original and/or know how to prevent that from happening?
Are the original resolutions the same? The x265 encoder works on a sliding scale of very lossy to placebo lossy, and isn’t really set using a “bitrate” setting.
I’m doing the same thing from OTA recording and have 2 profiles, one for HD recordings and another for SD recordings. For the HD recordings, I can set the profile to be more “lossy” (e.g. 25 to 27) than I can with the SD recordings (20-25).
If I’m after-the-fact transcoding, I will use Handbrake using a similar selection of a custom profile. I am also using a recent nightly build of Handbrake as well.
I’m still going to (one day) spend some time with Custom Cuts or the MCEBuddy command line to re-process files that don’t do any transcoding, just “refreshing” the metadata for the shows, since MCEBuddy embeds it all into the MKV container, and I have a lot of shows from several years ago when the metadata wasn’t as good as it is now with the explosion of streaming and everyone searching for content to stream.
No, I am working with SDTV, 720 and 1080.
Maybe I should create multiple profiles and somehow filter depending on resolution.
The problem is the lower quality files end up larger where the higher quality end up smaller. So if I set the SD files to be less lossy as mentioned this would make the problem even worse.
I noticed that Handbrake has a bitrate setting for x265 (no idea if it is functional or not).
If it is a parameter that FFMPEG or Handbrake can use, maybe @Goose can expose that in the GUI (or pass it in manually to the transcoder engine).
It would probably be helpful to prevent increasing the bitrate on any source media, but I don’t know if the existing average bitrate can be known, since it is an average, and the codecs are adaptive.
That would be great if there was a way of limiting the bitrate from ending up higher than the source.
If that could be opened up in the GUI that would be beneficial. It may be possible to even go into the config and add in that parameter. Not sure.
You could setup two (or more) profiles based on your input media bitrates and then manually select that profile via the command line (or only process that profile if the file is in a particular directory, and then drag’n’drop into the “right” folder for MCEBuddy to apply the right profile).
If bitrate were a metadata field that MCEBuddy can see without making a pass over the data (i.e. large file) to calculate the average bitrate, then I could see adding bitrate as a variable field placeholder that can be used in filtering or profile selection or filename processing logic somehow.
However, I don’t want to ask @Goose to keep adding stuff into MCEBuddy that is better handled through batch/script and command-line processing for these corner cases. Because everything he adds, he has to maintain and figure out how to keep it integrated into the UI and not end up cluttering up the app with a bajillion options or end up having to document and support a few people for one-off options buried in the configs. It’s a balance.
I understand, but seems like it would be beneficial to a lot of people to prevent larger file sizes. MCEBuddy can already tell the bitrate of the file so I wouldn’t think it would need to be a metadata field or anything specific/different.
Let me ask you this, I set up approximately 4 different profiles based on bitrates to somewhat solve the issue. I know there is a bitrate selection filter in the expert settings window.
My problem is let’s say I have a file that is 10,000 bitrate and I have a selection for anything greater than 2,000 and a selection for anything greater than 6,000. How can I just have it do the conversion task for the greater than 6,000 kbps bitrate task instead of doing both?
Would be nice if you could do a range selection.
If I can figure out how to get it to only do one conversion task/profile I can manage to work around the issue and provide a more consistent conversion without some files being larger than original. This isn’t ideal, but could work well enough.
Thanks for the help.
If I can change something in a config file or something so MCEBuddy would do this that would be great, but was trying to avoid scripting commands manually and scheduling a task as that defeats the whole purpose/need of MCEBuddy for me unfortunately.
You can use the file rename and archive/delete after conversion to process the files in decreasing bitrate profile order. i.e. the 6K transcode profile then the 2K transcode profile. If the 6K transcode profile succeeds, the 10K file is processed and then no longer exists for the 2K transcode profile to fire.
Thanks Mike, thats actually what I was thinking about doing. Basically the jobs would be created, but only the first one would process.
This would work just fine I believe.
Unfortunately that didn’t work as intended. I can confirm it moved the file to the archive folder, but somehow it still converted it twice using 2 different profiles. It shows the original file was the exact same file in the events though.
Do you have the number of jobs processing simultaneously limited to just one?
If you allow multiple jobs, it will kick off the first one and then move on to the next one, and you need them to be sequential.
There’s no real benefit if you’re using HW transcoding since the two (or more) jobs will compete for the GPU, and the same for the CPU, since the transcoding can be tuned for multi-core usage as well.
Yes I do have it set to one. I will verify and test again though.
I really don’t see how the next job worked.
Maybe I’m out of luck I don’t know.
It appears that the program waits to move the file until after all the conversion jobs for that file are complete. It converted it three times and moved it to the archive folder. That’s the only thing I can think of otherwise it shouldn’t be able to convert it after the first time.
There’s also a “wait until last accessed” parameter. Do you have that cranked down to zero or have you turned off the “update last accessed” flag in your filesystem?
You might have to upload the logs ornyour config to @Goose to look at. It’s an FTP site, and the how-to is posted here on the forums.
No I don’t but the “wait until last accessed” is set to one minute currently.
Okay, I may do that.
I have my delay set to 5 minutes. Maybe bump it up if there’s an “off-by-one” bug in there somewhere.
Thanks again Mike. I will try a higher delay.