VideoHelp Forum




+ Reply to Thread
Page 6 of 7
FirstFirst ... 4 5 6 7 LastLast
Results 151 to 180 of 203
  1. Originally Posted by poisondeathray
    Original


    Adobe Media Encoder CS4 (based on MC)


    x264 AQ=1.5
    Wow, those are some crazy differences. What is x264 trading off at AQ 1.5?

    aedipuss:

    (caveats: aedipuss's frame isn't the same as the one PDR used, the preprocessing is different, the snapshot is a JPG, and the bitrate is much higher.)

    I lanczos-resized in Irfanview to compare your snapshot with PDR's. The MPEG2 CCE snapshot is a lot more blurry than x264, but it doesn't smear out shadow detail like Adobe Media Encoder does. Still, it's at a whole 6Mbps while the H.264 decoders are at 1Mbps.

    aedipuss's CCE MPEG2 screenshot, cropped and resized to be more comparable, PNG


    I really doubt CCE can turn out anything close to H.264 at low and medium bitrates.
    Quote Quote  
  2. aBigMeanie aedipuss's Avatar
    Join Date
    Oct 2005
    Location
    666th portal
    Search Comp PM
    sorry here's a png but i still don't know what frame to use. but,you do realise mpeg-2 wasn't meant for anything under 3mbps, right?



    oops.png
    --
    "a lot of people are better dead" - prisoner KSC2-303
    Quote Quote  
  3. Originally Posted by aedipuss
    sorry here's a png but i still don't know what frame to use. but,you do realise mpeg-2 wasn't meant for anything under 3mbps, right?
    True. We should have been comparing at high-bitrate.

    I compared using your new screenshot, and x264@1Mbps is still a bit better. I'm willing to attribute part of the difference to better preprocessing (deinterlacing, resizing) for the x264 shot.
    Quote Quote  
  4. aBigMeanie aedipuss's Avatar
    Join Date
    Oct 2005
    Location
    666th portal
    Search Comp PM
    i let cce sp2 resize it and left it interlaced for mpeg-2.

    ps - i also used avidemux to convert it to huffyuv avi first as cce won't accept anything but avi.
    --
    "a lot of people are better dead" - prisoner KSC2-303
    Quote Quote  
  5. Originally Posted by aedipuss
    ps - i also used avidemux to convert it to huffyuv avi first as cce won't accept anything but avi.
    I guess you haven't heard of AviSynth? I usually feed M2Vs (MPEG-2 video) into CCE via an AviSynth script file.
    Quote Quote  
  6. Originally Posted by aedipuss
    i let cce sp2 resize it and left it interlaced for mpeg-2.
    I was just saying that it wasn't a fair comparison since the preprocessing was different. Ideally everyone should work from the same preprocessed source.

    Originally Posted by manono
    I guess you haven't heard of AviSynth?
    One day Avisynth will cure cancer. I'm sure of it. It's just that awesome.
    Quote Quote  
  7. Member
    Join Date
    Aug 2002
    Location
    Sweden
    Search PM
    I don't think CCE accept any higher resolution than 720x576 maximum but I might be wrong here since I have not used CCE in many years. HCenc can do higher resolutions.

    I must say this is a very interesting thread. I have just started to use x264 with MeGUI and I use the presets. But all those command line options would be nice to learn what they really do. As always the people that know how to set everything up do get nice looking encodings...

    How about interlaced h.264? I have heard that x264 is not yet fully optimized for interlaced content. Is DivX better for interlaced h.264? Any ideas? My solution is to bob deinterlace with something like MCTemporalGauss from 1080 25i and downsize to 1280x720 50P and encode with x264, but I wonder if this is really the best approach for converting HDV to bluray compatible h.264? In theory I could make 1440x1080 interlaced h.264 as an alternative.
    Quote Quote  
  8. Guys, the park/pond clip was only meant to illustrate the effects of AQ. MPEG2 was never meant for low bitrate encodes. But HCenc has AQ ported from x264, it's just not as effective. Here you can see the effects of AQ using HCEnc. The key areas are to look at the shadow detail, and pond/underwater detail.

    HCEnc 2Mbps AQ=0


    HCEnc 2Mbps AQ=4



    Wow only 2Mbps and it looks "passable right?" Wrong. Broken record time: You have to look at the entire clip. The beginning sequence where there is tree/leaf movement is a mess.


    HCEnc 2Mbps AQ=0


    HCEnc 2Mbps AQ=4


    x264 1Mbps AQ=1.5



    CCE is much worse at low bitrate (but arguably better than HCenc for high bitrate encodes)

    Wow, those are some crazy differences. What is x264 trading off at AQ 1.5?
    You also have to examine the other frames in the clip, because AQ redistributes bits inter-frame as well. There is not much at AQ=1.5 being traded off in this scenario, but if you look at AQ=2.0 (I didn't post this but you can test it yourself), there is even more improvement over AQ=1.5 on that sequence, at the expense of the beginning scene, before the pan down (the tree leaves are slightly less detailed). So again , everything exists in a balanced range and it's usually up to you to find the "optimal" setting.
    Quote Quote  
  9. Originally Posted by ronnylov
    I don't think CCE accept any higher resolution than 720x576 maximum but I might be wrong here since I have not used CCE in many years. HCenc can do higher resolutions.
    Correct. The regular version only outputs SD resolutions


    How about interlaced h.264? I have heard that x264 is not yet fully optimized for interlaced content. Is DivX better for interlaced h.264? Any ideas? My solution is to bob deinterlace with something like MCTemporalGauss from 1080 25i and downsize to 1280x720 50P and encode with x264, but I wonder if this is really the best approach for converting HDV to bluray compatible h.264? In theory I could make 1440x1080 interlaced h.264 as an alternative.
    This is the issue I'm having with blu-ray authoring. It's the fault of the blu-ray standard. 1080p60 (1080p50 for PAL folk) would have been nice.

    yes, x264 is less efficient at interlaced encoding than progressive. In my tests, Mainconcept does a slightly better job. Having said that, even with the poor efficiency, it's still more efficient than MPEG2 for interlaced HD material at blu-ray bitrates in my testing. If you are willing to use BD50 instead of BD25, I suspect you can get away with using MPEG2 (of course varies depending on your content complexity and compliation length)
    Quote Quote  
  10. aBigMeanie aedipuss's Avatar
    Join Date
    Oct 2005
    Location
    666th portal
    Search Comp PM
    Originally Posted by manono
    Originally Posted by aedipuss
    ps - i also used avidemux to convert it to huffyuv avi first as cce won't accept anything but avi.
    I guess you haven't heard of AviSynth? I usually feed M2Vs (MPEG-2 video) into CCE via an AviSynth script file.
    tried it first but it wouldn't accept the demo file as input.

    as for video size cce sp2 will accept 1920x1080 as input.
    --
    "a lot of people are better dead" - prisoner KSC2-303
    Quote Quote  
  11. Sorry, I mentioned yadif, lanczos, but forgot to mention AVCSource (Index using DGAVCIndex)

    Code:
    AVCSource("ezsm021.dga")
    Yadif(order=1) #TFF
    LanczosResize(720,400)
    Quote Quote  
  12. aBigMeanie aedipuss's Avatar
    Join Date
    Oct 2005
    Location
    666th portal
    Search Comp PM
    Originally Posted by poisondeathray
    Sorry, I mentioned yadif, lanczos, but forgot to mention AVCSource (Index using DGAVCIndex)

    Code:
    AVCSource("ezsm021.dga")
    Yadif(order=1) #TFF
    LanczosResize(720,400)

    thanks - i didn't have dgavcindex, couldn't index it to frameserve to cce sp2 before.
    --
    "a lot of people are better dead" - prisoner KSC2-303
    Quote Quote  
  13. Originally Posted by poisondeathray
    You also have to examine the other frames in the clip, because AQ redistributes bits inter-frame as well. There is not much at AQ=1.5 being traded off in this scenario, but if you look at AQ=2.0 (I didn't post this but you can test it yourself), there is even more improvement over AQ=1.5 on that sequence, at the expense of the beginning scene, before the pan down (the tree leaves are slightly less detailed). So again , everything exists in a balanced range and it's usually up to you to find the "optimal" setting.
    Good stuff. I did some reading up on Variance AQ and found out that it's essentially "free bitrate" because not much is being traded off. Knowing this and hearing what you said, I'll experiment with higher AQ strengths in future.

    Psy-RDO is a bit more controversial, essentially allowing better grain retention at the cost of more artifacting. I guess it really is responsible for the microshifting I mentioned. Honestly speaking, it seems like Psy-RDO might not be such a good thing if you aren't looking for particularly good grain. I'm currently reading up more about it.
    Quote Quote  
  14. Originally Posted by creamyhorror

    Psy-RDO is a bit more controversial, essentially allowing better grain retention at the cost of more artifacting. I guess it really is responsible for the microshifting I mentioned. Honestly speaking, it seems like Psy-RDO might not be such a good thing if you aren't looking for particularly good grain. I'm currently reading up more about it.
    It is controversial, using it causes deviation from SSIM/PSNR values, for more "subjective" or percieved quality. It can definitely help in some scenarios, definitely hurt in others. The default strengths used to be way way way too high --psy-rd 1:1 , artifacting everywhere. I usually turn it off for low bitrate or anime type sources. YMMV
    Quote Quote  
  15. Do you (or anyone) have a link to a good comparison? Doom9 isn't working well for me (overloading) and the comparison on DS's blog isn't available because of bandwidth limit exhaustion.
    Quote Quote  
  16. Originally Posted by creamyhorror
    Do you (or anyone) have a link to a good comparison? Doom9 isn't working well for me (overloading) and the comparison on DS's blog isn't available because of bandwidth limit exhaustion.
    Do you mean in regards to psy-rdo / psy-trellis?

    There aren't very many good ones that illustrate exactly what is happening that I've seen (not as clear as the AQ example above). This one is tough to make generalizations with, except the picture gets more noisy as you increase strengths. It's essentially adding noise, mainly around lines. You will notice your crf encoded size will increase with strengths (just like if you added grain or noise). "sagekilla" did a whole bunch in one thread on Doom9, search for that one. You will learn more just by testing it out yourself, and varying the settings. The effects vary within bitrate ranges (ie. "high" is relative and applicable only for a certain bitrate range, on a certain source and complexity type). It can be very dangerous if you're not careful
    Quote Quote  
  17. Indeed, after reading up on it I'm not sure if I want to use it on most sources. Apparently it retains detail while causing ringing artifacts. I'm going to do a comparison encode.
    Quote Quote  
  18. Read up, did comparisons, came to the conclusion that it's good at preserving grain after all despite resulting in small artifacting. Without psy-RDO, video looks smoothed.

    I wouldn't use it for Youtube uploads and other intermediate formats, but it's certainly good for grainy, detailed sources.
    Quote Quote  
  19. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    I use MainConcept Reference for professional projects, and the output is nowhere near as bad as the Adobe export samples shown above. I will say that the Adobe MainConcept version does not appear to be as good as the standalone MC encoder app, however. I've seen x264 look the same, and worse, than MC Reference -- rarely have I see it better. And that's just "samples", with next to nothing known about the workflows used to get it there.

    Seriously, I can't spend my day toying with command-line apps. Make a GUI or understand that nobody (willing to spend $$$$ on it) actually cares if it looks 10% better. Not worth the effort, poor ROI on time.

    This rallymax person has the right idea: https://forum.videohelp.com/topic372349.html
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  20. Originally Posted by lordsmurf
    I use MainConcept Reference for professional projects, and the output is nowhere near as bad as the Adobe export samples shown above. I will say that the Adobe MainConcept version does not appear to be as good as the standalone MC encoder app, however. I've seen x264 look the same, and worse, than MC Reference -- rarely have I see it better. And that's just "samples", with next to nothing known about the workflows used to get it there.
    In my experience, I have to say the opposite. If an x264 encode looks worse, it's usually user error, as abundantly demonstrated in this thread.

    I've NEVER seen MCR encodes look at good as x264 overall (assuming decent settings). Never is a fricken strong word, but I stand by it 100%. It maybe "better" on the odd frame, but the usual distribution is ~80% of the frames where x264 is clearly better , ~10% where they are similar, and ~10% where MCR is better. This varies, but is pretty consistent on all types of scenarios and content

    If you have time, go read over this whole thread, do some tests and come back see if you've changed your mind. Everything is transparent, from the settings, sources used, workflow, testing methology. If you want anything repeated feel free to discuss. I have 100's of tests that show the exact same thing.

    I agree MCR is better than the AME, simply because it has more functional settings and control. On the park/pond example MCR does about the same as the AME example because of the lack of AQ or lumimasking. If you go back a page, you will see x264 with AQ=0 looks just as bad too! I only posted that specific example to illustrate the effects of AQ - this is an extreme example. On "normal" sources (without shadow details), the differences aren't as huge. Only the very high end Mainconcept encoders (like Cinevision) , and the SDK have AQ like functionality. But overall the same trends remain when using consumer level Mainconcept based encoders: they provide less detailed encodes (things like grain and fine details are smoothed away), poor quality in background and shadow areas when compared to x264 encodes. I dare anyone to prove otherwise

    10% better? Perhaps only on low quality sources. Try the DPX sourced lagarith Dreamworks trailer posted. I'm seeing 40-50% higher bitrates required from MCR to equal x264. I'm seeing similar trends at for my blu-ray authoring on high quality sources, as have many others. Often chosing x264 vs. another encoder is the difference between stuck using an "expensive" BD-R 50 vs. "cheap" BD-R 25.
    Quote Quote  
  21. Originally Posted by lordsmurf
    I've seen x264 look the same, and worse, than MC Reference -- rarely have I see it better. And that's just "samples", with next to nothing known about the workflows used to get it there.
    All well and good, but we can't just take your word for it unless we can do some sort of testing on standalone MCR. MCR is certainly not bad by any means, if that's what you were arguing against.

    Seriously, I can't spend my day toying with command-line apps. Make a GUI or understand that nobody (willing to spend $$$$ on it) actually cares if it looks 10% better. Not worth the effort, poor ROI on time.
    You make it sound like we're trying to convince you in particular to use x264. We aren't, we're just demonstrating that x264 has significant quality/bitrate advantages, and people can choose to invest the time to try it out if they want. And there are a whole bunch of GUIs for x264 of varying levels of complexity (MeGUI, Handbrake, StaxRip, Ripbot264, Xvid4PSP, AutoGK...). You've almost certainly encountered them here.

    There's no need to be dismissive of something just because it doesn't seem to fit your needs as a video professional. Lots of people are dealing with amateur footage and DVDs and BDs as a hobby, and want as good quality as they can get.
    Quote Quote  
  22. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    Originally Posted by poisondeathray
    10% better? Perhaps only on low quality sources. Try the DPX sourced lagarith Dreamworks trailer posted. I'm seeing 40-50% higher bitrates required from MCR to equal x264. I'm seeing similar trends at for my blu-ray authoring on high quality sources, as have many others. Often chosing x264 vs. another encoder is the difference between stuck using an "expensive" BD-R 50 vs. "cheap" BD-R 25.
    as much as i hate to admit it, i would have to say that you have convinced me that main concept based h264 encoders do seem to smooth things out a bit much, something i hadn't noticed before but thanks to this thread i did a bunch of test encodes and sure enough excessive smoothing. but this also leads me to this question:

    perhaps there is a setting somewhere within the encoder to turn smoothing off? i find it very hard to believe that an app that costs $2000+ and has such a pro following doesn't have the ability to a) turn off smoothing and b) improve the encoding quality. just as you say that the weaknesses people usually find in x264 is because they misconfigured the encoder, maybe the same holds true for main concept based encoders?

    also i'm wondering how sony's avc compares, perhaps someone with vegas could run some of these test encodes for comparison?
    Quote Quote  
  23. Originally Posted by deadrats
    as much as i hate to admit it, i would have to say that you have convinced me that main concept based h264 encoders do seem to smooth things out a bit much, something i hadn't noticed before but thanks to this thread i did a bunch of test encodes and sure enough excessive smoothing. but this also leads me to this question:

    perhaps there is a setting somewhere within the encoder to turn smoothing off? i find it very hard to believe that an app that costs $2000+ and has such a pro following doesn't have the ability to a) turn off smoothing and b) improve the encoding quality. just as you say that the weaknesses people usually find in x264 is because they misconfigured the encoder, maybe the same holds true for main concept based encoders?

    also i'm wondering how sony's avc compares, perhaps someone with vegas could run some of these test encodes for comparison?
    I'm glad we are sharing our observations & experiences. I honestly want to learn here and if people have something completely different from what I'm (and most others) seeing, I would just like to investigate. It's not as if I'm trying to sell you the freeware x264 encoder...

    But seriously, there is no special setting - even maxed out - all consumer/prosumer level Mainconcept based encoders tend to 1) oversmooth, and 2) underallocate to dark areas. (believe me, I've tried every setting thoroughly). My friend has a studio , and I tested cinevision, and even the studio level version $50K does a lot worse in terms of efficiency than x264! For real. The only switch that has any real bearing for Mainconcept based encoders in most situations will be lowering the alpha / beta deblock values (the defaults are -1/-1, but you can try -2/-2 for example). Higher end versions do have lumimasking and psy settings similar to x264, but they usually are not accessible in the consumer versions.

    Yep, I've tested Sony AVC from Vegas 8 and 9; significantly worse than Mainconcept (even worse than the gimped Mainconcept version that comes bundled, it's that bad).
    Quote Quote  
  24. Originally Posted by deadrats
    perhaps there is a setting somewhere within the encoder to turn smoothing off? i find it very hard to believe that an app that costs $2000+ and has such a pro following doesn't have the ability to a) turn off smoothing and b) improve the encoding quality.
    It's not a matter of turning smoothing off, it's simply that x264 has technologies (adaptive quantization and psy-RDO, and now mbtree) that are currently only the province of studio-level apps. (In the case of mbtree I'm not even sure if any other encoder at all has anything like it.) These were all rapidly developed and improved over the past two years. Consumer-level encoders can't compete without implementing similar technologies, and they have a lot catching up to do in this respect.

    People will keep paying $2000 because of brand recognition and marketing. Freeware is looked down upon to some extent

    just as you say that the weaknesses people usually find in x264 is because they misconfigured the encoder, maybe the same holds true for main concept based encoders?
    If the correct options were available, I suspect PDR would already have found them...
    Quote Quote  
  25. Originally Posted by poisondeathray
    My friend has a studio , and I tested cinevision, and even the studio level version $50K does a lot worse in terms of efficiency than x264! For real.
    If it has lumimasking and psychovisual enhancements, surely it can't be that far behind? (Actually, I thought H.264 didn't need lumimasking? XviD has lumimasking and certainly needs it, from what I've read...)

    edit: seems like Cinevision has multiple AQ modes, including the lumimasking one, so yeah.
    Quote Quote  
  26. Originally Posted by creamyhorror
    If it has lumimasking and psychovisual enhancements, surely it can't be that far behind? (Actually, I thought H.264 didn't need lumimasking? XviD has lumimasking and certainly needs it, from what I've read...)
    The implementation is not as effective. For example, HCEnc port of VAQ isn't as effective (as seen above), or xvid's VAQ isn't as effective either...

    The higher end MC encoders have AQ in luminance, contrast and complexity. You can use them all in varying ranges, together or separately, but still not as effective as x264's (in any combination)
    Quote Quote  
  27. One guy on Doom9 claims:
    Originally Posted by kolak
    Cinevision can at least match x264 or even produce better results for grainy sources, but I like quality from the latest version of x264.
    Some features of Mainconcept's SDK can be found only in Cinevision and they work quite well.
    Originally Posted by kolak
    Originally Posted by shon3i
    Agree, but only with nominal blu-ray bitrates, with lover bitrates x264 still produce better looking video.
    Yes- I've forgotten to add this.
    I'm more BD bitrates guy, so I'm not realy interested in 5Mbit HD encodes (some time ago I was).

    I've done some test recently and Cinevision was slightly better, but I know it quite well, so I can tweak it. x264 has more settings and I don't have experence with it. Difference was very small- but on 2x zoom Cinevision looked more clean. This was fairly noisy 30p source, so Cinevision shined with its grain optimization.

    AQ stuff in Cinevison is very powerful, but also makes problems with some sources.
    With such encoders, at bitrates above 20Mbps, I'm finding it hard to imagine anyone can definitively rank the results, really. Any difference is more likely due to the psychovisual tuning of the encoder, which seems to be very much a personal preference thing (some like certain effects over others).

    I'd be interested to find out if I could see a difference at such high bitrates. I've never tried it, but I doubt I'd see much of a difference.
    Quote Quote  
  28. Originally Posted by creamyhorror

    With such encoders, at bitrates above 20Mbps, I'm finding it hard to imagine anyone can really rank the results, really. Any difference is more likely due to the psychovisual tuning of the encoder, which seems to be very much a personal preference thing (some like certain effects over others).

    I'd be interested to find out if I could see a difference at such high bitrates. I've never tried it, but I doubt I'd see much of a difference.
    Have a look at that Island trailer, you need much more than 20Mbps for transparency...It has heavy grain and lots of action/scene changes

    Kolak and shon3i both seem familiar with cinevision, but I only had a few days to test it so it might be I didn't get optimal encodes. But x264 was clearly more efficient in my testing, and shon3i's comments seem to suggest that as well. But how many people here are willing to pay $50K for an encoder...I would love to see more complete head to head testing as well
    Quote Quote  
  29. Originally Posted by poisondeathray
    Have a look at that Island trailer, you need much more than 20Mbps for transparency...It has heavy grain and lots of action/scene changes
    Will do, tomorrow.

    Kolak and shon3i both seem familiar with cinevision, but I only had a few days to test it so it might be I didn't get optimal encodes. But x264 was clearly more efficient in my testing, and shon3i's comments seem to suggest that as well. But how many people here are willing to pay $50K for an encoder...
    There was also that interesting quote:
    Originally Posted by Lyris
    Regarding how a $3000 encoder is going to compare to x264: one of the most respected names in the video world said that none of the main studio's encoders matched the quality of x264. Certainly, on most BD titles, I can see small compression artefacts that I don't see on (quite grainy) test encodes I've done. I imagine this is the "speed over quality" argument again.
    I don't know if "main studio's encoders" includes cinevision, though. Or whether it was just hyperbole.
    Quote Quote  
  30. Yes I remember reading that...too bad he never expanded on who it was....

    Well cinevision is a $50K encoder....Some other studios use blu-code. I'm not aware of any other

    I prefer to see with my own eyes to believe it. I was skeptical x264 was better than a $50K encoder, but my tests showed that trend to me. I would have liked to spend more time with it to test it more thoroughly ...but I'm still pretty convinced.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!