Quote:
Originally Posted by pradeeprama
Limit-tu isn't trying to favour smaller TUs over larger TUs at all. It is only trying to limit the depth of recursion that is used. In fact, I would think that you would see larger TUs with limit-tu enabled when compared to no limit-tu.
Can you share your command-lines so that we can comment?
|
Sure, here's the command line I used to test:
Code:
vspipe.exe --y4m "c:\x265\hotfuzz.vpy" - | C:\sources\x265\build\vc14-x86_64\Release\x265.exe --input - --y4m --input-depth 16
--dither --sar 1:1 --profile main10 --keyint 480 --ref 5 --rskip --colormatrix "bt709" --colorprim "bt709" --transfer "bt709"
--preset slower --rc-lookahead 60 --deblock -3:-1 --no-strong-intra-smoothing --limit-refs 3 --limit-modes --limit-tu 0
--tu-inter-depth 4 --tu-intra-depth 4 --merange 38 --tune grain --crf 21 --csv q:\hotfuzz_limittu0.csv --csv-log-level 2 --output "q:\hotfuzz_limittu0.hevc"
Here are the csv logfiles from my five encodes at different values for --limit-tu :
https://drive.google.com/open?id=0Bz...HJLdVNfRDdNbWM
In my tests, the bitrate and encoding speed was as follows:
--limit-tu 0 : 4875.60 kbps, 1.64 fps
--limit-tu 1 : 4899.45 kbps, 1.84 fps
--limit-tu 2 : 4990.49 kbps, 1.93 fps
--limit-tu 3 : 5037.98 kbps, 1.99 fps
--limit-tu 4 : 5044.37 kbps, 2.02 fps
The black mattes were cropped and the result downsized to 1280x544. The original source clip is here:
https://drive.google.com/open?id=0Bz...khsX3RuZGhWcjA