Much like Tmpgenc's motion search precision, I would believe.
Is that right? BTW, I'm running a set of encoding tests between HC, NuEnc and Tmpgenc. I'm concentrating mostly on quality as I know HC and NuEnc can't beat Tmpgenc that can do a 1-pass CQ based encoding really fast. Peter Cheat tried to replicate that in NuEnc. I wonder if you could try the same in HC, Hank. I mean in the near future. You don't need to do it right away ;-) My battery test will consist of 3 samples from each encoder using different avisynth scripts for DVD or, as we call it here, KDVD. My source will be PAL DVD 'Harry Potter 3'. I'll be using Incredible's Slicer function that will capture 2% of the movie. One of the scripts will be very basic: Code:
Mpeg2Source("D:\POAZKABAN\D2V\POAZKABAN.d2v") The second script will also be very simple: Code:
Mpeg2Source("D:\POAZKABAN\D2V\POAZKABAN.d2v") The third one will be also very simple and will use another Incredible's funtion named ADS that I am using on most of my encodes: Code:
Mpeg2Source("D:\POAZKABAN\D2V\POAZKABAN.d2v") This way I'll test the 3 encoders in raw conditions, in light filtering conditions and last but not least with adaptive filtering. I'll post results tomorrow. Cheers |
@Hank,
Well, this is my first test, and what can I say :!: Your motion estimation is as good or better than TMPEG's :D I just encoded two samples directly from a .d2v to eliminate any filtering effect artifacts, and here are the results: TMPGEnc (2-pass test for file size accuracy) Average bitrate 1,500Kbps (300Kbps Min, 5,000Kbps Max, Notch matrix) http://www.kvcd.net/downloads/rambo.m2v HC Encoder parameters and sample: Code:
*PROFILE BEST @All, I originally encoded about 2 minutes with each encoder, and the results were the same as these samples, so I just encoded 240 frames to make the samples small in size. You can analyze the results in Vdub by loading the samples and zooming in, and you'll see how HC does a great job around edges, specially around the titles and far away objects. -kwag |
Hey guys.
I've also tested HCE and have to say that I'm surprised positively. The quality of the 2-pass encoding compared with CQ of TMPGEnc is very good. In some scenes the qualiy is a little bit better but there are also some bugs. HC alwas set the max bitrate header to 9800kbps if I load the m2v file into BitrateViewer. I use HC on a P4 HT 3,2 GHZ and the speed is very good. But I hope hank optimized the Encoder always for HT so I can use 2 prozessors and it's faster. :lol: Hope the next release comming soon. :D @Hank I see in your GUI that we can in the future look at the source movie and the encoded file. But it would be nice if we can see a splitted movie. On the left side perhaps the source and the right the encoded and we have a direct comparison. This you can see in the WME, too. :D |
Nice to see some examples kwag!
One thing I noticed is that the clip encoded with EC is darker than the TMPEG clip. The other thing is that the EC clip was a bit blocky in some places. "Very" noticable in the scene change. But as this is an early version of the encoder I must say it looks amazing, not to mention it's free! I'm grateful. Very impressive work Hank! :D |
Quote:
I just finished my tests and if there's any difference between the source and the encoded clips, I would say that Tmpg's colors are slightly darker than source and HC's clip :? Quote:
But I think HC has got worser B frames than Tmpg. They look similar to NuEnc's, though... On the P frames side I think Tmpg still has the lead but HC is also looking very good and so is NuEnc. So the big difference is in the B frames compression. In difficult sources you can see some very blocky B frames where Tmpg can really provide a very smooth frame. I'll post the picts as soon as I can upload them. Nevertheless very good job from HC and NuEnc. Cheers |
Quote:
|
:oops: Never mind. It was I who had mixed up the clips! :roll:
Sorry for the screw up guys! EDIT Before you start laughing at me :lol: I must admit that I'm really confused at the moment. When looking at the clips in VLC the TMPEG clip is darker, but when I load them into VDub the HC clip is the darker one?! Codec problem perhaps? I'll be right back after I've rebooted my PC... |
Here are some images of what I'm talking about:
TMPEGEnc http://www.digitalfaq.com/archives/i.../2005/02/1.png HC Encoder http://www.digitalfaq.com/archives/error.gif |
You're right audioslave.
Tmpg's pic is darker than HC's one. So, you said you opened both clips using VDub? I use to do the same with VDubMod when I'm on doing comparisons. And I've come up to the same conclusion some time ago. I just didn't make much noise about it... And I didn't make sure I proove it :( Anyway, we need to see a pic from the source to make sure if it's tmpg that is darker or if it is HC that is lighter ;-) Karl, can you provide us with a pic from the source please? Cheers |
#1 - in the samples above, the picture of tmpgenc is not darker, it is lighter !
#2 - it can (again) be due to luma range scale (PC vs TV). #3 - else let see if you don"t have any directshow filter (ffdshow) that interfer in the rendering with HC (I don't know if it opens the D2V directly or throught DirectShow). |
Quote:
Quote:
They both worked under the same circumstances, I believe... Quote:
But in my case I already made sure I have no ffdshow installed. And I can replicate what Karl has shown us with his clips :? |
Hya Hank :)
Man, I really don't know any way else to put this. Otherwise I would. I'll explain myself. I was at HCEnc's D9 thread a few minutes ago and I couldn't help to see that Amnon82 is doing his best to get closer to you Hank. Now, I know that sometimes people can do some mistakes and they can learn from them, but Amnon (or Avalon) has prooved to be a hell of a leecher stealing many guys work. He has said many times that those were simple misunderstandings but he did take other people's work and put his name on it. If you care to press the search button in this forum and search for Avalon, you will understand what I mean. You're obviously a "big boy" and you're obviously entitled to choose those that you want near you. But it may well be that you still don't know Avalon as we do... Don't take it hard on me, please :oops: Even because if it was any other guy instead of Avalon, I wouldn't be here writing this post. Just thought that I should let you know ;-) Cheers PS-My own comparison is coming up next. |
Quote:
Quote:
|
Quote:
I'm using Firefox for what it's worth. Quote:
And I was under the impression that Limiter() would cut the ranges to TV scale, isn't that so? Then why can I replicate it here too? I'll tell you what: since I'm all dazed and confused (great Led Zep song :)) would you tell me what are the best settings for DVD2AVI and for the avisynth script? I mean, should I do PC -> TV when I'm creating the D2V project and should I use Limiter() before/after/at all in my script and should I tick any CCIR601 flag in the encoder (if it has some)? I'm really getting lost here and I see that tmpg's output is different than the source, know what I mean? :roll: TIA Phil Cheers |
@Hank315
Following my dialogue with Phil, is there an option in HC that will work as Tmpg's "Output YUV data as basic YCbCr not CCIR601" that clamps the output for TV range? I don't think so, right? Would it be hard to implement in the long future? Cheers |
Quote:
It is not because you limit the input (with limiter) to 16-235 than the *output* (what is produced by the encoders) is also limited ! The encoder do not care about the range of the input. It takes the data in entry, it applies it's algorythm and it produces values on output that are not necessary in the same range. But, by defautl, tmpgenc cuts its ouput to TV scale. So gain, if HC does not do the same, then you can't compare the output. Quote:
Then on the tv :!: :!: the result will be the same than the source. Note: there is also a problem with tmpgenc to know if it cuts (the correct behaviour) or rescale (not correct) the range. |
Hi guys.
What I wanted to prove with the screenshots is exactly what Dialhot said: The HC clip is darker. @Dialhot In DVD2AVI you suggest that I use PC scale?! I must have missed that. What then do I use in my script to make the output look the same as the original source (DVD)? In HC Encoder I can't choose if the output is to be used on PC or TV... I think? |
For DVD2AVI, the important to compare the two encoders is to use the same settings for both. Whatever is this setting is correct or not !
For HC? no I don't think you can, but it's not a problem : you can choose that with tmpgenc so encode the same sample with the two settings and see if one of them has the same light than the one from HC. Again, what is important for the moment is not to know what is the correct setting, but to see if it's possible to compare the 2 programms. |
For sure! :wink:
|
Hi all,
At first thanks for all the feedback and tests. Will try to answer some questions. HC opens the d2v directly, just takes the YUV planes and encodes them, it follows the rules from the ISO-MPEG document very strict and does no special scaling or whatever. Kwag, thanks for the test just downloaded the movies and had a quick look at them. In my eyes the luma scale is different, the TMPGenc movie looks lighter but there are more differences, will come back on that later. About the lower Quality B-frames, this might be true. There are some (internal) flags which tell the encoder to raise the Q for P and B frames. ATM they are set to 0 for P-frames and 2 for B-frames. For low bitrate encodings other settings would be better, maybe in next versions this can be set by the user. About CQ, (Constant Quality), HC doesn't support it ATM. But it could be implemented and it could work pretty fast also. Example: take 10% and encode it with Q=x1, all other test-encodes (Q=x2, Q=x3 etc) can be done fast because it can use info from the first encode, it just has to quantise it. This in combination with a smart search algorithm, Newton Raphson or something like that, can converge very fast but it is not one of the first priorities And yes it will run fast on a P4 3.2 (Prescott core) which uses SSE3, it can use the LDDQU instruction to load unaligned data fast; using a P4 3.2 myself, that's why I implemented it :) About the preview option, it will be in the next version but for now it's just a gadget, but maybe in future versions it can be done to do real frame-frame comparisons. But it will slow down the encoding... That's it for now, will be back tonight. grtx. hank |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.