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 1 of 3
1 2 3 LastLast
Results 1 to 30 of 65
Thread
  1. Filling a user request for some AVC 8bit 4:2:0 encoders. Apparently the "best quality" encodes they've seen were using Sony Vegas AVC, or Apple AVC used in things such as Apple movie trailers.

    It's common knowledge in the industry that Sony Vegas AVC and Apple AVC are among the worst. Everything looks good by themselves. You need to actually compare it to something else to see how something measure up. I look pretty good in the gym. But when the local pro bodybuilder walks in, I don't look so good anymore...

    This topic been beaten to death already among these particular encoders, many tests, many sources. But someone might be new to video encoding or want to see some tests for nostalgic reasons. What's new is VMAF , the Netflix developed metric. This was calculated in vapoursynth, with harmonic mean. You can calculate with ffmpeg too if it has been compiled with libvmaf.

    Netflix Meridian. Sneaker converted a sample to 1920x1080 8bit 4:2:0 from the 300GB file for testing
    https://mega.nz/#F!BlNDGIgJ!7lBUBs61l1oiIIBScrMyYg

    It's a bit atypical because it's "59.94p" ; and shutter angle looks a bit weird compared to a traditional theatrical production.

    Bitrates targets chosen based on Netflix's measured streaming bandwidth rates. 1920x1080p60 @ 6960kbps. In reality it varies by conditions and particular stream - but gives a rough estimate
    https://www.howtogeek.com/338983/how-much-data-does-netflix-use/

    Notes:
    Highest quality preset (not placebo for x264), 2pass if possible, match max keyframe interval if possible. No tuning/adjustments unless otherwise specified. If encoder over/undershot by a lot, I redid to hopefully get within +/- 1%. Ended up ~ 6 and 7.5 Mb/s for 2 data points for each

    Mainconcept AVC (Totalcode)
    Slowest/Best quality, 2pass. Max keyint 250. Ref16. Weightp enabled. Only allows Max 3 bframes. Bref and Bpyramid off by default on the best preset. If you enable it cuts references by 1. In my experience, MC does better without b-pyramid and b-ref. Has settings for AQ (brightness, contrast, complexity), but left at default values .

    Apple AVC
    Not many options. Best quality, multipass. Max keyframe set to 250, but it looks capped to 120 when examining the stream.

    Sony Vegas AVC
    Not many options. CABAC, High Profile. No multipass. CPU only chosen. Keyframes look placed every 30 (no control over it). If you examine the stream, no b-frames. Well known by Vegas users. Usually this means not even a chance in of achieving decent compression efficiency rates, compared to others that do offer b-frames

    X264
    Preset very slow, otherwise default



    I can post some screenshots later or if there is interest I can post encodes using different settings/bitrate time permitting. Speedwise Vegas > Apple > x264 > MC on those settings

    Feel free to add other encoders / tests.

    EDIT: I made a mistake for VMAF calculations ; I double checked with official tools (vmafossexec) added ffmpeg PSNR , SSIM results. See below
    Image Attached Files
    Last edited by poisondeathray; 16th Oct 2019 at 22:12.
    Quote Quote  
  2. Thanks for this, if truth be told I barely see a difference and in many ways I prefer to MC encode, which I know you're going to use as proof of my "bias".

    I won't even mention that you cheated:

    Has settings for AQ (brightness, contrast, complexity), but left at default values .
    I would like if you repeated the MC test with each one turned on to max and then with all three turned up to max, unless of course it's only one at a time, in which case ignore the last part.
    Quote Quote  
  3. Originally Posted by sophisticles View Post
    Thanks for this, if truth be told I barely see a difference and in many ways I prefer to MC encode, which I know you're going to use as proof of my "bias".
    This isn't proof of your "bias". Your bias is anything that has to do with x264. Anyone that takes a cursory look at your posts can see this

    But it's ok to prefer something over another. Some people like red better than blue for example. Human perception varies greatly

    Can you describe why you prefer MC encodes ? What characteristics do you like about it? Or dislike about Apple, or Sony, or x264 ? (or maybe certain characteristics you like or dislike from Apple/Sony/x264). How would you compare and contrast the MC encode or x264 encode in general terms?

    And how would you rank them in similarity to the source ? Not necessarily "what you prefer"

    I won't even mention that you cheated:

    Has settings for AQ (brightness, contrast, complexity), but left at default values .
    How is it "cheating" ? If I was cheating, why would I even mention that ? I'd be a pretty dumb cheater ...

    But didn't you say all things PSY and AQ were "bad"? If this is going to produce worse results, why bother ?

    x264 has a bunch of additional settings too that I left at default setting, why didn't you accuse me of "cheating" there too ?



    I would like if you repeated the MC test with each one turned on to max and then with all three turned up to max, unless of course it's only one at a time, in which case ignore the last part.
    Sure thing, but I have other things to do. But I'll try to do them in the next few days for sure

    If you go back 8-10 years, you can see I compared those modes in some tests.
    Quote Quote  
  4. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    Have you thought about the Adobe PP AVC encoder or are you worried about a RGB --> YUV loss?
    Quote Quote  
  5. Originally Posted by KarMa View Post
    Have you thought about the Adobe PP AVC encoder or are you worried about a RGB --> YUV loss?

    PP/AME doesn't convert to RGB, unless you have some RGB filter or process. It's one of the few YUV capable NLE editors

    The Adobe PP AVC encoder is a lower end version licensed from Mainconcept, with fewer options.
    Quote Quote  
  6. some screenshots zipped up
    Image Attached Files
    Quote Quote  
  7. Originally Posted by poisondeathray View Post
    Filling a user request for some AVC 8bit 4:2:0 encoders. Apparently the "best quality" encodes they've seen were using Sony Vegas AVC, or Apple AVC used in things such as Apple movie trailers.

    It's common knowledge in the industry that Sony Vegas AVC and Apple AVC are among the worst. Everything looks good by themselves. You need to actually compare it to something else to see how something measure up. I look pretty good in the gym. But when the local pro bodybuilder walks in, I don't look so good anymore...

    This topic been beaten to death already among these particular encoders, many tests, many sources. But someone might be new to video encoding or want to see some tests for nostalgic reasons. What's new is VMAF , the Netflix developed metric. This was calculated in vapoursynth, with harmonic mean. You can calculate with ffmpeg too if it has been compiled with libvmaf.

    Netflix Meridian. Sneaker converted a sample to 1920x1080 8bit 4:2:0 from the 300GB file for testing
    https://mega.nz/#F!BlNDGIgJ!7lBUBs61l1oiIIBScrMyYg

    It's a bit atypical because it's "59.94p" ; and shutter angle looks a bit weird compared to a traditional theatrical production.

    Bitrates targets chosen based on Netflix's measured streaming bandwidth rates. 1920x1080p60 @ 6960kbps. In reality it varies by conditions and particular stream - but gives a rough estimate
    https://www.howtogeek.com/338983/how-much-data-does-netflix-use/

    Notes:
    Highest quality preset (not placebo for x264), 2pass if possible, match max keyframe interval if possible. No tuning/adjustments unless otherwise specified. If encoder over/undershot by a lot, I redid to hopefully get within +/- 1%. Ended up ~ 6 and 7.5 Mb/s for 2 data points for each

    Mainconcept AVC (Totalcode)
    Slowest/Best quality, 2pass. Max keyint 250. Ref16. Weightp enabled. Only allows Max 3 bframes. Bref and Bpyramid off by default on the best preset. If you enable it cuts references by 1. In my experience, MC does better without b-pyramid and b-ref. Has settings for AQ (brightness, contrast, complexity), but left at default values .

    Apple AVC
    Not many options. Best quality, multipass. Max keyframe set to 250, but it looks capped to 120 when examining the stream.

    Sony Vegas AVC
    Not many options. CABAC, High Profile. No multipass. CPU only chosen. Keyframes look placed every 30 (no control over it). If you examine the stream, no b-frames. Well known by Vegas users. Usually this means not even a chance in of achieving decent compression efficiency rates, compared to others that do offer b-frames

    X264
    Preset very slow, otherwise default

    sorry for the ugly graph
    Image
    [Attachment 50444 - Click to enlarge]


    I can post some screenshots later or if there is interest I can post encodes using different settings/bitrate time permitting. Speedwise Vegas > Apple > x264 > MC on those settings

    Feel free to add other encoders / tests.
    Interesting. Any chance to add NVEncC64 h264 (Pascal, Turing) to the set?

    Added:
    Encoded with 1050Ti (Pascal), NVCEncC64 1-passVBR constant quality 7.3Mbps (36.0MB .mkv)

    Added2:
    Files attached
    Commandline (not optimized, probably):
    Code:
    NVEncC64.exe --avhw -i "meridien_.mp4" --fps 59.940 --codec h264 --profile high --level auto --sar 1:1 --lookahead 32 --vbrhq 0 --vbr-quality 30.00 --aq --aq-strength 8 --gop-len 24 --ref 3 --nonrefp --bframes 3 --bref-mode middle --mv-precision Q-pel --cabac --deblock --preset quality --colormatrix bt709 --output-res 1920x1080 --max-bitrate 40000 --bluray --output "meridien_.264"
    Image Attached Thumbnails Click image for larger version

Name:	1200_NVEncC64_1-passVBR_7.3Mbps_.png
Views:	8
Size:	1.45 MB
ID:	50446  

    Click image for larger version

Name:	2050_NVEncC64_1-passVBR_7.3Mbps_.png
Views:	7
Size:	1.32 MB
ID:	50447  

    Image Attached Files
    Last edited by Sharc; 8th Oct 2019 at 06:40. Reason: Attachements added
    Quote Quote  
  8. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    Maybe you can post the video Sharc, and give more detail on how you encoded it (ffmpeg?).
    Quote Quote  
  9. I edited my post. Video file and commandline now attached.
    I don't know how to do the VMAF test .

    B.t.w. I think this source compresses very well.
    Last edited by Sharc; 8th Oct 2019 at 06:59.
    Quote Quote  
  10. Originally Posted by poisondeathray View Post
    This isn't proof of your "bias". Your bias is anything that has to do with x264. Anyone that takes a cursory look at your posts can see this

    But it's ok to prefer something over another. Some people like red better than blue for example. Human perception varies greatly

    Can you describe why you prefer MC encodes ? What characteristics do you like about it? Or dislike about Apple, or Sony, or x264 ? (or maybe certain characteristics you like or dislike from Apple/Sony/x264). How would you compare and contrast the MC encode or x264 encode in general terms?

    And how would you rank them in similarity to the source ? Not necessarily "what you prefer"

    How is it "cheating" ? If I was cheating, why would I even mention that ? I'd be a pretty dumb cheater ...

    But didn't you say all things PSY and AQ were "bad"? If this is going to produce worse results, why bother ?

    x264 has a bunch of additional settings too that I left at default setting, why didn't you accuse me of "cheating" there too ?
    In order:

    My "bias" isn't against x264 per se, it's against the developers' lines of crap they used to promote their software and it's with user such as yourself who accepted their lies as gospel and then went out of their ways to promote it as if it was some universal truth never to be questioned.

    I like the MC encode better because to me the colors appear "more natural" and "richer" at the same time, I just find it visually more pleasing. This doesn't necessarily mean that it's closer to the original, I haven't seen the version you used as source, so it's impossible to know which one is closer to the source.

    Since you mention the Apple encoder, to me it appeared a bit soft and maybe even "washed out", but that leads me to my next question, are you using a Mac? If not, are you using Quick Time Pro or that free Quick Time alternative? I will admit that I have no proof, but to me, if you are using QT Pro or QT Alternative on Windows to judge the Apple encoder, I think you are unfairly biasing against Apple. I strongly suspect, based on Apple's history as a company, that they save the best options for their platform and so if you wanted to see the best Apple's encoder is capable of you would need to use Final Cut Pro:

    https://www.apple.com/final-cut-pro/specs/

    You will note that the encoder supports a ton of features, such as HDR and HEVC, you have purposely skewed the results if you do not acknowledge using a water down version of their encoder.

    It's cheating because of your stance on the importance of AQ for all encoders, so from your point of view, to not use a feature that you place so much importance on is tantamount to cheating.

    You used x264 + very slow, meaning it used 8 b-frames, 8 reference frames, all psy optimizations enabled, b pyramid, and so on, there are no "additional settings", you basically used x264's "mastering quality" mode and then purposely kneecapped the other encoders.

    But worst of all, for a guy that has spent years and hundreds of posts repeatedly saying that objective metrics can't be trusted, only your eyes can validly judge quality, you then turn around and use an artificial metric to "prove" x264's superiority. So when an artificial metric, after optimizing x264's options and purposely limiting competing encoders options, shows x264 winning, then you accept the results, but when it shows x264 losing, then they can't be trusted, the testers were biased/incompetent/etc.

    In the words of the late Dennis Green, you are what I thought you were.
    Quote Quote  
  11. Originally Posted by KarMa View Post
    Have you thought about the Adobe PP AVC encoder or are you worried about a RGB --> YUV loss?
    Or were you thinking that a NLE would be what most people would be using? It would be more representative of what you see for a typical user. I'll add it with the others runs

    I forgot to add notes about how to avoid RGB conversion for other tools, or the dreaded "computer RGB" in vegas ; or how to even get them to "read" a lossless x264 file. The "trick" is to use uncompressed 8bit4:2:0 with fourcc "IYUV" configuration. Newer versions of Adobe will actually accept lossless x264 in the 8bit4:2:0 , and it's truly lossless without RGB conversion. You can't say the same about "lossless" YUV codecs like utvideo, huffyuv (and the original only has a 4:2:2, not 4:2:0), lagarith, etc - those get converted to RGB in most windows NLE's, so they are not lossless. When you don't control for all those other variables, sometimes you get inaccurate results like color shifts, clipping, and it put that particular encoder at a disadvantage.




    Originally Posted by Sharc View Post

    Interesting. Any chance to add NVEncC64 h264 (Pascal, Turing) to the set?
    I don't have Turing, sneaker does . If someone posts that I'll add it to the VMAF when I get a chance




    Originally Posted by sophisticles View Post

    My "bias" isn't against x264 per se, it's against the developers' lines of crap they used to promote their software and it's with user such as yourself who accepted their lies as gospel and then went out of their ways to promote it as if it was some universal truth never to be questioned.
    If you look back, they get (got) questioned all the time , grilled.

    You can acknowledge that they have universal truth to the how the inner workings of the code work, or what setting does what - and people that read the code can verify.

    BUT - they were NOT the universal truth on how the encoder or some settings actually worked or produced results in real tests or real situations. People complained and questioned them all the time about fades and banding, this or that. They were not immune to scrutiny - It's that complaining and feedback (aka "whining") that helped improve x264 quickly . When there was a problem, it got reported, things got fixed or patched sometimes the same day. That large user base was essentially a big beta tester user base


    I like the MC encode better because to me the colors appear "more natural" and "richer" at the same time, I just find it visually more pleasing. This doesn't necessarily mean that it's closer to the original, I haven't seen the version you used as source, so it's impossible to know which one is closer to the source.
    Ok - That's the distinction I want to make clear

    If you have a crappy source, full of blocking, artifacts, ugly mess. A great encoder would reproduce that bloody mess faithfully.

    Probably nobody would "prefer" that , but that would be the technically better encoder

    Someone once told me (paraphrasing here) , that a content author spends a lot of time/money to create a certain look. The gist of it was they don't want you to mess with that look. The goal here is to get something closer to the source

    Since you mention the Apple encoder, to me it appeared a bit soft and maybe even "washed out", but that leads me to my next question, are you using a Mac? If not, are you using Quick Time Pro or that free Quick Time alternative? I will admit that I have no proof, but to me, if you are using QT Pro or QT Alternative on Windows to judge the Apple encoder, I think you are unfairly biasing against Apple. I strongly suspect, based on Apple's history as a company, that they save the best options for their platform and so if you wanted to see the best Apple's encoder is capable of you would need to use Final Cut Pro:

    https://www.apple.com/final-cut-pro/specs/

    You will note that the encoder supports a ton of features, such as HDR and HEVC, you have purposely skewed the results if you do not acknowledge using a water down version of their encoder.
    This is actually for FCPX (not FCP) - HEVC is not AVC ; and HDR isn't properly supported by 8bit, nor is this an HDR stream sample

    We are doing AVC tests. I used QT Pro. This is the based on the same library and settings used to encode the fabled Apple Movie Trailers of yesteryear. Look at mediainfo for the reference frames, and you can check the GOP makeup of I,B,P frames with a stream analyzer , it's the same . You can download the PDF manual of fcpx compressor and check. It's very simple interface with a few sliders. Someone with a Mac can feel free to add those encodes, but it doesn't have advanced settings; you wouldn't be able to up the reference frames to 16 or b-frames to 8 for example.


    It's cheating because of your stance on the importance of AQ for all encoders, so from your point of view, to not use a feature that you place so much importance on is tantamount to cheating.
    But if you read my earlier analysis way back , the short recap is MC's AQ doesn't work so well. It's implementation wasn't as good as x264's . I'll post those versions later. Even HCEnc, with the x264 AQ implementation ported shows more dramatic results. I posted examples where you gradually increase and you see the effect of what AQ is actually doing

    In my experience, MC's AQ implementation is better left to default at least visually speaking. But I'll add VMAF too and see what it thinks about those other versions

    You used x264 + very slow, meaning it used 8 b-frames, 8 reference frames, all psy optimizations enabled, b pyramid, and so on, there are no "additional settings", you basically used x264's "mastering quality" mode and then purposely kneecapped the other encoders.
    It's actually 16 ref (check mediainfo) . I tried to even out everything, 16ref etc...Only MC can hit 16 (default is 5 for "best"). The others can't do 8 b-frames. I tweaked everything as high as possible in that encoder.

    For x264 not all Psy optimizations; and they aren't tweaked. It's default, AQ mode default is 1, strength 1, psy-rd 1. No psy-trellis or other AQ modes. The proper way is to adjust and tune the encoder for the content. So this is technically "handicapping" x264 as well. You could have also used more b-frames. You also have --tune and presets like film . A simple cartoon might use other settings etc.. A casual user might just use presets and not tweak any other settings (except CRF or bitrate)

    If you want to be realistic, I should be using the lower end versions, because that's what people would be using. Such as exporting from a NLE like Adobe. I'll add those

    But worst of all, for a guy that has spent years and hundreds of posts repeatedly saying that objective metrics can't be trusted, only your eyes can validly judge quality, you then turn around and use an artificial metric to "prove" x264's superiority. So when an artificial metric, after optimizing x264's options and purposely limiting competing encoders options, shows x264 winning, then you accept the results, but when it shows x264 losing, then they can't be trusted, the testers were biased/incompetent/etc.

    In the words of the late Dennis Green, you are what I thought you were.

    I'm not "proving" anything with VMAF. I'm only adding it because it's the new shiny toy from Netfilx. We never had it back then when doing all those tests. The old metrics reported certain results, what does this shiny new toy say? And how does it correlate with what you "see" ?

    VMAF is commonly perceived as one of the better modern metrics that takes into account human subjective perception. Note that VMAF has various issue too ; but they are constantly improving it - you can't say that about the many other metrics .

    I'm saying the same thing I've always said - I'm telling you NOT to trust it, at least not blindly. Be careful. I'm asking you to correlate the results with what you "see" in terms of similarity to the source. That's what they did when training models, but there is so much variation in human perception. I said the same thing when x264 "won" with the other metrics way back. Don't put a lot of weight into them, you need to use your eyes. They aren't perfect and easily tricked. I even proved it with examples.

    It's just 1 metric, and this is just 1 test, another data point. You need to look at other samples, different genres (eg. cartoons, video games, action movies, sci fi , tearjerker drama, sporting event, etc..) , look at other tests and correlate them with what you see . If all the tests, subjective and objective move in the same direction and suggest the same thing, then it's stronger than just 1 test saying something
    Last edited by poisondeathray; 8th Oct 2019 at 16:19.
    Quote Quote  
  12. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    Decided to throw in my AMD RX460 card with its VCE 3.4, by downloading the 2.7GB source and encoding using FFMPEG with the h264_amf. The earlier cards supported B frames but this version and later does not due to the included HEVC encoder. So this card is just I frames and P frames.

    For the 6000kb version I CBR with the below plus setting, plus setting the GOP from 10-250 and 2-Pass. I would have done both with CQP but minor changes in the P quantizer causes unusual jumps in bitrate, so 6000kb was not possible with CQP.

    Code:
    -rc cbr -quality quality -profile high -coder cabac -me_half_pel true -me_quarter_pel true -preanalysis true -vbaq true
    For the 7500kb I did CQP with the below plus setting, plus setting the GOP from 10-250.

    Code:
    -rc cqp -qp_i 21 -qp_p 25.5 -quality quality -profile high -coder cabac -me_half_pel true -me_quarter_pel true -preanalysis true
    The AMD encodings seem to be the only one that doesn't really even attempt to encode the digital noise at these bitrates but yet will try to get all the detail on the car seats, which is interesting. There are different speed presets, with me using the Quality preset, but the speed hit is massive and the efficiency gain is barely noticeable. I mostly use the GPU for the HEVC encoding.
    Image Attached Files
    Quote Quote  
  13. Originally Posted by poisondeathray View Post
    This is actually for FCPX (not FCP) - HEVC is not AVC ; and HDR isn't properly supported by 8bit, nor is this an HDR stream sample

    We are doing AVC tests. I used QT Pro. This is the based on the same library and settings used to encode the fabled Apple Movie Trailers of yesteryear. Look at mediainfo for the reference frames, and you can check the GOP makeup of I,B,P frames with a stream analyzer , it's the same . You can download the PDF manual of fcpx compressor and check. It's very simple interface with a few sliders. Someone with a Mac can feel free to add those encodes, but it doesn't have advanced settings; you wouldn't be able to up the reference frames to 16 or b-frames to 8 for example.
    I was pointing out that Apple's "encoder" is actually capable of much more than some simple AVC encodes.

    And do you really believe that Apple, the company that has no problem artificially slowing down hardware over time to force an "upgrade", the company that has perhaps the most closed ecosystem in the tech world, with them actively fighting to prevent Windows from running on their systems and them first suing, then buying out Pear OS, a Linux based OSX clone that they considered a threat, would actually sell to the public an AVC encoder (QT Pro), that runs on Windows, and is no longer even supported:

    https://support.apple.com/en-us/HT201175

    That is the same as that found on it's flagship, professional grade Final Cut Pro X, which costs $300 and only runs on Mac?

    The same company that sells a $5000 ProRes accelerator card that only works with said FCPX?

    You can't possibly believe that the pirated version of QT Pro you downloaded from some torrent site 5 years ago is the same thing as that found on the latest and greatest FCPX? Can you? Really?!?
    Quote Quote  
  14. Originally Posted by sophisticles View Post

    I was pointing out that Apple's "encoder" is actually capable of much more than some simple AVC encodes.
    But for AVC, it's only capable of simple encodes .

    Did you look at the FCPX and Compressor manuals ? It's quite limited for AVC options. If you look at google images, it's quite basic . Same AVC options as the old FCP7 and QTPro for AVC . Basically no options besides quality, Key frame interval, 1 or 2 pass


    And do you really believe that Apple, the company that has no problem artificially slowing down hardware over time to force an "upgrade", the company that has perhaps the most closed ecosystem in the tech world, with them actively fighting to prevent Windows from running on their systems and them first suing, then buying out Pear OS, a Linux based OSX clone that they considered a threat, would actually sell to the public an AVC encoder (QT Pro), that runs on Windows, and is no longer even supported:

    https://support.apple.com/en-us/HT201175

    That is the same as that found on it's flagship, professional grade Final Cut Pro X, which costs $300 and only runs on Mac?
    Actually the general consensus was they "gave up" on video professionals a few years ago . Go look at pro video boards. The last few Mac pros were lemons, and FCPX was a big paradigm shift, cut down version that made things easy to use with big buttons, simple interface. It was geared towards casual users, not real pros. Go look at the reviews when it came out.

    FCPX , "their flagship" was priced accordingly $300 when it came out . FCP7, the previous flagship was $1000, even a month before FCPX release. FCP7 was a serious editing tool. It was used to cut some Hollywood productions, won Emmys. Premiere's GUI and design were modelled after FCP7. So there were petitions and revolts, many posts got censored/deleted on their own forums (of course it's Apple)

    Apple has worked very hard the last few years to gain back trust from video pros. So it's possible AVC has improved. Users certainly don't think so ; go look at user boards, professional sites - they seem to recommend handbrake, but you can't rely on "user" experience .

    Someone can add those encodes if they want to .
    Quote Quote  
  15. Originally Posted by KarMa View Post
    Decided to throw in my AMD RX460 card with its VCE 3.4, by downloading the 2.7GB source and encoding using FFMPEG with the h264_amf. The earlier cards supported B frames but this version and later does not due to the included HEVC encoder. So this card is just I frames and P frames.

    For the 6000kb version I CBR with the below plus setting, plus setting the GOP from 10-250 and 2-Pass. I would have done both with CQP but minor changes in the P quantizer causes unusual jumps in bitrate, so 6000kb was not possible with CQP.

    Code:
    -rc cbr -quality quality -profile high -coder cabac -me_half_pel true -me_quarter_pel true -preanalysis true -vbaq true
    For the 7500kb I did CQP with the below plus setting, plus setting the GOP from 10-250.

    Code:
    -rc cqp -qp_i 21 -qp_p 25.5 -quality quality -profile high -coder cabac -me_half_pel true -me_quarter_pel true -preanalysis true
    The AMD encodings seem to be the only one that doesn't really even attempt to encode the digital noise at these bitrates but yet will try to get all the detail on the car seats, which is interesting. There are different speed presets, with me using the Quality preset, but the speed hit is massive and the efficiency gain is barely noticeable. I mostly use the GPU for the HEVC encoding.
    Thanks, I'll run those through vmaf and update the results when I have time

    No b-frames ? Why would including a HEVC encoder as an option cause you to lose AVC b-frame option ?? How is that even related ?
    Quote Quote  
  16. Here are the MC + AQ options encodes, but only the 7.5Mbps versions. If someone really wants them, I can do the 6.1Mbps or other ranges or settings when I have time

    I'm surprised , there are some quite noticable changes . But this was a newer version of MC than those old tests, so maybe not entirely surprising.

    Which do you think is more similar to the original ? I have the VMAF results but let's do a blind test to see how well VMAF correlates to human perception in a limited sample. I'll give a hint at least one increased the score beyond the "default" . And my subjective opinion says one was definitely worse (in terms of similarity).




    Did anyone notice the big x264 problem ? I'll post some general observations about these tests later

    @Sharc, I think that NVEnc encode would benefit a bit from a longer keyframe interval . This is 59.94p, so a 1 sec would be 60 . 24 is not even 1/2 sec. The others were arbitrary set at x264's default setting 250, if possible - but that's necessarily not ideal either , just a starting point

    I've been using VMAF for about 6-8 months , and it's a mixed bag, but I'll post my comments on that later too



    Sorry some uploading issues; there should be 4
    Last edited by poisondeathray; 9th Oct 2019 at 09:53.
    Quote Quote  
  17. Where is the source that you used so that we may compare how which one is closest?
    Quote Quote  
  18. Originally Posted by sophisticles View Post
    Where is the source that you used so that we may compare how which one is closest?
    1st post, "source.mp4" in the mega.nz folder
    Quote Quote  
  19. Note that MC AQ have -100 also (range is -100 to +100)

    I honestly thought they wouldn't do much based on past experience. But this newer version seems to produce slightly different results, and the +AQ effects/differences are more pronounced.

    I uploaded the (-) AQ 7.5Mb/s versions for completeness, but I think these are clearly worse (in terms of similarity) with a quick glance.

    Some upload issues again... there should be 4 below
    Last edited by poisondeathray; 9th Oct 2019 at 14:37.
    Quote Quote  
  20. Originally Posted by KarMa View Post
    The AMD encodings seem to be the only one that doesn't really even attempt to encode the digital noise at these bitrates but yet will try to get all the detail on the car seats, which is interesting.

    I paused there for a second -

    It's an interesting choice of words - "digital noise."

    This test scene was a daylight shoot; It's not one of the dark shots in the other scenes. They used Red Weapon 6K, and Sony F65. If you look at native F65 or Weapon 6K daylight footage, it's exceptionally "clean" .

    This is not unwanted "digital noise". It's actually "wanted grain." or "wanted signal." It was added in post production on purpose. And this test version is oversampled - it's resized down to 1920x1080.

    I guess you could call it "digital noise" in some respects - but that has a negative connotation. "noise" implies "bad" or not part of the actual signal. (And whether or not someone "likes" it is another discussion)

    The job of an encoder is to reproduce the source as closely as possible, that's what these similarity metrics are supposedly showing. If the grain/noise "stuff" (whatever you want to call it) is in the source, but not in the encode, that's not very "similar"


    If you download some of the BM pocket cinema footage linked to in the other thread, the 1st one, that's characteristic sensor digital noise. It's lower light conditions, the sensor is relatively small compared to those other full cinema cameras. The look of the "noise" pattern characteristics are quite different, with color splotches. Nobody would argue that was "digital noise"





    Originally Posted by Sharc View Post

    B.t.w. I think this source compresses very well.


    In sense it is - it's low motion 59.94fps. But the grain makes it more difficult to compress. It's more difficult to retain grain, and keep the details underneath at the same time. Grain is "expensive" in terms of bitrate to encode

    If you take default x264 with --preset medium --crf 18 --tune film as a rough reference point for a "decent quality encode" scenario, you get ~10.9Mb/s; for --crf18 no tune ~8.8Mb/s . So we are still a bit under. And the CRF framerate awareness adjustment would have bumped quantizer mb values up. If it were a typical "23.976/24p" the non framerate adjusted quants would be lower and bitrates would actually be higher. 41.8Mb/s (!) for --preset medium --crf 18 --tune film using AssumeFPS(24) . That's not correct either, because of the aforementioned shutter angle. A properly shot 24fps film would have more motion blur, so it would be in between somewhere, but still signficantly higher than the ~7.5Mb/s we are using here

    For streaming, but "watchable" quality, lower bitrates - I would have degrained/denoised it to make it more compressible. A proper denoiser will typically produce better results than letting the encoder "denoise" for you
    Last edited by poisondeathray; 9th Oct 2019 at 16:13.
    Quote Quote  
  21. @poisondeathray
    Interesting thoughts about the x264 CRF framerate awareness and its impact on the quantizer mb values (bitrate) for this source.
    In the case of my NVEncC h264 encode the well known loss of details is obvious. On the other hand I was positive that the encoder's inherent "denoising" looked pretty clean, means little banding or posterization artefacts. Decent avisynth denoisers - although producing better results - will compromize the overall encoding speed. I can choose my poison.
    Quote Quote  
  22. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    Originally Posted by poisondeathray View Post
    It's an interesting choice of words - "digital noise."

    This test scene was a daylight shoot; It's not one of the dark shots in the other scenes. They used Red Weapon 6K, and Sony F65. If you look at native F65 or Weapon 6K daylight footage, it's exceptionally "clean" .

    This is not unwanted "digital noise". It's actually "wanted grain." or "wanted signal." It was added in post production on purpose. And this test version is oversampled - it's resized down to 1920x1080.

    I guess you could call it "digital noise" in some respects - but that has a negative connotation. "noise" implies "bad" or not part of the actual signal. (And whether or not someone "likes" it is another discussion)
    The provided sample is temporally noisy, this should be obvious to you. And apparently according to you this was added in post, which is fine but it's still noise, no matter what noun you use.

    Originally Posted by poisondeathray View Post
    The job of an encoder is to reproduce the source as closely as possible, that's what these similarity metrics are supposedly showing. If the grain/noise "stuff" (whatever you want to call it) is in the source, but not in the encode, that's not very "similar"
    The job of a lossy encoder is usually to retain whatever humans find most important first. In my provided samples, it seems like AMD doesn't save noise first. Good or bad. Denoising always comes with a certain level of risk of softening detail.

    Originally Posted by poisondeathray View Post
    If you download some of the BM pocket cinema footage linked to in the other thread, the 1st one, that's characteristic sensor digital noise. It's lower light conditions, the sensor is relatively small compared to those other full cinema cameras. The look of the "noise" pattern characteristics are quite different, with color splotches. Nobody would argue that was "digital noise"
    Color splotches aren't digital noise? Anyway as someone who regularly does hobby DSLR photography, you are still going to get both luma and chroma noise. Even with a low ISO, fast shutter, and capturing in RAW there will be noise. Noise that's even more obvious temporally when I create a timelapse with RAW images. Those color splotches are normally the easiest to get rid of in RAW or might be dealt with in camera before the camera saves it a H264 or Prores etc.

    Originally Posted by poisondeathray View Post
    No b-frames ? Why would including a HEVC encoder as an option cause you to lose AVC b-frame option ?? How is that even related ?
    B-frame support probably cost silicon space and or adds expense to the silicon wafer. Adding in HEVC support also adds costs. Removing B-frames was probably a way to cut costs while adding in HEVC. VCE 2.0 through VCE 3.1 have B-frame support but they don't have HEVC.
    Quote Quote  
  23. Originally Posted by Sharc View Post
    @poisondeathray
    Interesting thoughts about the x264 CRF framerate awareness and its impact on the quantizer mb values (bitrate) for this source.
    In the case of my NVEncC h264 encode the well known loss of details is obvious. On the other hand I was positive that the encoder's inherent "denoising" looked pretty clean, means little banding or posterization artefacts. Decent avisynth denoisers - although producing better results - will compromize the overall encoding speed. I can choose my poison.


    Yes, it's clean, pleasant to watch, but that signal loss is a direct result of less efficient compression.

    I'm suggesting a slightly longer GOP interval will give you slightly better compression, perhaps a bit more detail back. A 1 sec GOP is pretty standard , and usually longer for higher compression scenarios. I know it helped with earlier generations, I have an old Maxwell

    I'm concerned it's not showing NVEnc Pascal AVC in the proper context. Rumor has it that NVEnc was "better" than AMD VCE for AVC - it doesn't look like it here to me, but I don't have much experience with AMD VCE and haven't compared head to head directly. Now I can.

    I'm asking if you can upload a better version


    Of course you can do whatever you want ; The context of "similarity tests" is how well can encoder x,y,z achieve results that are similar to the source
    Quote Quote  
  24. Originally Posted by KarMa View Post
    The provided sample is temporally noisy, this should be obvious to you. And apparently according to you this was added in post, which is fine but it's still noise, no matter what noun you use.
    Bit of a tangent here , potato, "potahto" , but

    Yes, it's "noisy", but the distinction is wanted vs. unwanted .

    Are you aware of the term "signal to noise ratio" ? This "noise" is signal in this context



    Originally Posted by poisondeathray View Post
    The job of an encoder is to reproduce the source as closely as possible, that's what these similarity metrics are supposedly showing. If the grain/noise "stuff" (whatever you want to call it) is in the source, but not in the encode, that's not very "similar"
    The job of a lossy encoder is usually to retain whatever humans find most important first. In my provided samples, it seems like AMD doesn't save noise first. Good or bad. Denoising always comes with a certain level of risk of softening detail.
    A "perceptually tuned" encoder's job might be to retain whatever humans find most important first. But it's interesting this AMD sample, I haven't' seen too many - and this gives a chance for a direct comparison. Yes there are always tradeoffs



    Originally Posted by poisondeathray View Post
    If you download some of the BM pocket cinema footage linked to in the other thread, the 1st one, that's characteristic sensor digital noise. It's lower light conditions, the sensor is relatively small compared to those other full cinema cameras. The look of the "noise" pattern characteristics are quite different, with color splotches. Nobody would argue that was "digital noise"
    Color splotches aren't digital noise? Anyway as someone who regularly does hobby DSLR photography, you are still going to get both luma and chroma noise. Even with a low ISO, fast shutter, and capturing in RAW there will be noise. Noise that's even more obvious temporally when I create a timelapse with RAW images. Those color splotches are normally the easiest to get rid of in RAW or might be dealt with in camera before the camera saves it a H264 or Prores etc.
    I probably miscommunicated . That was a contrasting example - My point was color splotches are digital noise. That is unwanted signal . It should say "nobody would argue that that was "digital noise"" . Bad phrasing

    This sample has wanted grain. Added on purpose.

    But the exact same pattern on another video might be "noise"

    The difference is intent and wanted vs. unwanted (by the producer, not necessarily the viewers)
    Quote Quote  
  25. Originally Posted by poisondeathray View Post

    Yes, it's clean, pleasant to watch, but that signal loss is a direct result of less efficient compression.

    I'm suggesting a slightly longer GOP interval will give you slightly better compression, perhaps a bit more detail back. A 1 sec GOP is pretty standard , and usually longer for higher compression scenarios. I know it helped with earlier generations, I have an old Maxwell

    I'm concerned it's not showing NVEnc Pascal AVC in the proper context. Rumor has it that NVEnc was "better" than AMD VCE for AVC - it doesn't look like it here to me, but I don't have much experience with AMD VCE and haven't compared head to head directly. Now I can.

    I'm asking if you can upload a better version
    New version with 1sec GOP set to 60 frames. (The former 24 GOP was a leftover from earlier 24fps encodes).

    Commandline for 1-passVBR, constant quality:
    Code:
    NVEncC64.exe --avhw -i "meridien_.mp4" --fps 59.940 --codec h264 --profile high --level auto --sar 1:1 --lookahead 32 --vbrhq 0 --vbr-quality 29.85 --aq --aq-strength 8 --aq-temporal --gop-len 60 --ref 3 --nonrefp --bframes 3 --bref-mode middle --mv-precision Q-pel --cabac --deblock --preset quality --colormatrix bt709 --output-res 1920x1080 --max-bitrate 40000 --output "meridien_out.264"
    Image Attached Files
    Quote Quote  
  26. Here are my thoughts:

    Despite PDR's obvious attempts at cheating, by using old, outdated, discontinued, and crippled software, as is the case of MC and Apple's AVC encoder against the latest x264 builds, all encodes are fairly close to one another in quality, under normal viewing conditions. If one were to view each encode in isolation, without comparing it to either the source or the other encodes, I doubt anyone would know anything was amiss. This is especially significant because the test encodes were done at less than 1/3 the bit-rate used for commercial Blu-Rays. If a commercial BD were created using any of these encoders, I don't think anyone would be able to pick out any differences with the naked eye, With the latest full featured versions of each encoder, chances are the objective metrics may be too close to call as well at BD bit-rates.

    I really like the Meridian test source, NetFlix purposely created it as an encoder test, with features to highlight every encoder's weakness, but overall I would say they all did pretty well.

    X264 does win, as would x265, in 2 very important areas and that's cost and accessibility. While MC costs about $1500 and Apple's full featured encoder, despite PDR's claims, is only available on FCPX running on OSX, x264 (and x265) are cross platform, run on BSD, Linux, Windows and OSX, are legally free, and unlike hardware encoders, they do not require a specific brand of video card or cpu. The also do not have resolution and frame rate limitations, for instance AMD's VCE and Intel's QS are limited to 4096x2160p resolutions, and I have had trouble with both VCE and NVENC doing 4k DCI AVC encodes (on a 2200G and a GTX1050) but no trouble doing 4k DCI HEVC encodes.

    2 Things i would like to see added to this thread, QS test encodes from someone that has a Coffee Lake cpu, as well as hardware HEVC test encodes, and software hevc test encodes using Main Concept, Apple Compressor and x265.

    I would also like to see someone that maybe has access to the latest Magix Vegas, perhaps download and install the latest 30 day demo, download and ingest into the NLE to full 96GB Meridian source and simulate an actual production workflow, where they export from the timeline 1080p clip equivalent in length to our test version, using the built in MC and Sony encoders, as a point of reference of what someone working in post can expect to see without using a separate encoder for the deliverable.
    Quote Quote  
  27. Originally Posted by poisondeathray View Post
    Which do you think is more similar to the original ?
    I prefer the AQall100 (looking at some frames rather than watching the video)
    Quote Quote  
  28. Originally Posted by sophisticles View Post
    X264 does win

    I really like the Meridian test source, NetFlix purposely created it as an encoder test, with features to highlight every encoder's weakness, but overall I would say they all did pretty well.
    Hold on, it's just one test, 1 data point; don't read too much into it. You need to do at least dozens, hundreds of tests to get a "feel" for these things. This one doesn't have much motion. What about motion characteristics ? I already mentioned FPS and shutter speed - what about films with motion blur? What about "clean" films with no grain? Or animation ? Sports content with lots of motion? What about dark scenes, this was daylit (a common complaint is x264 prone to banding, blocking during those dark scenes - and it's true, but are other AVC encoders better or worse? I know the answer but if you want a demonstration... ). What about fades ? What about static content (real static, duplicate frames), etc....

    And those were basically "default" settings for high quality preset (if the encoder had a preset). GOP wasn't necessarily ideal, and you could tune some x264 settings better for this type of content and GOP makeup . And if there were "serious" problems, you could always use qpfile or zones


    Despite PDR's obvious attempts at cheating, by using old, outdated, discontinued, and crippled software, as is the case of MC and Apple's AVC encoder against the latest x264 builds
    Hahah nice one. I should have crippled MC, because that's what people commonly use. The one bundled with the NLE such as Adobe, Vegas (Magix , not Sony now, but they have a licensed low end version from MC too)

    I strong suspect Apple AVC is basically the same. There is no control in FCP7 or FCPX if you look at the manual. If anything it might even be worse considering the direction FCPX was headed. Someone can post an encode if they want to.

    In a sense, MC gives their lower featured encoder away for "free" or at low cost. Applications like video editors license a bunch of codecs, containers and formats, not just AVC. Such as MPEG2, MJPEG, XDCAM, DV, DVCHD , or MXF/MP4/TS/M2TS/MTS splitters and wrappers . An editor need to be able to import and export many types of formats, sometimes with specific specifications. Many of them are licensed for Mainconcept because of bundle pricing. If they bought "a la cart", or piecemeal from multiple vendors, it would be too expensive. And the one featured in NLE's is lacking many features

    all encodes are fairly close to one another in quality, under normal viewing conditions
    Yes, and that's very important point for the end user. That's what Netflix 's metric measures specifically. Not pixel peeping. Not pausing, zooming in. I will add comments on VMAF a bit later pros/cons, and my experiences with it. Also compare with conventional metrics like PSNR, SSIM

    But from a producer standpoint, you need to be more critical and have higher standards ; to be aware of pros/cons of certain workflows or encoders. The audience might not pixel peep, but the producer will . You don't want things like actor/actress's faces blurred away

    If a commercial BD were created using any of these encoders, I don't think anyone would be able to pick out any differences with the naked eye, With the latest full featured versions of each encoder, chances are the objective metrics may be too close to call as well at BD bit-rates.
    You can't say that based on this test. This test didn't test that scenario. Be careful on how you apply the observations/results of 1 test , 1 scenario to others.

    BD spec encoders have restrictions. For example 1080p59.94 is "illegal" . Typical is 1 sec GOP. You can't use 8 bframes etc... . There are VBV restrictions, buffer restrictions, the list goes on and on. You'd have to compare BD spec encodes to verify that assertion. And do you think that has been done before? You bet it has.

    And this is "artificial test" in many ways. Because you wouldn't use that many refs or b-frames for delivery . Higher requirements for decoding (L5.2), increased latency. Those setting would only be used in personal use scenario in real life. A more realistic test would be restricted to say L4.1 specs . 6-8 b-frames is still "legit" in a sense, some producers like BBC streams have than many


    Some other comments

    1) Detail preservation

    Take a look at frame comparisons especially faces and details compared to the source. Things like stubble, hair, skin pores and wrinkles are blurred away with some encoders. Look at the textures on the fabric of the hat and jacket. x264 does a better job of preserving those higher frequency details. It doesn't even look "HD" anymore for some of the encoders. OK those are important foreground elements, Actors faces etc...Arguably those are more important. But don't forget to look at the whole picture. What about background elements ? Look at the bushes. Notice they are blurred away for some encoders. The "D" in HD is supposed to be for "definition" in layman's terms , not some frame dimension concept. Where's the definition some of the encodes ? The original has details and grain - so the output should have details and grain.

    Those missing details are something you cannot easily recreate. That's why I would put higher weight on detail preservation. You can smooth over playback with playback filters, but you can't recreate details that were dropped by the encoder. (Ok maybe some of the newer AI research methods can synthesize some of it back, but we are discounting those right now).

    And can you even see "fine details" at normal viewing distance and conditions ? According to some research 96% of the general population cannot. That number would be higher here I'd imagine, because it's "59.94" . Frames are whipping by faster.


    2) Keyframe "popping"

    x264 has a problem with keyframe popping here. Look at the sky on frame 249-250 , or 499-500. That's the default IDR keyframe. Low grain / Big grain . Pop. If you blink you might miss it when watching it, so go frame by frame. There are some settings that can eliminate help, such as open-gop, adjusting the keyint (you can use infinite with x264, with scenecut still active. MC is capped at 300), adjusting IP, PB ratios over mbtree - but I left everything on default "veryslow" on purpose.

    Every encoder has "keyframe pop" here to some extent. Check between the key interval for each. eg. Sony has a slight "pop" in the sky pattern every 30, Apple every 120, NVenc pascal every 24, MC every 250 etc... But I would argue none are as bad as x264 on that first series of encodes. It MUCH worse in magnitude with x264 - because it does a better job of preserving grain and details, but at the end of the GOP, where the quality drops, this makes the transition is more abrupt. If frames are more blurry, less original grain and details to begin with, the transition is smoother. But it's also less frequent with x264 and MC, because the keyint is set to 250. And it's a bit more difficult to see under normal conditions because of "59.94p", frames whipping by faster
    Last edited by poisondeathray; 10th Oct 2019 at 09:34.
    Quote Quote  
  29. Responding from another thread, makes more sense to post here:

    Originally Posted by sophisticles View Post
    You conducted and posted a test, using a portion of the Meridian test source, specially prepared for another user. You purposely tried to fix the test so that x264 would win, by using old, outdated, limited versions of Apple's AVC encoder, and old, outdated, versions of MC's encoder, with many of the quality improving options disabled, while enabling x264's "mastering" setting. You still ripped into the x264 encodes and when finally pressed to change the MC settings, you produced encodes that most people agree that Mc beat out x264 visually.
    We're not done yet .

    I posted everything out in the open. There is no deception

    Apple QTPro is old, but the FCPX and compressor manual suggest it's not any different. Certainly there are no settings to make it remotely comparable to MC AVC Totalcode or x264 in this scenario, it's very limited.

    MC is isn't old, and it was set on the "highest" preset settings . I even adjusted them (default "best" ref was 5, I put it to 16. If I was being deceitful I should have left it at 5). Same with the other MC settings, I maxed out everything I could. I told you I left everything at default, even x264, on purpose. I didn't max out x264, nor did I adjust any other settings, just "veryslow" default. No placebo, no tuning or adjustments. I'd told you I'd post more encodes or anymore settings that you want when I had time. The reason is you need a starting place for the 1st run. If you wanted more encodes, I'll gladly add them when I had time. Please be a bit reasonable.




    Sharc thought AQall100 was most similar. I still think x264 is most similar overall, because of the grain and detail characteristics.

    => You never answered which video was the most similar, and why. Is it just a gut feeling? Describe why


    I need to know "why" people think this. This helps you learn and understand about perception.

    I already posted why I though x264 was more similar. It preserves details better, the grain better, and I put a higher weight on details contained in the source. Do you guys weigh that lower when you are considering "similarity"?


    The funniest, in a sad sense, part is that for years you, and people like you, have claimed that objective metrics can not be trusted to determine quality, that only your eyes can be trusted to make that determination. For years I have been saying on these boards that the job of an encoder is to reproduce the source as accurately as possible, not to make it look as good as possible and you and I, and a few other, have argued back and forth about this.

    When your own test results in an scenario where most agree that the MC encode looks better, you then adopt my stance nearly word for word, parroting my viewpoints (does {Polly want a cracker?) and standing on the results of an objective metric (VMAF) rather than what most people would agree is the nicer encode (MC).
    We agree on the job of the encoder. But we are having clear perceptual differences here. I want to understand why. I'm being serious here.

    Two other people replied . Is that "most people"? I guess that can be considered "most" . 2 vs. 1 . Do you think that's a good sample size ?

    Actually I made a mistake with VMAF; I'll update the post when I verify. But I doubled checked with the official VMAF tools and vmafossexec. VMAF thinks MC is on top, and one of the (-100) encodes is the top according to it. I'm going to purposely without it for a bit when we discuss perception . This can help validate VMAF, and improve it's predictive capability and results for the future


    This is especially dishonest of you when you consider that you actually admit the x264 encode has significant problems.

    You are the typical x264 zealot.

    How is it dishonest ? I'm being honest by telling you it has problems in case you missed them. (You probably missed them, I'm surprised you didn't scream it, which suggests how relevant the popping is. If you blink you'll miss it at this framerate)

    I'm telling you , you can fix the keyframe popping issue this with a proper encode , not using the default settings (which I did on purpose) . If you're allowed adjust MC settings from the default, are you not allowed to adjust other encoders ? MC maxes out at 300, you will still get keyframe popping there.

    Did you notice as you adjust MC AQ modes where, it becomes more "x264 like" in terms of retaining detail ? That's why I was a bit surprised earlier. Also , the keyframe popping gets worse when the detail and grain retention increases, just like x264 .

    I see the MC problems as worse overall, because it's missing too much detail . The keyframe pumping is in the grand scheme is minor - all of them have it to an extent - and occurs less frequently with MC and x264. And you can eliminate it completely with x264 settings in this scenario.



    I'm more interested in the perception aspect. Why does someone see "a" as being more similar to "b" ? and so forth. I will post later about this perception difference, and VMAF results with VMAF overall discussion pros/cons.
    Quote Quote  
  30. Originally Posted by Sharc View Post
    Originally Posted by poisondeathray View Post
    Which do you think is more similar to the original ?
    I prefer the AQall100 (looking at some frames rather than watching the video)
    When you say "prefer", to clarify you mean that looks most similar to the original in your eyes ?

    Can you describe that a bit more ? Or is it just a general "feeling" ?

    In what ways is it more similar ? How did you come to that decision ?



    Thanks
    Quote Quote  



Similar Threads