A new promising freeware MPEG-2 encoder
 

Hi guys!

Just wanted to inform you about this new encoder; HC.

Read more:
http://forum.doom9.org/showthread.ph...0&pagenumber=1

Download:
http://hank315.dyndns.org/HC_0.1.zip

I've tried it and the results are not bad at all! :D
In fact, they're great! :wink:

Hi audioslave :D
Yes, I had noticed it since a few days ago.
It sure looks very much promissing.
It's still a few holes below tmpg for the moment being, quality and speed wise.
On the other hand it's still very young and most probably it has a lot of room to grow better and faster ;-)
And Hank sure has done a very nice job :arrow: in Fortran95 8O
I've sent him an email this morning to see if he wants to join us here at kvcd.net too ;-)
We're (me and Karl) waiting for an answer.
Let's keep our fingers crossed :mrgreen:
Cheers

I just recognised that developement today on doom9 :)
Yep looks like a new toy to test. But imho it could be that Hank wont participate in here as this forum is not free anymore.

:wink:

I did a quick test with the GUI version on the first 1000 frames of a movie. The process has finished, all the button in the GUI were greyed except the "exit" button. I exited.

Now the GUI hangs when I open an avs :-(

Is it a trialware limited to one attempt ? :D

Nope. No trialware :)
The X button doesn't respond when I hit it.
But I can use the exit button without any problem.
And I can re-use the tool as many times I want.
I just made sure that both my input avs path and my output m2v path are short and without any spaces on it.
But I am sure you also did the same :?
So I'm clueless of what's happening since I can't replicate it myself.
Cheers

Maybe a win2000 issue. I'll see on my winXP PC.

Hi,

I'm using W2K, and it works (encoding the 10th sample right now)...
Are you opening the same script?

Yes I did.

Note: I am the only one that had a finished encoding but with nothing enable inthe GUI but the ''exit' button ? Like if the tool was still working ?

Hi Phil :)
What do you mean by "nothing enabled besides the exit button"?
You mean that all other options/buttons are grayed when it finishes encoding?
If so, I must say that I have other options enabled on the GUI besides the exit button :?
Again, you are keeping your in/out paths short and without spaces aren't you?
Also don't use the Trim function as it gave me some hard work on the previous release 0.01 and I still haven't tested it on 0.1.
Instead I'm using the internal "cut" from HC.
Also be aware that HC uses DGDecode.dll to open a D2V source.
I am not sure if it also uses DGDecode.dll to open AVS scripts.
And I am using DGMPGDec package instead of DVD2AVI to create the D2V project file.
Would you care to install DGMPGDec on your PC and create the project file again to see if it works on HC?
I guess not, right? :lol:
If my above assumption is correct, then it is a big issue for kvcd.net users since we mainly use DVD2AVI 1.76 (or 1.77).
Keep us updated on the progress, Phil.
Cheers

Yes it is.

"D:\kvcd\test.avs".
I can do it shorter but... :-)

I used the same.

I tested on an avi, I didn't have any DVD ripped on my PC...

... but I already use DGIndex 1.0.2 (when I do a DVD so :-))

You guess almost right because... I will return back to MPEG2DEC3 very soon !
The blindPP function in new DGIndex.dll does not work ! It give an avisynth crash on almost all the xvids I try to convert, making my V4 script useless. As I continue to have most of my activity in KVCD on xivd sources, I don't care to have old DVD2AVI and MPEG2DEC3.

[edit]I will use the new feature that allows you to call a specific function by using <nameoftheplugin>_<nameofthefunction>. This way I will continue to have DGIndex.dll and MPEG2DEC3 in the same directory :idea:

PS: now that I rebooted the PC, the GUI perhaps works again but... I removed the sources so I can't test :-D

Hi all,

Just registered here today, kwag thanks for the very quick response :D.
First some words about the encoder, ATM the GUI is still pretty beta but I just put it online to get feedback to improve it. The "old" version which runs in a command prompt and uses an ini file to set all parameters is also still online and has the same encoding engine as the GUI version.
HC is written in Fortran95, it's the only language I feel comfortable with and still is one of the fastest. It also uses a lot of MMX/SSE stuff.
My goal was to create an encoder which would generate video streams which are DVD compliant (maybe not a big issue here).

The next GUI version will be ready in 1 - 2 weeks, a lot of the problems I read here and at Doom9 will be solved.
As a Fortran programmer I had some trouble to get used to the weird and twisted way a Windows program works.

- About the DGDecode issue, it's just the combination of DGIndex and DGDecode which will work properly, the latest beta of it (V7) is incompatible with the stable version (V6) so you cant' use DGIndex V7 with DGDecode V6. You could also use DVD2AVI projects if you rename the MPEG2DEC.dll to DGDecode.dll and place in the same directory as the encoder (or system32). Maybe I will implement a check by reading the first line of the d2v file and let it choose automatically the right decoder.
- Works only with Avisynth 2.5 for *.avs input, for an avi encode it will not need DGDecode.dll
- HC gets YUV planes (YV12 colorspace) from Avisynth or DGdecode and during encoding there are no colorplane conversions.

If there are new versions I will provide the link here also.

Releases so far:
first release http://hank315.dyndns.org/HC.zip
update: http://hank315.dyndns.org/HC_0.01.zip (exe only, *BATCH command added)
update: http://hank315.dyndns.org/HC.pdf (pdf of the manual)
update: http://hank315.dyndns.org/HC_0.1.zip GUI version (still pretty beta :)

And no, it's not trialware. it's freeware but closed source.

All questions/feedback are welcome.

Welcome Hank ;)

-kwag

@Hank315
Great seeing you here Hank ;-)
I'm the one who sent you the emails inviting you to join us too.
And also the one who mixed up things about Karl's email account :mrgreen:.
On to business.
I can't tell you how much I appreciate your work being freeware (even if closed source).
That only gives us more options besides libavcodec.
Having said that I must add that I am also loving Peter Cheat's & Nic's work.
As to comparisons (as the ones I have seen on D9) I gotta say that in low bitrate, that is below 2000Kbit, libav based encoders still got the lead in quality.
My tests were all done using "The Notch" (thanks for including it BTW) in 2-pass VBR mode.
I will perform them again and post you either a screenshot or the ini file.
I don't have much internet bandwidth but at least I'll try to post some pictures to illustrate my tests.
Stay tunned ;-)

@Karl
Could we maybe open a section dedicated to HC, or add it to an already made section like the Libav one?
TIA

Cheers all

Funny :?
I couldn't find any information regarding the Licensing you're using on HC.
Now I hate raising this issue, but it would be advisable to include it in the destributable zip files that you are linking.
And possibly include it in the nice PDF you're distributing too.
Just to prevent future issue, you know ;-)
Cheers

I will, but only with Hank's permission :!:
If he says OK, then a "HC Encoder" forum section will be born :)

Your call Hank ;)

-kwag

Just wanted to drop by and welcome Hank :wink: .

Also noticed with very low bitrates Quenc is a little bit better if all quality options are on, so I still have some work to do :lol:
Yes, Nic and Peter did a real good job squeezing the last bits out using libav, also like Quenc and Nuenc a lot.

OK, why not :D

Haven't thought about that, ATM it's just freeware but will think about it.

Done :D

-kwag

Welcome Hank,
as you can see, here at KVCD are all well aware of any tool that can improve the quality/way we make our encodings. And your tool was also welcomed.
Be sure some/many of us will keep an eye/test your encoder. It looks really nice.
Just curious, what parameters does affect it when choosing a "encoding profile"?.
Congratulations, and welcome again.

The parameter which is most influenced by the profile choice is the way the motion vector search works.
The better the MV predictions are the less there's to encode for P and B frames which should result in a better general quality.
The profile choice is only important for the first pass, the second pass just uses the information read from the database from the first pass.

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:
Just a small letterbox() to keep it anamorphic with an overlap overscan of 2.
The second script will also be very simple:
That is, the same as above with a simple combination of Undot().Deen().
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:
Basically it's the same as the above, simple overscan of 2, but with an adaptive denoiser and sharpner :)
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:
http://www.kvcd.net/downloads/out.m2v

@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

I haven't seen Kwag's sample clips yet, but if you say HC's are darker than Tmpg's then there's something wrong.
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 :?
I frames compression compared to NuEnc and Tmpg is very similiar and looking very good.
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

Hmm, I looked at the clips again after reading your post. And if kwag hasn't mixed up the clips the HC clip is darker...

: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).

Is it something with my eyes :?: :roll:
Howcome if both clips were encoded after the D2V extraction?
They both worked under the same circumstances, I believe...
That's a good point to start looking for, I agree.
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.

I was talking about the snapshots of audioslave's post. If you see tmpgenc snashop darker, so yes, there is something with your eyes :)

And the encoder, they do not touch the range ? :) Inc and Karl already pulled their hairs on this a few days ago. Tmpgenc cuts the range. If HC does not do the same, then you are comparing citrus and oranges.

So was I. When I watch audioslave's snapshots I can see Tmpg is darker than HC...
I'm using Firefox for what it's worth.

True but on my own tests I'm using Limiter() before and after the filters.
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

Here we go again.
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.

Never use Limiter, always use PC scale DVD2AVI and ask to the encoder to cut the range to TV scale.
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