HC encoder

[ernstblaauw]

I also got a problem with DVD-RB and HC. I think it's the fault of DVD-RB, but I'm not sure.
Here is the log :
-----------------
[11:02:08] Phase I, PREPARATION started.
- HC encoder selected
- "CCE Adaptive Quantizer Matrices" is enabled.
- VTS_08: 3.309.137 sectors.
-- Scanning and writing .D2V file
-- Processed 185.274 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 58,1%
- Overall Bitrate : 3.284Kbs
- Space for Video : 2.970.554KB
- Analyzing VTS_08 for optimal CQ factor.
-- TargetSize (sectors):1.507.556
-- Sampling 5568 of 185274 frames.
-- Predicted size (sectors) at CQ=3,1: 2.249.678
-- Predicted size (sectors) at CQ=4,6: 1.770.273
-- Predicted size (sectors) at CQ=5,3: 1.478.462
-- Predicted size (sectors) at CQ=5,2: 1.478.462
-- Predicted size (sectors) at CQ=5,1: 1.478.462
-- Predicted size (sectors) at CQ=5,0: 1.478.462
-- Predicted size (sectors) at CQ=4,9: 1.770.273

Look at the predicted size.
I suspect this will go on forever. Is it possible the problem is related to the decimal (‘.’ And ‘,’)? I'm in Europe, maybe his has something to do with the metric settings?

[jdobbs]

This really has nothing to do with HC. DVD-RB does the predictions.

[unplugged]

For DVD content is it advised to use 9 or 10 with DC precision, qualitywise?
If I well remember the right DC value con be guessed depending by target bitrate... no?

[jdobbs]

Originally posted by ernstblaauw
I also got a problem with DVD-RB and HC. I think it's the fault of DVD-RB, but I'm not sure.
Here is the log :
-----------------
[11:02:08] Phase I, PREPARATION started.
- HC encoder selected
- "CCE Adaptive Quantizer Matrices" is enabled.
- VTS_08: 3.309.137 sectors.
-- Scanning and writing .D2V file
-- Processed 185.274 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 58,1%
- Overall Bitrate : 3.284Kbs
- Space for Video : 2.970.554KB
- Analyzing VTS_08 for optimal CQ factor.
-- TargetSize (sectors):1.507.556
-- Sampling 5568 of 185274 frames.
-- Predicted size (sectors) at CQ=3,1: 2.249.678
-- Predicted size (sectors) at CQ=4,6: 1.770.273
-- Predicted size (sectors) at CQ=5,3: 1.478.462
-- Predicted size (sectors) at CQ=5,2: 1.478.462
-- Predicted size (sectors) at CQ=5,1: 1.478.462
-- Predicted size (sectors) at CQ=5,0: 1.478.462
-- Predicted size (sectors) at CQ=4,9: 1.770.273

Look at the predicted size.
I suspect this will go on forever. Is it possible the problem is related to the decimal (‘.’ And ‘,’)? I'm in Europe, maybe his has something to do with the metric settings? I fixed this for v0.87. I was using a built-in routine to do the formatting... and I'd forgotten that it would change the decimal to "," in some countries. It not only reports incorrectly, but forces HC to use the integer portion of the value in the INI. That's why it was getting hte same values for 4.6 and 4.9 as well as the 5's...

[onesoul]

Originally posted by unplugged
For DVD content is it advised to use 9 or 10 with DC precision, qualitywise?
If I well remember the right DC value con be guessed depending by target bitrate... no? Here is a quote from pdf file of cce 2.5:Specifying intra-DC precision
Specify the bit precision of the DC coefficient of the intra-block in
Intra DC precision in the video settings screen. One of 8, 9 and
10 bits can be set here.
In general the optimum settings cannot be determined since changes
depend on the details of the picture and movement intensity. For pictures
with intensive movement and fine bumps, a low number of bits
is appropriate. For smooth pictures with little movement, a higher
number of bits is appropriate. A low number of bits may be specified
for use at a low bitrate up to 4Mbps, and a high number of bits may
be specified for use at a high bitrate.
When Auto is selected, the precision varies according to quantization
scale.
For details, refer to the guides on MPEG-2. I recommend using dc precision of 9, I hardly any differences between 9 and 10 btw.

[Archimedes]

The right intra dc precision depends on the encoder and the source video. The differences are very small.

I’ve tested the HC Encoder with a test clip from
http://www.tecoltd.com/enctest/enctest.htm
and a special software. I have encoded with dc 10, 9, and 8. The best results offers the video with dc 8 (because of the special test clip). It depends on the source video.

However, the default in HC (dc 9) is ok.

[dragongodz]

The right intra dc precision depends on the encoder and the source video
the target bitrate plays a large part in this. if you are targeting a low bitrate a lower dc precision such as 8 can yield better appearing results. lower DC requires less bitrate. while with a higher target a higher DC can provide a slightly sharper/clearer picture.

[ljpp]

@hank

The changelog of HC .14 says "improved encoder". Could you give bit more details what kind of improvements to expect?

[freelock7]

-Hank
Great step ahead -once again!-with this Constant Q DVD compliant in HC014beta!
I was waiting for this fix for a long time!
Now first pass is possible in a quick time with very high quality!
Nice!:)

[hank315]

The changelog of HC .14 says "improved encoder". Could you give bit more details what kind of improvements to expect?Quality should be a bit better, Q-values are now better distributed for each frame.

[freelock7]

-Hank
Is it possible to add a <shutdown> option in the command line for HCBatch?

[hank315]

@freelock
No problem, will add the next command: *SHUTDOWN
Will be in the next version.

[katjarella]

Please, hank315 - if you really insist in adding a *SHUTDOWN command: Please add a countdown that someone may abort the shutdown if it accidently was included in the INI. And it shall run at least 5 minutes before proceeding! Thanks.

@freelock7
Is Electricity in Belgium so expensive that you have to save every minute?! Our bakers are more expensive than the Electricity. :D

[LigH]

Oh, girls can be so funny... Don't mess around! ;)
__

I would like to see a way to export the current settings to an INI file from the GUI version for use in the batch version, as well as an import of options from a batch INI into the GUI (including the file names). This could make debugging easier, as well as preparing a batch run (editing INIs with a text editor is a little annoying).

[lunario]

hank about the memory error with hcbatch i´ve used the gui version to encode a movie and no errors so i think that error is only with hcbatch and ex avi2dvd ( ithink it´s the only app that has native support for hcenc (dvdrebuilder too)

[freelock7]

-Hank
THX.
-Katjarella
Keep the earth clean. Everything has to be used correctly.

[Vitos]

I've been watching this nice encoder from its beginning. It really had a very strong start (I didn't ever expect it to be such a great encoder written from scratch). However my interest for MPEG-2 encoder is because I recently started archiving my home DV-camera recordings - lots of pan, zoom and shaky interlaced footage. Unfortunately this encoder loses very fast comparing to QuEnc or Freenc (ffmpeg based) - I noticed blocking with almost every average camera pan and it becomes extremely visible with some more dynamic scenes. I verified it with motion vector visualisation in ffdshow - in at least 30% of camera pans many vectors point to random directions and once in a while all of them go nuts! Other mentioned encoders are much better in this aspect. Going up with bitrate doesn't visually help too much.

PS.
By the way - on my W2k SP4 PL I can't load any AVS file with the GUI v0.13 and v0.14 (even simple one line AVISource command, ConvertToYV12 doesn't help). GUI just freezes after load attempt, no CPU, no drive activity. I have Avisynth 2.5.5 installed.

[dragongodz]

lots of pan, zoom and shaky interlaced footage
well i can not speak for DoctorRad but i tested this before release with fades and pans and was fine. i didnt test with interlaced though so will check it out soon and talk to hank315 about anything i find.

on my W2k SP4 PL I can't load any AVS file with the GUI v0.13 and v0.14
known problem for W2k thats already being looked at.

[DoctorRad]

Originally posted by Vitos
I've been watching this nice encoder from its beginning. It really had a very strong start (I didn't ever expect it to be such a great encoder written from scratch). However my interest for MPEG-2 encoder is because I recently started archiving my home DV-camera recordings - lots of pan, zoom and shaky interlaced footage. Unfortunately this encoder loses very fast comparing to QuEnc or Freenc (ffmpeg based) - I noticed blocking with almost every average camera pan and it becomes extremely visible with some more dynamic scenes.

I will capture some high motion interlaced sports footage and do some tests... which version(s) have you found problems with, Vitos?

Dr. Matt...

[Vitos]

Originally posted by DoctorRad
I will capture some high motion interlaced sports footage and do some tests... which version(s) have you found problems with, Vitos?

Dr. Matt...

Practically all (don't remember how it was with first released v0.01). But for sure I get poor picture in described conditions with 0.12, 0.13 and 0.14. At first 0.14 test I got the impression it was slightly better, but I need to encode again some footage with previous versions for comparison to confirm that (don't have time right now).

[DoctorRad]

Originally posted by Vitos
Practically all (don't remember how it was with first released v0.01). But for sure I get poor picture in described conditions with 0.12, 0.13 and 0.14. At first 0.14 test I got the impression it was slightly better, but I need to encode again some footage with previous versions for comparison to confirm that (don't have time right now).
I captured some in-car footage from the W*rld R*lly Ch*mp**nsh*p over the weekend, which is both interlaced and panning/zooming almost all the time. I think the motion vectors could perhaps be better, but then you often don't quite get the results you expect from Motion Estimation. I'll discuss with hank.

Another question for Vitos: What resolution and bitrate are you encoding at?

Dr. Matt...

[archrival]

I remember reading a while back about this being written in Fortran 95, I also noticed that the newest version of gcc now supports that version of Fortran. Could this be ported to a shared library for use on multiple o/s's?

Edit
I guess I could read page 2, the only page I didn't read. Either way, I don't think the question was answered.

[Vitos]

Originally posted by DoctorRad

Another question for Vitos: What resolution and bitrate are you encoding at?

Standard PAL 720x576 resolution, I tried 5000 and 7000kbps bitrates (going lower makes image quality unacceptable).

[Vitos]

Originally posted by Vitos
Standard PAL 720x576 resolution, I tried 5000 and 7000kbps bitrates (going lower makes image quality unacceptable).
Ok, so to prove my obseravations:

Here one of the "crazy motion vectors" frame I was talking about, encoded with HC at 5Mbps:
http://home.elka.pw.edu.pl/~woleksia/MotionHC512.jpg

And the same frame done by QuEnc:
http://home.elka.pw.edu.pl/~woleksia/MotionQuEnc512.jpg

How does it looks visually? Such single frame doesn't have much impact on visible image quality, but after a few poor motion estimated frames heavy blocking occurs.
You can observe it on these sample video (QuEnc much better):
HC v0.14 encoded (http://home.elka.pw.edu.pl/~woleksia/testsampleHC5k.m2v)
QuEnc 0.59b4 encoded (http://home.elka.pw.edu.pl/~woleksia/testsampleQuEnc5k.m2v)

Both encoded with 12 GOP, 2 B frames, MPEG quantization, interlaced BFF, trellis disabled for QuEnc.

They might not be available on this server for too long, so better be quick.

Edit:
PS. Is there a possibility to insert image directly visible in the post (not as link like I did)?

[LigH]

According to the vB code docs (http://forum.doom9.org/misc.php?s=&action=bbcode), the IMG tag should have been working; probably it was disabled for this forum because inline images cause so much traffic and slow down page loading.

[onesoul]

Actually you can insert images directly if use it like:
*URL=http://---.jpg]*IMG]http://---.jpg[/IMG][/URL]

Switch * for [ and it will work.

edit: hmm, for inserting thumbnails it works, not sure about a full size image though.

You can use imageshack which generates a thumbnail automatically and even outputs the code described above.

[DD51]

Man o man after watching these 2 clips for awhile I got really dizzy!!!
Going to lie down for awhile...

[ukb008]

Hi.

Please can you give me the website of HC or the location of a standalone help file?

Regards.

[LigH]

As far as I know, this thread is the "website of HC". ;)

Look at the beginning of the thread, the archive contains all files - including the PDF documentation.

[Vitos]

Originally posted by DD51
Man o man after watching these 2 clips for awhile I got really dizzy!!!
Going to lie down for awhile...
Heh, I selected the most hard to consume fragment not only for encoder. :)
Of course this one is hardly watchable at all, but it shows what happens in some places with some "normal" recordings when ie. half a second of much movement occurs.

[Encoder Master]

I have a question to this test clips.

Could it be that the videos are interlaced?
I've testet a lot and HC Encoder looks on my progressive videos very very good.

Now, I was surprised. I've tested first QuEnc with a movie and compared it with HC Encoder and I can't realy saw a difference. Both videos looks better then the TMPGEnc produced. In some pics HCE looks better and another QuEnc. But HCE gives me more of this great pictures. But I test again.
And also HCE is so fast in 2Pass. QuEnc on my P4 with the best settings only 11-12 FPS :( .


Last I have a question to Closed GOP. If I have enough bitrate should I closed the GOP with HC Encoder?
With TMPGEnc and Glosed GOPS the results are better. And what is with HCE?

Thanx for listening.

[SILICON]

3 pass mode will be more quality?. I don´t care wait for encode.
Is hard of program a 3 pass mode in HC encoder?

Tranks.

[ukb008]

Where do I get more info about KVCD except on www.kvcd.net ? That site has practically no info to outsiders, info like what the place of KVCD is, in a world where there are XviD and DVD and Doom9's fora. What are the advantages in terms of quality, cost and time? Etc.

Regards.

[Boulder]

Originally posted by SILICON
3 pass mode will be more quality?.
Probably not. If the rate control is good, you don't need any more than 2 passes.

[jdobbs]

Exactly. There's no reason why you shouldn't know everything you need to know to allocate bits after the first pass. The second pass just does it..

[ukb008]

AGK has been known to perform more than two passes...running the first pass more than once. Although, logically, what jdobbs said is right.

Regards.

[Boulder]

Originally posted by ukb008
AGK has been known to perform more than two passes...running the first pass more than once.
The latest DivX5 supports doing more than 2 passes, maybe that's why. I don't know if XviD updates the stats file during the second pass.

[hank315]

ATM I'm not planning to do more than 2 pass encoding.
Think it's better to optimize the 2 pass encoding then to come up with a multipass encoding...

BTW, is there somebody who can really see the difference between a 5 or 6 pass CCE encoding ;)

[Fishman0919]

BTW, is there somebody who can really see the difference between a 5 or 6 pass CCE encoding


Me, Me, oh me... opps sorry, I thought you said CAN'T see the difference...then again I couldn't see the difference between 2 passes and 100 passes with CCE SP 2.70 :D

[dragongodz]

And also HCE is so fast in 2Pass. QuEnc on my P4 with the best settings only 11-12 FPS
i wish people wouldnt do this. HC and QuEncs settings are not the same, especially if you use things like trellis or insane and extreme settings, as HC doesnt have these. please understand this and dont try and make speed comparisons based on things you obviously dont comprahend.

3 pass mode will be more quality?
a 3rd pass may help reditribute bits a bit more in rare cases but should not be really needed. the only case i can think of that HC would NEED it is if a VBV fix fails, then another pass could redo the previous frames to prevent this. since i dont see this happening too much it would appear to not be needed.
of course its possible to combat that likely hood or need aswell. you would read a frame, encode it, hold it in memory, read next frame, encode it, if a VBV fix fails redo the previous frame still held in memory to account for it. write first frame and hold second in memory, read next frame and repeat. of course using skipped MB would also make VBV failure extremely unlikly aswell without the need of any of that. from our discussions i know hank315 will follow all that. :D

BTW, is there somebody who can really see the difference between a 5 or 6 pass CCE encoding
actually the question was difference between 2 and 3 pass where it is possible for there to be a small difference. such as if frames were heavily quantised to satisfy VBV a 3rd pass could lower previous frames to allow for higher after frames and possibly looking better for a fraction of a second. a rare case which would hardly make any difference i know but even that can be averted with the buffered method i mention above for those 1 in a X cases. :)
anything over 3 passes is ridiculous and if it really produces better results you would have to ask what the encoders problem is that it cant do its job in a sane amount of passes. :sly:

[ljpp]

@Dgz
i wish people wouldnt do this. HC and QuEncs settings are not the same,

On the other hand, if HC delivers comparable or better results than QuEnc, while obtaining a much higher encoding speed -- why not compare them? After all, CCE is always praised for it speed, while setting are not same, etc. etc.

[dragongodz]

On the other hand, if HC delivers comparable or better results than QuEnc, while obtaining a much higher encoding speed -- why not compare them? After all, CCE is always praised for it speed, while setting are not same, etc. etc.
because you are comparing against settings you dont understand.
for example, trellis, the implamentation in libavcodec is absolutly not optimised for speed. i have seen it said before it was going to be but it still hasnt been and IMHO is actually pointless the way it is. you sometimes gain a small quality increase but at a speed that doesnt really justify it. you will most times not be able to tell if it wasnt on but encoding speed increases a lot.

as for the "extreme and slow" setting i will quote from the QuEnc_Settings.txt that is with most releases.
This is experimental, not recommended, but turns on many settings that can increase quality
so far the tests i have done and also reading what others have written low bitrate encodes quality is better but again there is a huge speed hit for it.

try just using High Quality, which also increases quality, with QuEnc and then see the speed and quality difference compared to using the settings above.

hank315 - sorry for taking this off track a bit. :)

[ljpp]

@hank

Do you have new releases planned - when can we expect an update to this already great performing encoder?

[hank315]

Do you have new releases plannedYes.

when can we expect an updateUh... always hard to answer this, let's say when it's finished :)

And ATM I even don't know yet what new stuff will be implemented.
One thing is for sure, the next release is meant to raise quality, not speed.

[Oldeman]

Quality os always good to strive for....:sly:

[ukb008]

Does HC-Enc have a website where more info can be read?

Regards.

[artoor]

Originally posted by ukb008
Does HC-Enc have a website where more info can be read?

Regards.
It seems that this thread is the best site where You can read about HC-enc... And HC014.pdf included in HC_014.zip file as well :)

Regards

[krbo]

can't find anyone reported the same so :

HC GUI is not working on win2k sp4 (celeron 2.4) with Avisynth 2.55

Simply chokes ("not responding") after loading script.

Not even simpliest avs (version())

Tested 0.13 and 0.14

with .d2v works OK

With the same avs HC batch works like a charm !

[LigH]

@ krbo:

You cannot find half of this thread (http://forum.doom9.org/showthread.php?s=&threadid=88888)? It is known for months now that HC has problems opening AviSynth scripts under Windows 2000 (the last report was by Vitos, one page ago in this thread here), but HCbatch works well instead. And the reason was not yet found AFAIK, because hank315 is not able to recreate this bug - at his machine, everything works well.

[krbo]

Originally posted by LigH
@ krbo:

You cannot find half of this thread (http://forum.doom9.org/showthread.php?s=&threadid=88888)? It is known for months now that HC has problems opening AviSynth scripts under Windows 2000 (the last report was by Vitos, one page ago in this thread here), but HCbatch works well instead. And the reason was not yet found AFAIK, because hank315 is not able to recreate this bug - at his machine, everything works well.

sorry, it's not easy to find something called HC or CCE with search engine like here where these terms are too short for it.

hank315 should put "known bugs" somewhere in HC readme