I just made my first encode with --analysis-mode load and while it ran 3 times 
as fast, the
encoded file was completely broken. This is with 10-bit input and output, 
current git head.

Original command line: x265 --preset veryslow --input pristest.y4m 
--analysis-mode save
--analysis-file pristest.dat --crf 20 -o pristest-q20-veryslow.hevc
Second command line: x265 --preset veryslow --input pristest.y4m 
--analysis-mode load
--analysis-file pristest.dat --crf 24 -o pristest-q24-veryslow.hevc

pristest.y4m: https://dl.dropboxusercontent.com/u/54412753/x265/pristest_30s.7z 
(first 30s of
the original 120s)
pristest.dat: https://dl.dropboxusercontent.com/u/54412753/x265/pristest.7z
pristest-q24-veryslow.hevc:
https://dl.dropboxusercontent.com/u/54412753/x265/pristest-q24-veryslow.hevc

All I changed was the crf, and I got tons of black blocks and echo blocks, 
especially beginning
around 0:20, as if residuals sometimes weren't being applied at all. MPDN just 
freezes, other
players play with major artifacts.

Aside from that, holy crap is the analysis file huge. It's as large as the y4m; 
I had to put it
on a ntfs compressed folder, where it went from 11gb to 800mb real bytes. (The 
7-zip is only
50mb.) Surely x265 can run some sort of compression over it while writing, 
either low xz (lzma2)
or at least lzo/lz4? When I first attempted to use it from the same drive as my 
working file, I
ended up thrashing the disk so badly that encoding speed was actually halved, 
until I moved it
to my SSD system drive.
_______________________________________________
x265-devel mailing list
[email protected]
https://mailman.videolan.org/listinfo/x265-devel

Reply via email to