VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors.
Please consider supporting us by disabling your ad blocker or buy PlayOn and record Netflix! :)
+ Reply to Thread
Page 71 of 71
FirstFirst ... 21 61 69 70 71
Results 2,101 to 2,129 of 2129
Thread
  1. Originally Posted by LigH.de View Post
    (MSYS/MinGW, GCC 7.1.0) ... does XhmikosR still update?
    Good question But while he doesn't, you might give a try to the archive below.
    Nothing special, I just downloaded his latest MSYS1 package and replaced the contents of the mingw directory with nevcairiel's GCC 7.2
    Image Attached Files
    Quote Quote  
  2. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Huuuge THX
    Quote Quote  
  3. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Trying to switch from MSYS (XhmikosR) to MSYS2 (MABS); it's not so simple, using separate runs in MinGW32 and MinGW64 as workaround for now to avoid patching the cross compilation toolchain file.

    x265 2.5+27-0e168bdeb48b (GCC 7.2.0)
    Image Attached Files
    Last edited by LigH.de; 26th Oct 2017 at 10:53.
    Quote Quote  
  4. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.5+31-df2de6ea407d

    Support for more monochrome video source formats; plus a few fixed nits.
    Image Attached Files
    Quote Quote  
  5. x265.exe 2.5+37-aa9649a2aa8c

    µchangelog:

    api: 'x265_get_slicetype_poc_and_scenecut' to fetch slicetype, poc and scenecut information

    api: 'x265_get_ref_frame_list' to get forward and backward refrence list

    Implementation of low-pass subband dct approximation.

    doc/test: Add lowpass test, remove/add experimental labels to some features.

    Add vbv-end to denote VBV emptiness after inserting all the frames into it.
    Image Attached Files
    Quote Quote  
  6. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.5+47-6a882a9300c2

    Speed-ups, API changes, more internal analysis features, new CLI parameters:

    Code:
       --vbv-end <float>             Final VBV buffer emptiness (fraction of bufsize or in kbits). Default 0 (disabled)
       --vbv-end-fr-adj <float>      Frame from which qp has to be adjusted to achieve final decode buffer emptiness. Default 0
       --lowpass-dct                 Use low-pass subband dct approximation. Default disabled
       --refine-mv-type <string>     Reuse MV information received through API call. Supported option is avc. Default disabled - 0
    Docs: refine-mv-type, vbv-end
    Image Attached Files
    Last edited by LigH.de; 8th Nov 2017 at 06:46.
    Quote Quote  
  7. x265.exe 2.5+54-6ac1b12bcde9

    Code:
    Encoder: avoid blocking in getEncodedPicture() for zero latency when multiple slices are enabled
    Improved performance by 10 - 15 fps depending upon preset and number of slices.
    Image Attached Files
    Quote Quote  
  8. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    ^ please note that this is a real-time encode scenario, not a high-quality one.
    Quote Quote  
  9. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.5+55-dd9772385d15

    Add CLI option to enable or disable picture copy to internal frame buffer

    Code:
       --[no-]copy-pic               Copy buffers of input picture in frame. Default enabled
    Allow encoder to copy input x265 pictures to internal frame buffers. When disabled, x265 will not make an internal copy of the input picture and will work with the application's buffers. While this allows for deeper integration, it is the responsbility of the application to (a) ensure that the allocated picture has extra space for padding that will be done by the library, and (b) the buffers aren't recycled until the library has completed encoding this frame (which can be figured out by tracking NALs output by x265)
    I can imagine that when x265 is linked inside an application or as DLL; but how is that supposed to work for x265 as a separate CLI application? I doubt it would have access to memory pointers of a calling application.
    __

    P.S.:

    As far as I hope to understand, it may not be helpful to the pure x265 CLI encoder, but possibly to other applications derived from this structure, configuring itself internally with a CLI parameter string as well.
    Image Attached Files
    Last edited by LigH.de; 15th Nov 2017 at 14:07.
    Quote Quote  
  10. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.5+65-a7c2f80c18af

    Disable opt-qp-pps and opt-ref-list-length-pps by default; use AVC CU analysis data in anlysis-reuselevel 7 and 8; update an outdated help message for --bframes
    Image Attached Files
    Quote Quote  
  11. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Should have waited one more day...

    x265 2.5+66-dae558b40d99

    merge with stable + fixed compiler warning (parentheses)

    Milestone v2.6 is in sight!
    Image Attached Files
    Quote Quote  
  12. x265.exe 2.6+2-32e6f04b8713

    What's New:

    Originally Posted by pradeeprama@forum.doom9.org
    x265 version 2.6 is now out! The key new improvements include support for segmented encoding, and introducing the ability of x265 to reuse and refine analysis from previously done HEVC and AVC encodes. The tarball of this release can be downloaded from the downloads page.

    Release date - 29th November, 2017.
    ============================

    New features
    ------------------
    1) x265 can now refine analysis from a previous HEVC encode (using options --refine-inter, and --refine-intra), or a previous AVC encode (using option --refine-mv-type). The previous encode’s information can be packaged using the x265_analysis_data_t data field available in the x265_picture object.
    2) Basic support for segmented (or chunked) encoding added with --vbv-end that can specify the status of CPB at the end of a segment. String this together with --vbv-init to encode a title as chunks while maintaining VBV compliance!
    3) --force-flush can be used to trigger a premature flush of the encoder. This option is beneficial when input is known to be bursty, and may be at a rate slower than the encoder.
    4) Experimental feature --lowpass-dct that uses truncated DCT for transformation.

    Encoder enhancements
    --------------------------------
    1) Slice-parallel mode gets a significant boost in performance, particularly in low-latency mode.
    2) x265 now officially supported on VS2017.
    3) x265 now supports all depths from mono0 to mono16 for Y4M format.

    API changes
    -----------------
    1) Options that modified PPS dynamically (--opt-qp-pps and --opt-ref-list-length-pps) are now disabled by default to enable users to save bits by not sending headers. If these options are enabled, headers have to be repeated for every GOP.
    2) Rate-control and analysis parameters can dynamically be reconfigured simultaneously via the x265_encoder_reconfig API.
    3) New API functions to extract intermediate information such as slice-type, scenecut information, reference frames, etc. are now available. This information may be beneficial to integrating applications that are attempting to perform content-adaptive encoding. Refer to documentation on x265_get_slicetype_poc_and_scenecut, and x265_get_ref_frame_list for more details and suggested usage.
    4) A new API to pass supplemental CTU information to x265 to influence analysis decisions has been added. Refer to documentation on x265_encoder_ctu_info for more details.

    Bug fixes
    -------------
    1) Bug fixes when --slices is used with VBV settings.
    2) Minor memory leak fixed for HDR10+ builds, and default x265 when pools option is specified.
    3) HDR10+ bug fix to remove dependence on poc counter to select meta-data information.
    Image Attached Files
    Quote Quote  
  13. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.6+2-32e6f04b8713
    Image Attached Files
    Quote Quote  
  14. do u guys have any tutorial about how to compile x265 with visual studio ?
    I installed THIS but don't know what to do next.
    Quote Quote  
  15. To whom this may interest...
    latest x265 version is 2.6+5 — no substantial difference from the 2.6+2 release, but now x265 requires nasm instead of yasm to be compiled "properly".
    Reason for the change: nasm supports AVX-512, whereas yasm does not.
    Problem: nasm is much slower than yasm.
    It would be interesting if the x265 devs themselves patched nasm to make it fast. OR, perhaps, they could add AVX-512 support to yasm...

    Anyway: according to what I found through Google, people have been complaining about nasm's slowness since ages ago
    Quote Quote  
  16. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    I do remember that yasm increased its speed from 1.2 to 1.3 by expanding internal buffers. I doubt that speeding up nasm would be just as simple.

    But I also remember that the developers already explained in the doom9 forum that enhancing yasm for AVX-512 support would not be worth the efforts of contributors, they said that the support of AVX-512 requires quite a lot of different processing of instructions, compared to previous instruction sets. So yasm is abandoned. And speeding up nasm would mainly be the task of nasm developers (who may enjoy contributions, but I would assume it is surely not another task for Multicoreware, they have their own schedule).

    Don't cry about 5 minutes per week or two. How often do you really need a fresh build?
    Quote Quote  
  17. Originally Posted by LigH.de View Post
    Don't cry about 5 minutes per week or two. How often do you really need a fresh build?
    Not a direct answer to your question, but...

    With yasm, a multilib 64-bit build of x265.exe takes around 15 minutes (that is to say, about 5 minutes per "section" — 8-bits + 10-bits + 12-bits) on my Q8400.

    With nasm, I still haven't found the patience to measure it — probably the E.T.A. will be somewhere between 12 minutes x 3 = 36 minutes and 20 minutes x 3 = 1 hour...
    but I admit that this is just a wild guess.
    Quote Quote  
  18. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    So bad? ... Hmm, I have only an AMD Phenom-II available. Not sure if it runs multi-threaded. But you are right: The 32-bit build takes 14 min, the 64-bit build takes 36 min. Quite a difference. But well ... I can do other things in the meantime, it's semi-automatic. The only issue under Windows is that terminating processes stays in critical sections for a while, the longer the more cores you have. And make tools as well as GNU compilers seem to spawn and terminate processes a lot.
    _

    @ador250:

    No experience here, but according to https://bitbucket.org/multicoreware/x265/wiki/Home it should not be too hard...

    Windows (Visual Studio) Instructions

    Code:
    $ hg clone https://bitbucket.org/multicoreware/x265
    Then run make-solutions.bat in the build\ folder that corresponds to your favorite compiler, configure your build options, click 'configure', click 'generate', then close cmake-gui. You will be rewarded with an x265.sln file. Also see cmake documentation.
    Last edited by LigH.de; 1st Dec 2017 at 06:57.
    Quote Quote  
  19. Originally Posted by LigH.de View Post
    So bad? ... Hmm, I have only an AMD Phenom-II available. Not sure if it runs multi-threaded. But you are right: The 32-bit build takes 14 min, the 64-bit build takes 36 min. Quite a difference. But well ... I can do other things in the meantime, it's semi-automatic. The only issue under Windows is that terminating processes stays in critical sections for a while, the longer the more cores you have. And make tools as well as GNU compilers seem to spawn and terminate processes a lot.
    Okay, I disrespected my lack of patience and let the new asm code do its new "magic"... my Q8400 needed 40 minutes to compile the new x64 multilib x265.exe. If I had followed qyot27's advice and entered "make --jobs=4", probably the 40 minutes would be reduced to 36... But if I had to use a Pentium 4 (like in 2013), certainly the 40 minutes would become 2 hours

    </END OF COMPLAINT>
    Quote Quote  
  20. x265.exe 2.6+8-fc0570b8d8f9
    (GCC 7.2.0, nasm 2.13.02)
    Image Attached Files
    Last edited by Marsia Mariner; 2nd Dec 2017 at 03:06. Reason: edit
    Quote Quote  
  21. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.6+14-f09f3b4a2115

    New options:

    Code:
       --fullhelp                    Show all options and exit
       --gop-lookahead <integer>     Extends gop boundary if a scenecut is found within this from keyint boundary. Default 0
    Image Attached Files
    Quote Quote  
  22. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.6+24-69cfe46e8a3b – merge with stable

    Several fixes e.g. in analysis and VBV handling; added support for RADL pictures; renamed options:

    Code:
       --radl <integer>              Number of RADL pictures allowed in front of IDR. Default 0
    
    (  --analysis-reuse-mode <string|int>  removed )
       --analysis-save <filename>    Dump analysis info into the specified file. Default Disabled
       --analysis-load <filename>    Load analysis buffers from the file specified. Default Disabled
    Image Attached Files
    Quote Quote  
  23. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265_2.6+31-3712d13c09bf
    • important stability fix when using very verbose parameters like zones and additional files (could exceed a too small internal buffer)
    • input: change from ifstream to stdio stream
    • change date to 2018 in output file header
    Image Attached Files
    Quote Quote  
  24. x265.exe 2.6+37-1949157705ce
    Image Attached Files
    Quote Quote  
  25. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Mine delay a bit. There are broken binutils in the latest update with GCC 7.3.0, leaving "(null)" in the build ID strings.
    Quote Quote  
  26. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    After re-installing MABS completely, which updated only to binutils-2.29, version strings are back. Other important changes:

    32-bit builds made with GCC can open large files too; MinGW compiles exclude some superfluous libraries; fixes in special conditions with BREF frames, rate control with both weightp and cutree, and unnecessary luma calculations in CSV output

    x265 2.6+37-1949157705ce (MSYS2/MinGW, GCC 7.3.0)
    Image Attached Files
    Quote Quote  
  27. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    MSYS2 released binutils-2.30-2; static binaries should work again.
    Quote Quote  
  28. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.6+39-01b685d6fa33

    CMake: fix generation of version info from .hg_archival.txt; fix output to pipe on Windows (enable binary mode)
    Image Attached Files
    Quote Quote  
  29. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    New upload: x265 2.7+1-2aa737a99f51

    limitTU: Save intra CU's TU depth when analysis save/load is enabled; dHDR10 parsing fixes; ipfilter kernels split into several separate source files; v2.7 milestone
    Image Attached Files
    Quote Quote  



Similar Threads