# ffmpeg question **URL:** \ **Category:** Factual Questions\ **Created:** [January 29, 2020, 11:06am UTC](https://boards.straightdope.com/t/ffmpeg-question/847158 "2020-01-29T11:06:53Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Darren\_Garrison](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/darren_garrison/32/92_2.png) [@Darren\_Garrison](https://boards.straightdope.com/u/Darren_Garrison)\ **Post date:** [January 29, 2020, 11:06am UTC](https://boards.straightdope.com/t/ffmpeg-question/847158/1 "2020-01-29T11:06:53Z")
I have been using [ffmpeg Media Encoder](https://play.google.com/store/apps/details?id=com.silentlexx.ffmpeggui&hl=en_US) 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.) ---
**Author:** ![DPRK](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@DPRK](https://boards.straightdope.com/u/DPRK)\ **Post date:** [January 29, 2020, 1:52pm UTC](https://boards.straightdope.com/t/ffmpeg-question/847158/2 "2020-01-29T13:52:48Z")
According to [this page](http://ramugedia.com/rate-control-of-x265), 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) ---
**Author:** ![Darren\_Garrison](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/darren_garrison/32/92_2.png) [@Darren\_Garrison](https://boards.straightdope.com/u/Darren_Garrison)\ **Post date:** [January 29, 2020, 5:20pm UTC](https://boards.straightdope.com/t/ffmpeg-question/847158/3 "2020-01-29T17:20:02Z")
But the -q:v 5 is a “real” setting, too. On the android app, the settings for a specific file gives the command line > [@](#): > > -i (input) -c:v libx265 -q:v 5 -c:a aac -ab 128k -ar 44100 (output) and on ffmpegYAG, it gives the command line > [@](#): > > -i (input) -f matroska -map\_chapters -1 -map 0:0 -map 0:1 -sn -c:a:0 aac -b:a:0 128k -c:v:0 libx265 -crf 28 -mbd:v:0 rd -mbcmp:v:0 rd -cmp:v:0 rd -precmp:v:0 rd -subcmp:v:0 rd -trellis:v:0 1 -y (output) So they actually use the respective settings in the commands sent to ffmpeg, it isn’t just a simplification in the UI. ---
**Author:** ![Balthisar](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/balthisar/32/2825_2.png) [@Balthisar](https://boards.straightdope.com/u/Balthisar)\ **Post date:** [January 30, 2020, 1:19am UTC](https://boards.straightdope.com/t/ffmpeg-question/847158/4 "2020-01-30T01:19:26Z")
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? ---
**Author:** ![DPRK](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@DPRK](https://boards.straightdope.com/u/DPRK)\ **Post date:** [January 30, 2020, 2:52am UTC](https://boards.straightdope.com/t/ffmpeg-question/847158/5 "2020-01-30T02:52:36Z")
FWIW the [libx265 docs](https://x265.readthedocs.io/en/default/cli.html#quality-rate-control-and-rate-distortion-options) 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. ---
**Author:** ![Darren\_Garrison](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/darren_garrison/32/92_2.png) [@Darren\_Garrison](https://boards.straightdope.com/u/Darren_Garrison)\ **Post date:** [January 30, 2020, 6:39am UTC](https://boards.straightdope.com/t/ffmpeg-question/847158/6 "2020-01-30T06:39:56Z")
> [@Balthisar](#): > > Is your objective to get an h265 file that’s the same size as an mpeg4 stream? 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. ---
**Author:** ![DPRK](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@DPRK](https://boards.straightdope.com/u/DPRK)\ **Post date:** [January 30, 2020, 3:46pm UTC](https://boards.straightdope.com/t/ffmpeg-question/847158/7 "2020-01-30T15:46:39Z")
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. ---
**Author:** ![Darren\_Garrison](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/darren_garrison/32/92_2.png) [@Darren\_Garrison](https://boards.straightdope.com/u/Darren_Garrison)\ **Post date:** [March 20, 2020, 6:31pm UTC](https://boards.straightdope.com/t/ffmpeg-question/847158/8 "2020-03-20T18:31:57Z")
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](https://sourceforge.net/projects/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](http://virtualdub2.com/). 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](https://en.wikipedia.org/wiki/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_.