VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Page 51 of 73
FirstFirst ... 41 49 50 51 52 53 61 ... LastLast
Results 1,501 to 1,530 of 2190
Thread
  1. Member
    Join Date
    Nov 2002
    Location
    United States
    Search Comp PM
    I'm going to take a break from x265 for a while. Every new build gets slower and slower so there is no need for me to keep banging my head against the wall, hoping that someone has created a build that will encode HEVC faster than 5 fps. I'll check back in a few months to see if MCW has decided to concentrate on making the encoder faster. Besides, I should be outside enjoying the nice weather instead of sitting at the computer, waiting for another heart attack.
    Quote Quote  
  2. current version build with MinGW
    Quote Quote  
  3. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    jb_alvarado's media-autobuild_suite is going to work well again with MSYS2-64; x265 already builds with GCC 4.9.0; so there are experimental builds of the 4 EXE flavours. Yet, a few issues have to be fixed still...

    And because there was a stable-merge again, version 1.0+21-8963bc3aa2e1 with the usual MSYS (GCC 4.8.2).
    Last edited by LigH.de; 7th May 2014 at 03:38.
    Quote Quote  
  4. Hello everybody,
    does anybody knows how cmake gets his version info for x265 from hg? When I use the TortoiseHg installer pack to clone, I can compile x265 normal under windows with msys2/mingw-w64 and it gets also the correct version. But when I try to use the build in mercurial hg tool from msys2 it don't get the version number and cmake stops with errors.
    Quote Quote  
  5. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by jb_alvarado View Post
    Hello everybody,
    does anybody knows how cmake gets his version info for x265 from hg?
    The folders that contain cmake and hg MUST be in the "path".

    When I use the TortoiseHg installer pack to clone, I can compile x265 normal under windows with msys2/mingw-w64 and it gets also the correct version. But when I try to use the build in mercurial hg tool from msys2 it don't get the version number and cmake stops with errors.
    I still recommend the FULL Msys+MinGW package from Xhmikosr's site. Just un7zip, configure, enjoy.
    Also, I have no experience with TortoiseHg. The x265 wiki still must be read with some tons of salt (unfortunately).
    Image Attached Thumbnails Click image for larger version

Name:	path.png
Views:	285
Size:	19.4 KB
ID:	25024  

    Quote Quote  
  6. Hello El Heggunte,
    thanks for your answer! This doesn't help. I don't work with the windows path variable, I work with my msys profile, and there is the all in the path I think. When not than I think mercurial can not clone and cmake can not build.

    Is strange, I even don't install TortoiseHg, I only unpack the msi file, put the path in my profile and it work. I need to ask the developer from msys2.

    I was working before with msys1 and I think the new version is way smarter, so I don't want to go back.
    Quote Quote  
  7. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    commit 7d11f60 is here : /
    Image Attached Files
    Quote Quote  
  8. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    OK, time to join in again.
    Quote Quote  
  9. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Version 1.1 is coming "soon™", so there was a stable merge again. There have been many preset changes to make them a lot faster with only little quality penalty.

    Therefore: x265 1.0+151-108996798e78
    Quote Quote  
  10. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    being in possession of content with the usual amount of artifacts, ie, (tv sources) -- won't help with these kinds of upgrade efficiencies. but i'll have to test for myself and see if there really is any difference or penalty using an older x265 build once the x265 team update their portal with the latest build, since they don't update that area often. i'm at their mercy since i don't know how to compile for xp. and before you ask.. no, i don't go to sharing sites like mediafire. my pc is not equipt to handle (block) their ads.
    Quote Quote  
  11. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    commit d78f38b707ba "for the rest of the world"
    Image Attached Files
    Quote Quote  
  12. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 1.1+3-1fe42453d2e3 is up. Time to clean up my HEVC folder a bit and remove 0.8 versions.
    Quote Quote  
  13. For those who don't like MediaFire&Co I compiled and attached the lates (MinGW 32/64bit; 8bit/16bit) x265 versions.
    Image Attached Files
    Quote Quote  
  14. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Well, among many other file hosters, MediaFire is rather fair, IMHO; not too many ads, not too hard limits, quite compatible (even Opera 12 can handle it and block flash ads without disabling the download).
    Image Attached Files
    Quote Quote  
  15. Member
    Join Date
    Nov 2002
    Location
    United States
    Search Comp PM
    From what I understand, it doesn't make all presets faster but just speeds up the medium preset to pretty much do away with the need for other presets unless you are a glutton for punishment with super slow encoding speeds. The faster presets are no faster than before.

    Still a long way off if expected to replace x264. Like Ligh stated though, time to clean out all older x265 folders.


    EDIT:

    We have sped up the ultrafast preset by about 10 to 30% (bigger
    benefit at higher bit rates). There is a very small impact on encoding
    efficiency, but you can always increase efficiency by using a slower
    (higher quality) preset. We've also sped up the superfast, veryfast
    and faster presets in a similar way.
    This is contrary to what I read on doom9 the other day by x265.
    Last edited by DarrellS; 4th Jun 2014 at 08:33.
    Quote Quote  
  16. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Practical encoding speed will depend on many factors. If the bottleneck is reading the huge uncompressed source file from a slow harddisk (or an elaborately filtered AviSynth script via avs4x265 pipe), then faster calculations in x265 won't speed up anything. And supported CPU instructions may have some impact as well, even when the source is read fast.
    Quote Quote  
  17. Member
    Join Date
    Nov 2002
    Location
    United States
    Search Comp PM
    I encoded a 1080p clip at 15 fps so there is some improvement there but using the medium preset, I only got 3.2 fps. Also, I add --crt 18 to my presets and using the external encoder in Virtualdub, I get an anonymous pipe error on the medium preset and have to remove the --crt 18 from my command argument to get it to encode. The ultrafast preset ends up with almost double the bitrate as the medium preset.
    Quote Quote  
  18. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    There is no command line option "--crt". Maybe you mean "--crf".

    But it also depends on the position where you put options into a command line. At the wrong position, it may split an option from its argument, and the command line parsing gets confused.
    Quote Quote  
  19. Member
    Join Date
    Nov 2002
    Location
    United States
    Search Comp PM
    Whoa, I screwed that up pretty good. My first preset was correct but somehow I managed to hit the t key instead of f key, then copied and pasted to all my other encoders.

    Thanks for that. I doubt that I would've figured it out on my own. I need to get better reading glasses I guess.

    EDIT: Looks like I used -q 18 on ultrafast.
    Last edited by DarrellS; 4th Jun 2014 at 17:41.
    Quote Quote  
  20. Member
    Join Date
    Nov 2002
    Location
    United States
    Search Comp PM
    I guess I need to clean out everything and start over cause I can't get anything to work now. Gets to the last frame and crashes. None of my x265 presets work. I must've used an older encoder earlier today instead of the new one.
    Quote Quote  
  21. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Crashing during the after-encode summary in "ultrafast" and "superfast" presets is already a known issue to me. I notified the developers, they are about to fix it. A next release should work well again...
    Quote Quote  
  22. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Not_so_Off-Topic...

    Latest version of avs4x265 is 0.4 0_o

    http://kurtnoise.free.fr/x265/
    Quote Quote  
  23. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Uh, nice. It became tiny, doesn't include an x265 anymore. No changelog though, probably still does the same (feeding raw YUV and adding required parameters). Maybe does it include now suggested additions from the avs4x264 thread in the doom9 forum (which seem to got lost there, but I got an email notification about the disappeared reply)? It seems to support High Bit Depth script output, according to what I understand from the C sources.

    Ah, it is explained from here on.
    __

    P.S.: x265 1.1+35-495874699b0d on MediaFire and below.

    Another stable merge + one more useful patch. Presets ultrafast and superfast should not crash anymore during the summary.
    Image Attached Files
    Last edited by LigH.de; 5th Jun 2014 at 03:02.
    Quote Quote  
  24. Member
    Join Date
    Nov 2002
    Location
    United States
    Search Comp PM
    I can confirm that the crash problem is fixed in x265_1.1+35-495874699b0d but the encode speeds are much lower (10.39 fps) than yesterday and lower than the old version that I still have.
    Quote Quote  
  25. Member
    Join Date
    Nov 2002
    Location
    United States
    Search Comp PM
    I tried Fllear's build and encoded 1080p at 16.26 fps.

    VideoEnc: encoded 432 frames in 26.57s (16.26 fps), 483.14 kb/s
    Quote Quote  
  26. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    Халоу!
    Tired of all these samples!
    Can be viewed on the fresh and simple / amateur record on this > similarity video (sourсe).
    Quote Quote  
  27. Member
    Join Date
    Nov 2002
    Location
    United States
    Search Comp PM
    Something is wrong with 1.1+45. Every build that I tried would only encode 1920x1080 at 4.3 fps.
    Quote Quote  
  28. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    "C:\PROGRA~1\Hybrid\x265.exe" --tune ssim --preset slower --input - --input-res 1920x1080 --fps 50 --frames 19 --max-merge 5 --no-strong-intra-smoothing --weightb --b-adapt 1 --bitrate 2000 --psy-rd 0.5 --aq-mode 1 --no-cutree --sao-lcu-bounds 1 --colormatrix bt709 --output "C:\Users\PARADO~1\AppData\Local\Temp\x265_11_11_3 4_6710_01.265"
    x265 [info]: HEVC encoder version 1.1+45-e5656f1e1904
    x265 [info]: build info [Windows][ICC 1400][64 bit] 8bpp
    x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
    x265 [info]: WPP streams / pool / frames : 17 / 2 / 1
    x265 [info]: Main profile, Level-4.1 (Main tier)
    x265 [info]: CU size : 64
    x265 [info]: Max RQT depth inter / intra : 2 / 2
    x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 5
    x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
    x265 [info]: Lookahead / bframes / badapt : 30 / 8 / 1
    x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 3
    x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-2000 kbps / 1.0 / 0
    x265 [info]: tools: rect amp rd=6 psy-rd=0.5 lft sao-lcu signhide
    encoded 19 frames in 95.49s (0.20 fps), 2098.84 kb/s
    x265 [info]: frame I: 1 Avg QP:44.83 kb/s: 5971.60
    x265 [info]: frame P: 9 Avg QP:42.19 kb/s: 3493.07
    x265 [info]: frame B: 9 Avg QP:44.60 kb/s: 274.31
    x265 [info]: global : 19 Avg QP:43.47 kb/s: 2098.84
    x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
    x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
    x265 [info]: consecutive B-frames: 10.0% 90.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
    finished after 00:01:35.721

    - - - - -

    Overlooked

    Strip from the trees show that the encoder does not produce image correction with the next frame - stupid duplicates / not refer to changes (not subtracts).

    My suspicions seem to come true:
    > theory 1
    > theory 2

    Also > DivX

    Original


    Click image for larger version

Name:	orig-stup.jpg
Views:	210
Size:	895.6 KB
ID:	25584

    x265

    Click image for larger version

Name:	x265-stup.jpg
Views:	204
Size:	595.8 KB
ID:	25583
    Image Attached Files
    Last edited by Gravitator; 10th Jun 2014 at 23:15.
    Quote Quote  
  29. @Graviator: don't use psy-rd, it's known to produce artifacts
    Quote Quote  
  30. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    Originally Posted by Selur View Post
    @Graviator: don't use psy-rd, it's known to produce artifacts
    This is a clear example of the demonstration not only of psy, and also for the entire encodings! You will not be able to get rid of bands without awareness of this problem. - What do I disable or enable to the strip from trees gone?
    Quote Quote  



Similar Threads