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. |
2nd December 2013, 23:41 | #224 | Link | |
Guest
Posts: n/a
|
Quote:
diff -r 833d78aaf71e source/encoder/encoder.cppTom |
|
3rd December 2013, 09:12 | #226 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
For comparing different encoders, you should probably use a standalone tool.
For example x264 IIRC did some shortcuts (not deblocking non-reference Bframes or something like that) during the calculations, and it is possible x265 does it similarly. Using a standalone tool in any case gets rid of such variances. |
3rd December 2013, 22:51 | #228 | Link |
Guest
Posts: n/a
|
Version 0.6 released
Release Notes...
x265 0.6 is a regularly scheduled release There were large improvements in compression efficiency since 0.5, mostly a result of the completion of weightp and b-pyramid. There is also a large amount of new assembly code; replacing most of the compiler intrinsic functions and adding coverage for some new primitives. = New Features = * CLI reads input video from stdin * Main10 profile is enabled, requires a HIGH_BIT_DEPTH build * weightp is now complete enough to be enabled by default * performance presets have been defined, matching x264 preset names * b-pyramid (hierarchical B frames) now supported * Constant Rate Factor rate control is considered stable * Adaptive Quantization introduced (experimental) Adaptive Quantization is still considered experimental. We are not always seeing the expected improvements to SSIM when it is enabled, and thus it is still not enabled by default. = API Changes = * x265_nal data members renamed * x265_picture now has colorSpace member * --weightp enabled by default * default parameters now match our medium preset * new x265_param_default_preset() method for assigning preset and tune * new x265_param_alloc() and x265_param_free() methods for version safety * new x265_picture_alloc() and x265_picture_free() methods for version safety The public data structures have changed enough that apps compiled against previous versions of x265 must be recompiled to use x265 0.6. We are taking steps to add version safety to the public interface. If you use the new alloc/free methods for the param and picture structures, and use x265_param_parse() to set param values by name, you will likely not have to recompile your application to dynamically link against later releases of x265. = New Command Options = * --y4m overrides detection of Y4M input stream, ex: x265 --y4m - out.hevc < vid.y4m * --version long option alias for -V * -p/--preset sets performance preset * -t/--tune sets parameter tuning * --[no-]b-pyramid enabled by default * --input-csp color space parameter, only i420 is supported in this release * --crf constant rate factor rate control * --aq-mode and --aq-strength See x265 --help for more details = Upcoming improvements = * motion compensated weightp analysis (using lookahead data) * CU-tree (MBtree adapted from x264) * VBV rate control * assembly for HIGH_BIT_DEPTH builds |
3rd December 2013, 23:43 | #229 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
Now this is good news. The rate of change has been incredible over the past few months, especially in getting assembly written, and I've seen the patches coming for CUtree already. Great work! I'll probably take this and see how it performs on a real video soon.
|
4th December 2013, 01:09 | #230 | Link | |
Guest
Posts: n/a
|
Quote:
Tom |
|
4th December 2013, 03:28 | #231 | Link |
Registered User
Join Date: May 2013
Posts: 90
|
btw. 0.6 Release Notes, since it hasn't been mentioned:
--rd can now have values from 1 to 6 (previous value 2 is now 5,6) from my tests Adaptive Quantization works correctly with rd>=4 Last edited by fumoffu; 6th December 2013 at 23:09. |
4th December 2013, 12:55 | #232 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
From my experimenting in the last couple of weeks, it did seem to provide a significant visual improvement, although I wasn't doing comprehensive testing. |
|
4th December 2013, 13:05 | #233 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
SSIM is not able to measure a subjective improvement. So don't be sad about not getting a perfect similarity based on a technical metric; the metric will be the less reliable value, compared to an ABX test with hundreds of probands.
|
4th December 2013, 15:10 | #234 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
I'm having some difficulty using x265. I tried a 10 Bit encode using a build from x265.cc (64bit, 16bpp, 1d2d60f4eb81, mingw). Here's the command-line I used:
x265 - --input-res 1920x800 --fps 24000/1001 --input-depth 10 --crf 18 --aq-mode 1 -o test2.h265 --preset slow Sample, log 1. I can't mux it using either l-smash or mp4box. Both suspect corruption. 2. It came out at only ~11 Mbytes for 2684 frames with horrible quality. I know I can decrease --crf further but is this really the quality expected for crf 18? 3. The log says "yuv [info]: 1920x800 24000Hz[...]". Should I have used "23.976" instead of "24000/1001"? Last edited by sneaker_ger; 4th December 2013 at 15:19. |
4th December 2013, 15:25 | #235 | Link | |
Swallowed in the Sea
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
|
Quote:
So, either Code:
mp4box -add input.hevc output.mp4 Code:
mp4box -add input.h265:FMT=HEVC output.mp4 |
|
4th December 2013, 19:23 | #237 | Link | |
Registered User
Join Date: May 2013
Posts: 90
|
Quote:
|
|
4th December 2013, 19:32 | #238 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
I will test but it sounds reasonable. Totally blind to not notice 24000 != 24.000. Now when using "--fps 23.976" the log says "23Hz". Wondering if it just clips the log or if the output might be wrong (if there a timings in the raw stream at all).
|
4th December 2013, 19:38 | #239 | Link | |||
Registered User
Join Date: Sep 2002
Location: France
Posts: 432
|
Quote:
Quote:
Quote:
|
|||
4th December 2013, 20:22 | #240 | Link |
Testeur de codecs
Join Date: May 2003
Location: France
Posts: 2,484
|
Well I test actualy this 0.6 build and optimistation (speed and quality) are simply terrific in few month. H264 is simply surpassed and by far. I test codec since 2003 and I use always the same trailer for that. x265 produce same output quality for psnr than H264 mainconcept codec at half bitrate. x265 is actualy not able to produce the same quality output for psnr than x264 10 bit in placebo mode at half bitrate. Anyway it's only the 0.6 version for x265 ...
In all my test with this trailer x264 10 bit in placebo mode is never able to produce the same quality output than MPEG4 ASP (XviD or DivX) at half bitrate. H265 is certainely the most advanced evolution (in codec generation comparison) that I have never see for new codec (and I test some codec since more 10 years) ...
__________________
Le Sagittaire ... ;-) 1- Ateme AVC or x264 2- VP7 or RV10 only for anime 3- XviD, DivX or WMV9 Last edited by Sagittaire; 4th December 2013 at 21:07. |
Thread Tools | Search this Thread |
Display Modes | |
|
|