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. |
26th July 2016, 18:32 | #4041 | Link | |
Registered User
Join Date: Feb 2015
Posts: 326
|
Quote:
Speed comparison of 32-bit builds on i5 3450S (AVX), input file file 1920x800, no special options: Code:
bits | GCC 5.3 | GCC 6.1 8bit | 95.37s (7.86 fps)| 83.15s (9.02 fps) 10bit | 435.44s (1.72 fps)| 328.79s (2.28 fps) 12bit | 436.29s (1.72 fps)| 328.16s (2.29 fps) |
|
26th July 2016, 19:26 | #4042 | Link | |
Registered User
Join Date: Dec 2014
Posts: 240
|
Quote:
What are you thinking about some using LimitedSharpenFaster or LSFmod to slightly sharpen the image.... And...what's better/faster in x265? me UMH or STAR? Last edited by jlpsvk; 26th July 2016 at 19:44. |
|
26th July 2016, 19:51 | #4043 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
@ Ma:
I think I used your additional options for the GCC 5.3.0 build as well. That was on another PC... Maybe compare with v2.0+9 which certainly did not have these options set; the changes to v2.0+10 should be small or not relevant in this case, IIRC. _ @ jlpsvk: When motion search does not find a good enough match to inter-code a block, it has to be intra-coded, which requires more space and reduces the efficiency. Therefore, a more exhaustive search may improve the efficiency of an encode. Depending on the material. If there are almost only short or perpendicular motions, star would be efficient enough. Could you know beforehand? Artifical sharpening usually worsens the compressibility. It requires spending more bits for high frequency parameters to be encoded without noticeable artifacts. |
26th July 2016, 19:55 | #4044 | Link | |
Registered User
Join Date: Dec 2014
Posts: 240
|
Quote:
Code:
--crf 19 --output-depth 10 --level-idc 5.1 --cbqpoffs -3 --me umh --rc-lookahead 60 --ref 4 --min-keyint 23 --keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --rskip --crqpoffs -3 --high-tier |
|
26th July 2016, 20:23 | #4045 | Link | |
ffx264/ffhevc author
Join Date: May 2007
Location: /dev/video0
Posts: 1,844
|
Quote:
Last edited by microchip8; 26th July 2016 at 20:26. |
|
26th July 2016, 20:25 | #4047 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
By "material", I rather mean rather little or much action, rather random or regular motion, short or far range. The fact that they are stored on Blu-ray is less relevant...
If you focus on Hollywood blockbusters, you will probably have to expect much random and rather far motion, therefore a more exhaustive search may be more efficient for the quality/size ratio, but cost some speed. In case of nature documentaries, there are different attributes... |
27th July 2016, 12:51 | #4049 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,731
|
Is the scenechange detection essentially the same as in x264? I just encoded the exact same video with both and x264 produced 1411 I-frames while the x265 encode has 1611 I-frames. The length of the source (Zootropolis) is 156147 frames.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
28th July 2016, 00:49 | #4051 | Link | |
Registered User
Join Date: May 2015
Posts: 68
|
Quote:
|
|
28th July 2016, 04:35 | #4053 | Link |
Registered User
Join Date: Jul 2016
Posts: 100
|
You surely asked a good question aymanalz, and one that I have pondered abundantly lately. For the time being I have decided to stay with x264 until the speed of x265 gets some serious attention. The price of disk is cheap. I added 5TB USB for just over $100. With x264 I usually encode at CRF 20, but sometimes as low as CRF 15. For my HD media I usually go 2 pass with nothing short of 10,000 kbit. I did some test encodes with x265 and calculated the encode time for a full movie would be in excess of 48 hours of solid machine time. The same film encodes in under 5 hours in x264. I don't care that the encoded film is 8 GB in x264 and may be les sin x265. I don't have 48 hours or more of dedicated machine time to use for single encodes.
I can revisit using x265 seriously for my video library once the speed issue is resolved. In the meantime, I am enjoying testing and evaluating it. I feel there is great promise and progress forthcoming. |
28th July 2016, 06:12 | #4054 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
Hmm, now that I read the docs again ... I believe we need explanations (and even diagrams!) from a person with more insight.
The description of "star" mode sounds as if it is quite adaptive and can be fast if it finds a good match already in the first star pattern search, but will take more time if the other two steps are required in case of a bad match. Speculations. |
28th July 2016, 07:22 | #4055 | Link | |
Registered User
Join Date: May 2015
Posts: 68
|
Quote:
But you are right, they do need to further speed it up, if it is possible to do so. And I really hope it is possible, because as you state, x265 shows tremendous promise over previous codecs. I see that with every encode I make - the quality of output is far better than x264, at similar bitrates. But the encoding speed is still drearily slow for those of us who don't have professional level hardware. Which is why I'm also holding back on re-encoding a ton of HD home videos for now. |
|
28th July 2016, 07:45 | #4056 | Link | |
Registered User
Join Date: May 2015
Posts: 68
|
Quote:
Code:
Generally, the higher the number the harder the ME method will try to find an optimal match. I hope this gets clarified soon. Isn't it one of the more important determiners of quality? |
|
28th July 2016, 09:46 | #4057 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
It has an impact to the quality/size ratio, but it is not necessarily responsible for better quality in general. If you don't care much about the size, remember: if motion search doesn't find a good enough match for inter coding (motion vector + difference), intra coding (independent newly coded content) is used, which just requires more space, but if the output size is not restricted directly, quality can still be convenient.
Quality gets only worse if you have a limited average or maximum bitrate, which could only be achieved by coarser quantization if too many intra blocks take too much of the overall bitrate. Fortunate motion search matches could have spared bitrate, and finding them requires a more or less thorough search for them. |
28th July 2016, 14:44 | #4060 | Link | |
Registered User
Join Date: Dec 2008
Posts: 415
|
Quote:
I'm using the 64bit version of the GCC 6.1.0 build. Based on my limited testing, it seems that the 8bit version is close to 75% faster than the 12bit version. Both using Very Slow preset. Thanks for the executables and hope you would release a new executibles as the encoder get updated. Last edited by nakTT; 28th July 2016 at 17:54. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|