VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or try DVDFab and copy, convert or make Blu-rays and DVDs! :)
+ Reply to Thread
Page 72 of 73
FirstFirst ... 22 62 70 71 72 73 LastLast
Results 2,131 to 2,160 of 2161
Thread
  1. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    #metoo

    x265 2.7+8-613d9f443769
    Image Attached Files
    Quote Quote  
  2. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.7+12-98e48e8dd6ab

    Code:
       --refine-intra <0..4>         Enable intra refinement for encode that uses analysis-load.
    ...
                                        - 4 : Re-evaluate all intra blocks, does not reuse data from save encode.
    
       --[no-]dynamic-refine         Dynamically changes refine-inter level for each CU. Default disabled
    
       --[no-]idr-recovery-sei      Emit recovery point infor SEI at each IDR frame
    Image Attached Files
    Quote Quote  
  3. Marsia Mariner
    Guest
    deleted
    Last edited by Marsia Mariner; 30th Mar 2018 at 12:28. Reason: buggy build? :-/
    Quote Quote  
  4. Marsia Mariner
    Guest
    x265.exe 2.7+20-3440a56acc78

    fix bug in SEI::write clean up
    Image Attached Files
    Quote Quote  
  5. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.7+20-3440a56acc78

    fix bug in SEI::write clean up
    Image Attached Files
    Quote Quote  
  6. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.7+22-946f82dbf4e8

    dynamic-refine tunings
    Image Attached Files
    Quote Quote  
  7. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.7+332-593e63cda903 (Win64)

    Support for AVX-512 assembly optimized kernels; remember: enable it manually by adding --asm avx512 to the CLI — and don't fry your CPU...

    Only x86-64 (Win64) version available, skipping it in x86 (Win32) mode for NASM is necessary not to break compilation completely.
    Image Attached Files
    Quote Quote  
  8. Marsia Mariner
    Guest
    ^ Thanks for the newest build.

    This time I have nothing important to say... yeah, the recent AVX-512 stuff has made x265 somewhat fatter
    Image Attached Thumbnails Click image for larger version

Name:	x265-with-tons-of-AVX512.png
Views:	787
Size:	18.9 KB
ID:	45153  

    Quote Quote  
  9. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.7+337-54ff74d2b635
    • Merge with default; prep for v3.0
    • Support for HLG-graded content and pic_struct
    • Fix conditions for single-sei NAL
    • Fix 32 bit build error (means: AVX-512 support is only included in x86-64 architecture target)
    (VMAF support to report per frame and aggregate VMAF score — unfortunately not yet? available for Windows builds)

    New CLI parameters:

    Code:
       --atc-sei <integer>           Emit the alternative transfer characteristics SEI message where the integer is the preferred transfer characteristics. Default disabled
       --pic-struct <integer>        Set the picture structure and emits it in the picture timing SEI message. Values in the range 0..12. See D.3.3 of the HEVC spec. for a detailed explanation.
    Image Attached Files
    Quote Quote  
  10. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.7+340-aa9102400f24

    remove unused asmname from x265_param (may fix some crashes on Xeons); added a newline in the help
    (fixed VMAF warning not applicable under Windows)
    Image Attached Files
    Quote Quote  
  11. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.7+346-69aafa6d70ad (stable merge)

    AVX-512 cleanups and a few nits (getting a RC soon?)
    Image Attached Files
    Last edited by LigH.de; 3rd May 2018 at 14:23.
    Quote Quote  
  12. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.7+348-0968a46d6ba4

    fixes a build error on Mac and a calculation bug in scalefactor 0
    Image Attached Files
    Quote Quote  
  13. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.8+1-478bfe2b7673 (stable release, GCC 7.3.0, Win32+Win64)

    last few fixes in analysis mode
    Image Attached Files
    Quote Quote  
  14. Marsia Mariner
    Guest
    x265.exe 2.8+10-a7bd0622ece5

    off-topic: still compiling with gcc 7.3.0.... because I don't know whether the "upgrade" to GCC 8.1.0 would be worth the hassle
    Image Attached Files
    Quote Quote  
  15. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.8+10-a7bd0622ece5 (merge with stable)

    several bug fixes (build errors, dyn.ref., scaled enc.)

    I won't hurry to GCC 8.x either. When MSYS2 updates, it gets updated.
    Image Attached Files
    Quote Quote  
  16. Marsia Mariner
    Guest
    x265.exe 2.8+12-9cde2c278464

    doc: Add recently added SEI and pic-struct to cli doc

    fix signed/unsigned mismatch warning in windows

    ~"merge with stable"~


    This time I did not forget to enable "VMAF support" in the build script.
    Not sure of how useful that will be though.
    Image Attached Files
    Quote Quote  
  17. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    VMAF will be ignored in Windows builds. And it will not work for multilib builds, not even on Linux.
    Quote Quote  
  18. Marsia Mariner
    Guest
    Thanks for the info

    VMAF will be ignored in Windows builds
    Have they explained the reason why?

    Also: are you sure they didn't mean *MSVC* when they said "Windows"?

    (yes, the x265 devs can be that stupid)
    Last edited by Marsia Mariner; 1st Jun 2018 at 09:06. Reason: grammar
    Quote Quote  
  19. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    I don't remember any reply yet on the mailing list. I already suspected that an MSYS2/MinGW environment might be able to handle that if there is not a Windows specific reason to fail.
    Quote Quote  
  20. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.8+19-bcdc610cf5f0

    Support scale factor with analysis-reuse-level 1-6; fix build issue when using icc; add support for chunked encoding*; use the data structure of analysis-save/load for multi-pass-opt-analysis/multi-pass-opt-distortion; add vbv-end tolerance check

    Code:
       --chunk-start <integer>       First frame of the chunk. Default 0 (disabled)
       --chunk-end <integer>         Last frame of the chunk. Default 0 (disabled)
    * this seems to allow the output of parts of a GOP, with bitrate control beyond this GOP where required, possibly to support "smart rendering"
    Image Attached Files
    Quote Quote  
  21. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.8+24-289b8a3730ae

    Code:
       --nalu-file <filename>        Text file containing SEI messages in the following format : <POC><space><PREFIX><space><NAL UNIT TYPE>/<SEI TYPE><space><SEI Payload>
    was --usersei-file a "moment" ago...
    Image Attached Files
    Quote Quote  
  22. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.8+40-0106f9f2f867

    several new AVX(2) assembler routines
    Image Attached Files
    Quote Quote  
  23. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.8+47-e2759ae31c36

    several fixes related to HDR10+ LLC JSON and dependencies between effects of options
    Image Attached Files
    Quote Quote  
  24. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.8+57-eea92165b035

    Enhance VBV lookahead of RADL pictures (and a few more small building and API fixes)
    Image Attached Files
    Quote Quote  
  25. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    MSYS2 recently updated MinGW64 with GCC 8.2.0; due to some internal compiler errors, MinGW32 will stay with GCC 7.3.0, though, until these issues are solved.

    x265 2.8+58-d17bc7714ed2 (Win32-GCC730 & Win64-GCC820)
    Image Attached Files
    Quote Quote  
  26. Marsia Mariner
    Guest
    x265.exe 2.8+66-88ee12651e30
    Image Attached Files
    Quote Quote  
  27. Marsia Mariner
    Guest
    x265.exe 2.8+68-fa57fa584898

    µChangeLog

    --- use one 32bit operation instead of two 16bit in MV union

    --- api: fix memory allocation of distortionData

    sse_t type depends of x265 default bit-depth
    if 8bit x265 try to allocate distortionData for 10bit encoding
    (possible in multilib build) we need double memory size for
    sse_t type tables (uint32_t -> uint64_t)
    Image Attached Files
    Quote Quote  
  28. Member
    Join Date
    Sep 2018
    Location
    France
    Search Comp PM
    We were having some trouble with building libx265 with MinGW as the local version we had a on a dev machine was crashing, and the mingw server to upgrade to the latest version wasn't responding late last week. That is why there has been no updates here Notepad++ Malwarebytes FileZilla
    As a quick check, can you try to replace the #ifdef _WIN32 in x265-extras.h with #ifdef X265_API_IMPORTS to check if that fixes the problem? I recall running into a similar problem where MinGW behaves differently from other windows SDKs and therefore had to make a tweak like this in x265.h; the identical change isn't made in x265-extras.h.
    Last edited by bimaloy30; 27th Sep 2018 at 14:20.
    Quote Quote  
  29. Marsia Mariner
    Guest
    Originally Posted by bimaloy30 View Post
    We were having some trouble with building libx265 with MinGW as the local version we had a on a dev machine was crashing, and the mingw server to upgrade to the latest version wasn't responding late last week. That is why there has been no updates here.

    As a quick check, can you try to replace the #ifdef _WIN32 in x265-extras.h with #ifdef X265_API_IMPORTS to check if that fixes the problem? I recall running into a similar problem where MinGW behaves differently from other windows SDKs and therefore had to make a tweak like this in x265.h; the identical change isn't made in x265-extras.h.
    The text above was actually written by an actual x265 developer @ https://bitbucket.org/multicoreware/x265/issues/360/v25-does-not-work-in-ffmpeg-24x

    So, my question is: ¿are you a spämmer?
    Quote Quote  
  30. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.9+1-169e76b6bbcc (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

    surprise
    Image Attached Files
    Quote Quote  



Similar Threads