Doom9's Forum - View Single Post

hello_hello · 20th November 2015, 18:09

Thanks for the info guys. I didn't mean to come across as being anti-x265 or anything like that. Just trying to look at it objectively.... and understand

If the speed requirements included both passes combined, it seems to me x265 would have faired better if CRF encoding was used. Probably harder to test given there's no bitrate control but assuming at the same bitrate CRF and 2 pass encode the same way, maybe in some cases a slower speed preset could have been used if a 1st pass wasn't required.

There's some things I don't understand, such as why for the Ittiam HEVC Software Encoder, 2 pass encoding was used for the "ripping" tests while CBR encoding was used for the other two, or why (according to pdf) the ultrafast x265 preset was used for the "desktop 30fps" test while the superfast preset was used for the "server 60fps" test. Logically to me it should have been the other way around.

20th November 2015, 18:09	#9 \| Link
hello_hello Registered User Join Date: Mar 2011 Posts: 4,829	Thanks for the info guys. I didn't mean to come across as being anti-x265 or anything like that. Just trying to look at it objectively.... and understand If the speed requirements included both passes combined, it seems to me x265 would have faired better if CRF encoding was used. Probably harder to test given there's no bitrate control but assuming at the same bitrate CRF and 2 pass encode the same way, maybe in some cases a slower speed preset could have been used if a 1st pass wasn't required. There's some things I don't understand, such as why for the Ittiam HEVC Software Encoder, 2 pass encoding was used for the "ripping" tests while CBR encoding was used for the other two, or why (according to pdf) the ultrafast x265 preset was used for the "desktop 30fps" test while the superfast preset was used for the "server 60fps" test. Logically to me it should have been the other way around.