I have been using ffmpeg Media Encoder to transcode video into h.265. It has a number of built-in scripts, and the h.265 one has the video quality as -q:v 5. I’m really pleased with that combination of quality vs. size. I also am using the ffmpegYAG shell on the PC, but it uses -cfr to determine the bitrate. What I’d like to find is the -cfr setting that gives the sameish file size as -q:v 5 in the Android shell. (The transcoding on either platform is so painfully slow that I don’t want to have to resort to trial and error.)
According to this page, crf is the real parameter. The qscale also depends on the frame rate. Maybe try crf=22 ? (Disclaimer: just a guess and I haven’t tried anything) This should be better than default quality.
In addition to the crf, there are also encoding speed presets, veryslow up to ultrafast (default medium)
But the -q:v 5 is a “real” setting, too. On the android app, the settings for a specific file gives the command line
and on ffmpegYAG, it gives the command line
So they actually use the respective settings in the commands sent to ffmpeg, it isn’t just a simplification in the UI.
Are you sure that the qscale is making a difference on h265? IIRC, that only affects mpeg4 codec; crf is definitely the thing to use for h265.
h265 is completely different than mpeg4, though, and offers much, much better compression, so there’s not really any point to say “quality vs. size” when comparing both of them. Is your objective to get an h265 file that’s the same size as an mpeg4 stream? If so, you’d expect higher quality. If you’re looking to maintain quality, then the file size will be smaller than the same mpeg4. What’s your priority?
FWIW the libx265 docs mention a bunch of parameters, including crf (0 to 51, default 28), but none of them is qscale; the only thing that might fit is --qp or -q <0 to 51> which is constant quantizer rate control, but then that doesn’t seem consistent, as 5 would be a really low value, a qscale of 5 corresponding to a QP of about 27 or so according to the formulae on the page I linked to before.
No, my objective is to get file x to be the same size/quality if I run it on the PC as it would be if I ran it on the phone (because I’m happy with the phone’s output.) If file x transcoded to a 250 MB h.265 on the phone, I want the setting that will make file x transcode to a 250 MB h.265 on the PC. Since both transcode at a rate of around 5 frames per second or less, it would be time-consuming to do it by trial and error.
There is an easy way to resolve this definitively. On the platform with the mysterious quality option, start encoding a video as usual but pass the --csv and --csv-log-level options as described in the documentation, with the log level set to 1. The resulting file will tell you the actual QP and RateFactor for every encoded frame, which you can use to derive the crf. You only need a relatively short, representative clip, so the test should not take long.
So, I tediously found a solution to my compression level experiment, but a new discovery in case anyone else runs into a similar issue and happens to read this thread.
As I mentioned in my first post, I was using ffmpegyag as the shell for ffmpeg/h.265 on the PC. I had assumed that the various shells available would run the codec at roughly the same incredibly slow speed. Well, recently I found that my many-years-favorite but long-in-the-tooth open-source video editor, Virtualdub (which I thought had been abandoned for development years ago) has an updated fork with support to modern codecs and containers. When I started trying transcoding files to h.265 in Vdub2, I immediately saw that it was much faster. How much faster? I transcoded a sample video ( 704x396 VC-1) on ffmpegyag and got a frame rate of 9.8 fps. With the ffmpeg h.265 settings in Vdub2, set to the same quality? 104 frames per second. More than 10x as fast. That floored me–I don’t know what the hell ffmpegyag is doing wrong to make encoding so slow, but it gave me a totally false impression on how slowly the codec works.
I know this may be gibberish to most of you, but hopefully my passing it along can help someone.