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 56 of 73
FirstFirst ... 6 46 54 55 56 57 58 66 ... LastLast
Results 1,651 to 1,680 of 2166
Thread
  1. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Comparing SSIM values in Decibels might be a little more intuitive (similar to Sone as subjective loudness).
    Quote Quote  
  2. Originally Posted by Selur View Post
    x265 beat x264 with an SSIM of 0.98374 vs x264's 0.98134, making it about 15% better objective quality.
    How is a difference of 0.0024 15% percent?

    Since the SSIM values are nearly identical. (scaling differences can make small difference look a lot larger then they are )
    What about the file sizes? (Clearly with the same SSIM values, the file with the lower file size would be preferable)
    Hah, Detmek beat me to it. It's great to see so many Russian speakers and someone from Serbia here btw. Welcome to the nuthouse, Detmek.

    The file sizes are virtually the same so I didn't include them. But if you need to know, the music video is 6,600KB for the x264 output and 6564KB for x265, 1440 frames, 23.976 fps.
    1948 and 1967 KB for the second vid. 2333 frames, 60 fps.

    Also is there anything easy noticable different to the frames/scenes where x265 looses SSIM wise?
    Don't know, I haven't looked at them side by side yet.

    Originally Posted by Selur View Post
    @Detmek: Doh, thanks! I always forget that 0.98 is twice as good as 0.96 and that that looks x% better is not really that objective.
    "Objective" means that it can be measured, not that the measurements mean anything important. Evaluating the quality visually would be the subjective quality analysis.
    Yes, it's ******* confusing. The less accurate method is 'objective' while the better way is 'subjective' as if it's meaningless. The joys of the English language...

    Originally Posted by Ligh.de
    Comparing SSIM values in Decibels might be a little more intuitive (similar to Sone as subjective loudness).
    I don't find SSIM unintuitive at all. The rule of thumb is 0.99000+ is good quality and for cartoons/linear graphics 0.99500 is mandatory. Anything below 0.98000 can safely be dismissed as garbage which means you only need to double the bitrate to achieve 0.99000 perfection.
    Last edited by Mephesto; 28th Aug 2014 at 21:13.
    Quote Quote  
  3. Originally Posted by Mephesto View Post
    I've done another quality test, the first since I tried 1.0 back in May with disappointing results. 1.3 has really changed the game.

    With the 720x320 music video, x265 beat x264 with an SSIM of 0.98374 vs x264's 0.98134, making it about 15% better objective quality.
    The revolution is here, brothers and sisters. x265 has finally outclassed x264. Dunno if I'll be using it yet though, the speed was 1 fps for a 720x320 video. Jeez. 13 times slower. When I first got this i7 in 2010 it was a mother f**ing godsend that enabled me to encode 720p in realtime. No way in hell I'm going back to that mess I had with that Pentium D that was slow as shit despite being 4 GHZ.
    I know it's shameless self-promotion basically, but that's why I created this in the first place. Give it a go and let me know what you think. Current release lacks of psy-rdoq, but it's on my to do list. Not exactly swarming with requests to add it.
    Last edited by p-v-p; 29th Aug 2014 at 11:56.
    Quote Quote  
  4. p-v-p, I only use one computer so I don't need your program. Either way, my old Pentium D and Pentium 4 would only offer a 20% boost combined which isn't worth the double amount of power consumption.

    Now that I got a look at the videos I can somewhat answer Selur's question. Frame 139 was the frame with the worst SSIM value difference, x265 getting 0.945 and x264 getting 0.962. I posted all 3 below. You decide what's better quality as I can't tell.

    x264 preserved more high frequency details at the expense of the rest of the spectrum which left a lot of flat areas. x265 did not prioritize the high frequency details but preserved the low and medium frequency textures better, appearing somewhat more blurry than x264 but at the same time retaining distortion-free edges.

    I think this is more a problem of x265 misallocating proper bitrate to some areas that might need it.

    In general, x265 output throughout the video looks a little better, sort of like a good wavelet codec actually. There is none of the typical macroblock artifacts and noise/distortion around edges as with x264 so it's more pleasant on the eyes. The imperfections are difficult to spot without the source for comparison. With x264 they're obvious.

    It's a good start but no regular guy will notice any quality improvements until x265 achieves 50% better efficiency.
    Image Attached Thumbnails Click image for larger version

Name:	exgfsource139.PNG
Views:	1588
Size:	247.9 KB
ID:	27157  

    Click image for larger version

Name:	exgfx264139.PNG
Views:	1551
Size:	214.0 KB
ID:	27158  

    Click image for larger version

Name:	exgfx265139.PNG
Views:	1561
Size:	233.0 KB
ID:	27159  

    Quote Quote  
  5. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    Originally Posted by mephesto View Post
    it's a good start but no regular guy will notice any quality improvements until x265 achieves 50% better efficiency.
    Hi,
    HD ~15%, FHD ~30%, UHD ~50%.
    Last edited by Gravitator; 30th Aug 2014 at 11:07.
    Quote Quote  
  6. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    Originally Posted by Mephesto View Post
    It's a good start but no regular guy will notice any quality improvements until x265 achieves 50% better efficiency.
    Mephesto,
    What is your x265 command-line? I recommend using --preset slow, slower or veryslow preset. Add --psy-rd 0.8 --psy-rdoq 1.0 for low bit rates. You can increase these values for higher bit rates. For x264 I just use --preset veryslow. We regularly produce x265 encodes that look better than x264 encodes at twice the bitrate.

    For example, here is an encode I did last week of "Tears of Steel" (1080P lossless YUV encoded from lossless PNG image sequence). The settings used are shown here.
    Here are the actual encoded video files...
    Tears_400_x264.mp4
    Tears_400_x265.mp4

    Quote Quote  
  7. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    Originally Posted by x265 View Post
    Here are the actual encoded video files...
    Tears_400_x264.mp4
    Tears_400_x265.mp4
    Very cool and presentable
    Quote Quote  
  8. Originally Posted by x265 View Post
    Originally Posted by Mephesto View Post
    It's a good start but no regular guy will notice any quality improvements until x265 achieves 50% better efficiency.
    Mephesto,
    What is your x265 command-line? I recommend using --preset slow, slower or veryslow preset. Add --psy-rd 0.8 --psy-rdoq 1.0 for low bit rates. You can increase these values for higher bit rates. For x264 I just use --preset veryslow. We regularly produce x265 encodes that look better than x264 encodes at twice the bitrate.

    For example, here is an encode I did last week of "Tears of Steel" (1080P lossless YUV encoded from lossless PNG image sequence). The settings used are shown here.
    Here are the actual encoded video files...
    Tears_400_x264.mp4
    Tears_400_x265.mp4

    That is indeed impressive, but I did exactly what you said just now and the x265 output scored a little better in SSIM but visually they still only marginally outclass x264. This video is only 720x320 though so maybe it isn't as efficient here. But H264 was designed for 720p and above when it came out but it still competed with XVID at half the bitrate on any resolution. So I pray x265 will be great for things besides UHD as well.

    I'd test HD stuff too but I'm only getting 1 fps on this 320p video so I seriously don't have the patience.
    Quote Quote  
  9. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    Originally Posted by Mephesto View Post
    That is indeed impressive, but I did exactly what you said just now and the x265 output scored a little better in SSIM but visually they still only marginally outclass x264. This video is only 720x320 though so maybe it isn't as efficient here. But H264 was designed for 720p and above when it came out but it still competed with XVID at half the bitrate on any resolution. So I pray x265 will be great for things besides UHD as well.

    I'd test HD stuff too but I'm only getting 1 fps on this 320p video so I seriously don't have the patience.
    We would need to know more information in order to help you. Can you tell us more about your source video (bit rate, quality, type of content, etc.)? Can you share your full command-line, and your results (bit rate, speed, PSNR or SSIM measurements)?

    If your source is already highly compressed, I'm guessing that you want x265 to shrink your video further (maybe by half) without a noticeable loss in quality. For this your best bet would either be constant rate factor (CRF) mode, or 2 pass ABR. Each delivers similar quality. CRF (with veryslow preset) is slightly faster than 2 pass ABR . 2 pass ABR has the advantage of giving you the ability to specify a target bit rate. So you can set --bitrate in x265 to half the value of your source video, and you'll probably be happy with the result.
    Quote Quote  
  10. Originally Posted by x265 View Post
    We would need to know more information in order to help you. Can you tell us more about your source video (bit rate, quality, type of content, etc.)? Can you share your full command-line, and your results (bit rate, speed, PSNR or SSIM measurements)?
    I already posted all that information in the prior posts.
    What I didn't mention was that the first video was sourced from a 1080p x264-compressed video. That is why I resized it to 720x320. I would never use an already-compressed video as a valid source.

    If your source is already highly compressed,
    Highly compressed? Nah, it's 5000 kb/s 1920x1080. About average I'd say.

    I'll be glad to give any other information you need, including the videos themselves and the SSIM .CSVs.
    Quote Quote  
  11. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Let's start with complete command line options for each encoder.
    Quote Quote  
  12. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 1.3+58-c5624effb73c backed out a possibly incomplete bugfix regarding B-frame bitrate prediction in VBV, causing problems in CBR mode, but re-enabled and fixed --cu-lossless.
    Quote Quote  
  13. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    Used x265_1.3+59 (x64) - Slices are still coming from the future.
    Original sample > park_joy (mega.co.nz).
    Image Attached Files
    Quote Quote  
  14. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    Who has the original sample "Kristen and Sara" ?
    Quote Quote  
  15. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by Gravitator View Post
    Who has the original sample "Kristen and Sara" ?
    I've sent you a P.M.
    Quote Quote  
  16. Originally Posted by LigH.de View Post
    Let's start with complete command line options for each encoder.
    Mine? x265:
    Code:
    avs2yuv exgf.avs -o - | x265 --y4m --crf 22.6 --preset veryslow --psy-rd 0.8 --psy-rdoq 1.0 -o exgf.hevc -
    For x264 I don't have the commandline because this was done back in Nov. 2013. But as you can see, maximum settings except 8 refs, 16 merange and umh ME.
    Code:
    cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=11 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=240 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.70 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=2:1.00
    Quote Quote  
  17. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    build 1.3+95-93db2f53fe57
    Image Attached Thumbnails Click image for larger version

Name:	dynamite-channel-2.jpg
Views:	2548
Size:	110.9 KB
ID:	27288  

    Image Attached Files
    Quote Quote  
  18. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    build 1.3+114-795878af3973
    Image Attached Thumbnails Click image for larger version

Name:	zx-doll.jpg
Views:	1282
Size:	92.5 KB
ID:	27297  

    Image Attached Files
    Quote Quote  
  19. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    RealDoll?
    Quote Quote  
  20. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by LigH.de View Post
    RealDoll?
    Nope, that's a CandyGirl:

    Code:
    http://en.wikipedia.org/wiki/CandyGirl
    Saber Marionettes F.T.W. \o/

    Last edited by El Heggunte; 6th Sep 2014 at 10:53.
    Quote Quote  
  21. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    After so many recent patches with speed-ups and fixes, now is probably a good time to release another build: x265 1.3+145-44cb33846e0e

    Unfortunately, most speed-ups seem to be relevant only for AVX2 supporting CPUs, which I don't own... but a few are also rather generic.
    Image Attached Files
    Quote Quote  
  22. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    build 1.3+165-3fc141aa74b5
    Image Attached Thumbnails Click image for larger version

Name:	silky-moon.jpg
Views:	288
Size:	157.6 KB
ID:	27351  

    Image Attached Files
    Quote Quote  
  23. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    Earlier I wrote about the remark of contact with pieces of frames from the following frames > Slices of the future

    - Similar description for the codec VP9 > @zerowalker ("green pig" )
    Quote Quote  
  24. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    In general, it is not wrong for B frames to have slices with references to future P or I frames. That's exactly the purpose of B frames: To optimize size by referencing most similar sources with bidirectional prediction. So I wonder why you are complaining about what is a feature on purpose ... except it goes wrong in a way that it introduces annoying compression artefacts, then it would be a bug to be fixed.
    __

    P.S.:

    Another "merge with stable" plus a few fixes x265 1.3+185-2fb61cc75152
    Image Attached Files
    Last edited by LigH.de; 15th Sep 2014 at 04:55.
    Quote Quote  
  25. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    Originally Posted by LigH.de View Post
    So I wonder why you are complaining about what is a feature on purpose ...
    So this is a problem in my settings or it is a feature of x265 crooked build frames?
    Quote Quote  
  26. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    x265 1.3+185-2fb61cc75152 - also not the right construction;
    frame №87 (B) - shows a part of the umbrella comes from future frames.
    Original sample > park_joy (mega.co.nz).

    Click image for larger version

Name:	22222.jpg
Views:	1094
Size:	99.3 KB
ID:	27457
    Image Attached Files
    Last edited by Gravitator; 15th Sep 2014 at 07:09.
    Quote Quote  
  27. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    I'll have to analyze your original video first and check if I can reproduce such artefacts... But it makes me wonder if the original video already has interlacing or blending. If x265 works correctly, then it should calculate that this is not a best-matching refrence.

    Your complete x265 command line may be useful to reproduce it.

    I see a pink flickering at the end of your MKV sample. A good hint that this is not intended.
    __

    P.S.: I am not good at interpreting a Hybrid preset; but the bits I do understand make me wonder if you are going for a codec overkill: up to 16 cons. B frames, 16 Ref. frames, I:P ratio 1.7, P:B ratio 1.7 ... yes, you are trying to force many B frames. But what is it good for?
    __

    OK, tested a bit.

    Only 6800 kbps for 1080p is little. It provokes quantization factors around 40 sometimes. With so much pressure, the encoder has no chance but to use even vaguely similar parts, even of future scenes, to spare bitrate, and thus has no choice but messes with the chrominance.

    This test is way too extreme.
    Last edited by LigH.de; 15th Sep 2014 at 08:20.
    Quote Quote  
  28. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    But it makes me wonder if the original video already has interlacing or blending.
    I always turn off the deinterlace mode: Auto (to encode a bit faster).
    Click image for larger version

Name:	dein.jpg
Views:	1082
Size:	55.5 KB
ID:	27461
    Quote Quote  
  29. Member
    Join Date
    Jan 2014
    Location
    Kazakhstan
    Search Comp PM
    up to 16 cons. B frames, 16 Ref. frames
    Maximum free choice for the encoder.

    I:P ratio 1.7, P:B ratio 1.7
    Just my eye pleasant.
    Quote Quote  
  30. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Hey, even preset "placebo" uses only max. 8 consecutive B frames and max. 5 references to choose from. Your set is even more a waste of time, way too much choice for the encoder, yet too little bitrate to be able to reproduce the original video satisfyingly.

    Your set is the proof that no combination of any other options can substitute enough bitrate.
    __

    P.S.:

    What you call "future references" seems to me like a preference of weighted B frames (generating blends) over motion vectors. Now that is indeed a point to discuss with the developers. The reconstruction appears to have blends which don't exist in the original video.

    By the way, Derf's 1080p Y4M source is a lot more detailed than the ProRes file. But also has a longer playing time (the ProRes MOV only has the last 2 of 10 seconds from the Y4M), a download of 1483 MB.
    Last edited by LigH.de; 15th Sep 2014 at 08:54.
    Quote Quote  



Similar Threads