VideoHelp Forum


Try DVD Fab Video Downloader and rip Netflix video! Or Try DVD Fab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Page 65 of 75
FirstFirst ... 15 55 63 64 65 66 67 ... LastLast
Results 1,921 to 1,950 of 2222
Thread
  1. Originally Posted by LigH.de View Post
    Hmm, strange. The location of the scripts appears to be correct (in C:\MSYS\home\2016, not in C:\MSYS\bin). I don't know why they are "not found". Please show the output of "ls -l" in your shell; in mintty, "ls -Flash" should look even prettier.

    And yes, the link seems to be correctly edited.
    I try msys.bat and work it but follow error
    http://i.hizliresim.com/L1mLAa.png
    Last edited by eca2424; 10th Feb 2016 at 06:45.
    Quote Quote  
  2. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    It seems that compiling failed, therefore no exe and no dll exists.

    Running ./remake_x265.sh should take a while if it is successful, and produce a lot of console output. Are there any error messages? Maybe I forgot to mention that you have to install CMake as well...
    Quote Quote  
  3. Originally Posted by LigH.de View Post
    It seems that compiling failed, therefore no exe and no dll exists.

    Running ./remake_x265.sh should take a while if it is successful, and produce a lot of console output. Are there any error messages? Maybe I forgot to mention that you have to install CMake as well...
    you right ı forgot cmake okay i did Now, I just need to use what code to make 1.7 or 1.8?
    Quote Quote  
  4. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    You should have executed hg clone https://bitbucket.org/multicoreware/x265 and then ./uptodate_x265.sh once to prepare your local source copy and the building subdirectories. Then...

    To build the revision with the tag "1.7":
    • hg update --cwd x265 -r 1.7
    • ./remake_x265.sh
    • ./makemulti.sh
    • ./release_x265.sh
    • Archive the content of C:\MSYS\home\2016\release after testing if x265_ml -V in C:\MSYS\home\2016\release\Win32 reports the version correctly.

    To build the revision with the tag "1.8":
    • hg update --cwd x265 -r 1.8
    • ./remake_x265.sh
    • ./makemulti.sh
    • ./release_x265.sh
    • Archive the content of C:\MSYS\home\2016\release after testing if x265_ml -V in C:\MSYS\home\2016\release\Win32 reports the version correctly.

    Please note: Trying to build versions before 12 bit code has been developed will probably fail without editing the shell scripts.
    Quote Quote  
  5. Originally Posted by LigH.de View Post
    You should have executed hg clone https://bitbucket.org/multicoreware/x265 and then ./uptodate_x265.sh once to prepare your local source copy and the building subdirectories. Then...

    To build the revision with the tag "1.7":
    • hg update --cwd x265 -r 1.7
    • ./remake_x265.sh
    • ./makemulti.sh
    • ./release_x265.sh
    • Archive the content of C:\MSYS\home\2016\release after testing if x265_ml -V in C:\MSYS\home\2016\release\Win32 reports the version correctly.

    To build the revision with the tag "1.8":
    • hg update --cwd x265 -r 1.8
    • ./remake_x265.sh
    • ./makemulti.sh
    • ./release_x265.sh
    • Archive the content of C:\MSYS\home\2016\release after testing if x265_ml -V in C:\MSYS\home\2016\release\Win32 reports the version correctly.

    Please note: Trying to build versions before 12 bit code has been developed will probably fail without editing the shell scripts.
    thats all.Thank you very much.and Thank you for your patience.
    Quote Quote  
  6. Hi @LigH.de, me again. What code 8+10 bit for multilib.sh ? not 8+10+12. only 8+10
    Quote Quote  
  7. you would need to modify multilib.sh to only build 8+10 -> Have you ever read it and understood how it works?
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  8. Originally Posted by Selur View Post
    you would need to modify multilib.sh to only build 8+10 -> Have you ever read it and understood how it works?
    Yes. Multilib.sh edit with visual studio. What code only 8+10 bits? Do you now sir?
    Quote Quote  
  9. If you are using Visual Studio, editing and/or using multilib.sh which is a shell script meant for linux enviroments, doesn't make any sense at all!

    What you need to edit and use is the multilib.bat which resides in the corresponding build/vc... folder which matches your Visual Studio version.
    Looking at for example at: https://bitbucket.org/multicoreware/x265/src/425b583f25dbb57af86fc5c128548038954baf31/...e-view-default

    you would need to delete:
    Code:
    @mkdir 12bit
    Code:
    @cd 12bit
    cmake -G "Visual Studio 12 Win64" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON
    if exist x265.sln (
      MSBuild /property:Configuration="Release" x265.sln
      copy/y Release\x265-static.lib ..\8bit\x265-static-main12.lib
    )
    Code:
    if not exist x265-static-main12.lib (
      msg "%username%" "12bit build failed"
      exit 1
    )
    and exchange:
    Code:
    cmake -G "Visual Studio 12 Win64" ../../../source -DEXTRA_LIB="x265-static-main10.lib;x265-static-main12.lib" -DLINKED_10BIT=ON -DLINKED_12BIT=ON
    if exist x265.sln (
      MSBuild /property:Configuration="Release" x265.sln
      :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
      move Release\x265-static.lib x265-static-main.lib
      LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib x265-static-main12.lib
    )
    with:
    Code:
    cmake -G "Visual Studio 12 Win64" ../../../source -DEXTRA_LIB="x265-static-main10.lib" -DLINKED_10BIT=ON 
    if exist x265.sln (
      MSBuild /property:Configuration="Release" x265.sln
      :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
      move Release\x265-static.lib x265-static-main.lib
      LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib
    )
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  10. Originally Posted by Selur View Post
    If you are using Visual Studio, editing and/or using multilib.sh which is a shell script meant for linux enviroments, doesn't make any sense at all!

    What you need to edit and use is the multilib.bat which resides in the corresponding build/vc... folder which matches your Visual Studio version.
    Looking at for example at: https://bitbucket.org/multicoreware/x265/src/425b583f25dbb57af86fc5c128548038954baf31/...e-view-default

    you would need to delete:
    Code:
    @mkdir 12bit
    Code:
    @cd 12bit
    cmake -G "Visual Studio 12 Win64" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON
    if exist x265.sln (
      MSBuild /property:Configuration="Release" x265.sln
      copy/y Release\x265-static.lib ..\8bit\x265-static-main12.lib
    )
    Code:
    if not exist x265-static-main12.lib (
      msg "%username%" "12bit build failed"
      exit 1
    )
    and exchange:
    Code:
    cmake -G "Visual Studio 12 Win64" ../../../source -DEXTRA_LIB="x265-static-main10.lib;x265-static-main12.lib" -DLINKED_10BIT=ON -DLINKED_12BIT=ON
    if exist x265.sln (
      MSBuild /property:Configuration="Release" x265.sln
      :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
      move Release\x265-static.lib x265-static-main.lib
      LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib x265-static-main12.lib
    )
    with:
    Code:
    cmake -G "Visual Studio 12 Win64" ../../../source -DEXTRA_LIB="x265-static-main10.lib" -DLINKED_10BIT=ON 
    if exist x265.sln (
      MSBuild /property:Configuration="Release" x265.sln
      :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
      move Release\x265-static.lib x265-static-main.lib
      LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib
    )
    I'm using GCC. Should I delete all?
    Quote Quote  
  11. If you use GCC, you should edit the multilib.sh and remove everything related to the 12bit library.
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  12. I did exactly as you say, but it did not work here multilib.sh
    Quote Quote  
  13. Can't follow you, .... your are not usign the multilib.sh, but the makemulti.sh and that still contains lots of call related to 12bit,....
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  14. I'm sorry I misspelled.actually makemulti.sh. thats original. I do not edit.
    Quote Quote  
  15. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    New build with changed 2-pass VBV-CRF conditions (AFAIK, you have to add --vbv-maxrate {kbps} in 1st pass to enable the use of a CRF value for VBV-constrained CRF mode instead of a target bitrate for VBR mode in 2nd pass):

    x265 1.9+15-425b583f25db (GCC 5.3.0)
    Image Attached Files
    Last edited by LigH.de; 15th Feb 2016 at 03:17.
    Quote Quote  
  16. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 1.9+54-291beccb6760 with fixed 2-pass VBR rate control.
    Image Attached Files
    Quote Quote  
  17. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Some more bitrate control enhancements in x265 1.9+88-b6d8e66e7f71
    Image Attached Files
    Quote Quote  
  18. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 1.9+96-b09998b1256e should have fixed the bitrate control for zones.
    Image Attached Files
    Quote Quote  
  19. Am I the only one who is getting lower quality output now than x265 1.4?
    Quote Quote  
  20. For the same bitrate and fps? Yes, you are the only one.
    Quote Quote  
  21. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Experimental UHD Bluray support (--uhd-bd) in x265 1.9+106-c8ec86965e54; is there anyone who can test and confirm?
    Image Attached Files
    Quote Quote  
  22. Is there some sort of overview what this should do?
    http://x265.readthedocs.org/en/latest/cli.html?highlight=--uhd#cmdoption--uhd-bd isn't really informative and so a x265/H.265 specific overview would be helpful.
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  23. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    I don't know any other detailed documentation yet. For now you may have to inspect the patch source. Sneaker already found a few flaws, reported in the doom9 forum.
    Quote Quote  
  24. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Several fixes regarding UHD-BD, dithering of different color depths, and documentation clarifications:

    x265 1.9+125-40afead3177d
    Image Attached Files
    Quote Quote  
  25. Originally Posted by LigH.de View Post
    Several fixes regarding UHD-BD, dithering of different color depths, and documentation clarifications:

    x265 1.9+125-40afead3177d
    So x265 can encode UHD BD compliant for authoring software without a need to transcode?
    Quote Quote  
  26. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    I don't have any player or authoring tool, so I am not sure; if I followed the doom9 forum discussion involving a spec verifier well, I believe it is not yet done, there is an issue left regarding the structure of open GOPs (the number of contained frames may get counted beyond the maximum of allowed frames per GOP). And there may be still undetected issues... who knows. The number of available devices and authoring software is small. But if you set x265 up to comply with specified ranges and use only closed GOPs, the result should already be very compatible.
    Quote Quote  
  27. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 1.9+140-34a3d35c5f97: UHD-BD compatibility forces closed GOPs; --limit-refs clarified to be on/off; and a bunch of fixes and speed-ups (ARM implementations don't matter for x86 platform)
    Image Attached Files
    Quote Quote  
  28. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 1.9+150-00ea3784bd36: Unicode filenames support for output and stats; and some rate control improvements
    Image Attached Files
    Quote Quote  
  29. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 1.9+167-bebae72f9db7 provides a few changes regarding the grain handling, and a new tweak:

    Code:
       --[no-]recursion-skip         Enable early exit from recursion. Default enabled
    Image Attached Files
    Quote Quote  
  30. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 1.9+183-4723933fdec9: --slow-firstpass is now enabled as default; quantization is clipped in 2-pass with grain tuning; --qpfile and --csv support Unicode too.
    Image Attached Files
    Quote Quote  



Similar Threads