Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
20th September 2016, 13:13 | #1 | Link |
Registered User
Join Date: Jun 2016
Posts: 3
|
Should slow encoding speeds result in a smaller file?
Hello,
I have obviously been making a noobie mistake so I'm hoping someone could illuminate me. I had been labouring under the apparently mistaken belief that if I set the encoder speed to slow or veryslow but kept all the other parameters the same then I would end up with a smaller output file. I have an encode I made from BluRay at CRF 18 running UltraFast and VerySlow. The UltraFast took 2 hrs and produced a file of approx 3.5GB. The VerySlow encode took about 65 hours and produced a file of approx 9GB. The same AVS script was used for both encodes and I made no changes to the other launching parameters. I used Lord Mulders x264/x265 Launcher to run the encodes. I left Tuning at <None> and Profile at <Unrestricted>. The only custom parameter I added was --sar 1:1. I'm attaching the MediaInfo results for both files which shows all the encoding parameters. As I used CRF 18 on both the picture quality is expected to be the same. But why did the VerySlow encode end up with a filesize approx 2.5 times the UltraFast encode? What benefit would I get from doing slow encodes? Thank you |
20th September 2016, 17:10 | #2 | Link |
Registered User
Join Date: Sep 2012
Posts: 47
|
Wow, that's a big difference. Did you check the files visually? Usually you expect the slower presets to be more efficient and better bitrate/quality. But note that the understanding and target of quality changes even for fixed CRF once you change the preset, at least by a little. Maybe true running multiple presets, like maybe including medium too, for a smaller clip and look at what you see.
Somebody who actually knows the encoder could correct me or tell you much better, but there are I think two main aspects: 1. To save on computational cycles and improve speed, at the quicker presets the video is analyzed less and the encoder has less of an idea of the true characteristic of the video. So it's idea of a certain quality is coarser and may be wrong. 2. At the more computationally intense presets, more pscychovisual optimizations are turned on. These shift what resulting video is acceptable and change the distribution of bits. In particular I think if aq and psy-rd and so on get turned on, the encoder may try to better match the energy of flatter blocks, which in practice could mean throwing more bits at grain. Is there heavy grain in the source? What do the encodes look like? |
21st September 2016, 19:28 | #3 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Exactly - ultrafast has only a very coarse idea of what quality is compared to veryslow. Visually, I'd expect your CRF 18 veryslow to look significantly better than the ultrafast.
Still, that is a pretty huge variance. What kind of content is it? I think comparing at CBR or 2-pass VBR is more useful when comparing extremely different presets. |
21st September 2016, 20:01 | #4 | Link |
Registered User
Join Date: Feb 2009
Location: Toronto, Ontario, Canada
Posts: 1,059
|
Just a guess when using preset Ultrafast motion estimation is diamond method, where veryslow uses star. Which can change how encoder allocate bit-rate to video, especially with crf in low range values. Other variable might also have big role in it.
I agree with benwaggoner CBR would be better in this case.
__________________
If you fail to plan; you plan to fail, would you not agree? Think about it. Last edited by HWK; 21st September 2016 at 20:12. |
22nd September 2016, 08:47 | #5 | Link |
Registered User
Join Date: Jul 2015
Posts: 708
|
I don't know what they write gentlemen.
x264 [info]: cabac=1 ref=1 deblock=1:-2:-2 analyse=0x1:0 me=dia subme=2 psy=1 fade_compensate=0.00 psy_rd=1.00:0.25 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=6,6 fast_pskip=1 chroma_qp_offset=0 threads=4 lookahead_threads=2 sliced_threads=0 nr=0 decimate=0 interlaced=0 bluray_compat=0 constrained_intra=0 fgo=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=48 keyint_min=4 scenecut=40 intra_refresh=0 rc_lookahead=48 rc=crf mbtree=1 crf=18.0000 qcomp=0.80 qpmin=0 qpmax=81 qpstep=4 vbv_maxrate=160000 vbv_bufsize=160000 crf_max=0.0 nal_hrd=none/vbr filler=0 ip_ratio=1.10 aq=1:0.00 x264 [warning]: NAL HRD parameters require VBV parameters <-- CBR & VBV x264 [warning]: CBR HRD requires constant bitrate <-- CBR to auto VBR Code:
Output #0, yuv4mpegpipe, to 'pipe:': Metadata: date : 2016-09-07T08:27:49+02:00 encoder : Lavf57.50.100 Stream #0:0: Video: wrapped_avframe, yuv420p10le, 4096x2304, q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc Metadata: encoder : Lavc57.57.101 wrapped_avframe Stream mapping: Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help y4m [info]: 4096x2304p 0:0 @ 24000/1001 fps (cfr) x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX x264 [error]: constant rate-factor is incompatible with 2pass. x264 [error]: x264_encoder_open failed av_interleaved_write_frame(): Broken pipe Error writing trailer of pipe:: Broken pipe Last edited by Jamaika; 22nd September 2016 at 09:02. |
|
|