Log in

View Full Version : HCenc 023 released


Pages : [1] 2 3 4 5 6 7 8

hank315
11th May 2008, 23:30
Major changes:
- added adaptive quantization
- added panscan

And as usual some bug fixes.

Thanks to the beta testers and those who provided sources to tackle some nasty bugs.

http://hcencoder.bitburners.com

Irakli
11th May 2008, 23:56
Awesome news! And thanks for great encoder!

I am quite curious about the new AQ. I will test it soon.

Btw, does your AQ have anything in common with VAQ used in x264? Or does it use completely different algorithm?

Regards,
Irakli

45tripp
12th May 2008, 01:20
:thanks:

rcubed
12th May 2008, 06:49
Hank,
Thanks for the release of HC023, also for adding the button to specify the lossless file location. An additional donation on it's way.

I really appreciate and applaud your efforts. Keep up the excellent work.:thanks:

Sincerely,

rcubed

Sharc
12th May 2008, 09:10
The links to HC23 at bitburners.com are dead ....

smok3
12th May 2008, 09:59
:thanks:

edit: direct link removed.

Dkruskie
12th May 2008, 11:46
Thanks Hank :)

manolito
12th May 2008, 12:43
Thanks very much Hank!

And I already need some advice concerning the new "Adaptive Quantization" feature.

To avoid blockiness in flat scenes I so far have used "Lumgain 3" quite successfully. Now it looks like I can get the same effect by using adaptive quantization. Which one of the two methods is the preferred one? Or should both methods be used at the same time for optimum results?

Cheers
manolito

hank315
12th May 2008, 12:50
Yes, the links are dead ATM.
Already mailed them, will be fixed soon I hope but the link provided by smok3 does work.

Btw, does your AQ have anything in common with VAQ used in x264? Or does it use completely different algorithm?
I don't know exactly how it is implemented in x264 but IIRC it uses a variance based decision method, something similar is also used in HC023.

Rogi
12th May 2008, 14:54
Thank you very much for your hard work.:)

linx05
12th May 2008, 17:25
Thank you so much!

nevragain
12th May 2008, 19:18
thank you very much
what is "panscan"?

guada2
13th May 2008, 16:21
Hello hank315,
Good work..

Why have limited the number of B frames to 2 (in GOP Structure)?
Can you adjust the AQ Strength decimal (0,2; 1,3...)?

Bye.

pandy
13th May 2008, 17:36
what is "panscan"?

http://en.wikipedia.org/wiki/Pan_and_scan

Irakli
13th May 2008, 18:15
I don't know exactly how it is implemented in x264 but IIRC it uses a variance based decision method, something similar is also used in HC023.

Thanks for the info.

Why have limited the number of B frames to 2 (in GOP Structure)?

Probably because DVD Video standard supports up to 2 consecutive b-frames only.

shon3i
13th May 2008, 19:51
from HC PDF documentation :)

*B3
parameter - type -
Status not required
Default -
Example *B3
This command allows 3 consecutive B-frames, NOT DVD-COMPLIANT.

kumi
13th May 2008, 20:10
Thanks Hank!

Will *AQ > 0 use *MATRIX or *CUSTOMMATRIX as the baseline matrix, or will it instead use a hard-coded one?

nevragain
14th May 2008, 00:35
http://en.wikipedia.org/wiki/Pan_and_scan

I know thats what pan and scan is. How does this apply to HC does it do this automatically?

Gannjunior
14th May 2008, 09:57
hank,

i would like to say that your encoder is the best to hit higher ssim and psnr value...it manages really well HD clip and it is really tunable ( just i would like also 1pass vbr as in CCE beacuse i need for some test i'm doing...) and its second pass it is amazing to goal the exact size i want!!

big work.
thanks!

ciao

BDrift
14th May 2008, 23:48
Thanksē for another fine release :) seems it's time to finally donate!! :p

manolito
16th May 2008, 20:23
I did a couple of test encodes using either *AQ 3 or *LUMGAIN 3. The source was quite dark, average bitrate a little over 5000 kbps. The matrix I used comes from manono:
8, 8, 8, 9,11,13,14,17,
8, 8, 9,11,13,13,14,17,
8, 8,11,12,13,14,17,94,
9,11,13,13,14,17,17,94,
11,11,13,13,14,17,94,94,
13,13,14,16,17,20,94,94,
13,13,14,17,94,94,94,94,
13,14,17,94,94,94,94,94

12,12,13,14,15,16,22,26,
12,13,14,15,16,22,26,32,
13,14,15,16,22,26,32,41,
14,15,16,22,26,32,41,53,
15,16,22,26,32,41,53,94,
16,22,26,32,41,53,70,94,
22,26,32,41,53,70,94,94,
26,32,41,53,94,94,94,94


To make it short: I could not detect any differences between the two encodes. Maybe the bitrate was too high. AQ 3 did compress slightly better than LUMGAIN 3, but this probably depends on the source.

So more testing needed, I guess...

Cheers
manolito

Boulder
19th May 2008, 17:17
Try sources with flat areas versus sharper edges..the bits should be shifted from the edges towards the more flat areas of the frames. Also scenes with grass or similar texture are quite good.

blutach
21st May 2008, 08:19
As usual, I am late with my thanks Hank. :)

Regards

asarian
21st May 2008, 09:43
Outstanding piece of work, that HC encoder of yours!

:thanks:

phXql
26th May 2008, 06:59
Great piece of software. Thank you!

six13
30th May 2008, 05:27
Can someone please explain the 4 settings in AQ vs the 4 settings in LUMGAIN? I am trying to understand what to look for. I have previously used LUMGAIN 4 and liked the video. AQ has me puzzled, I saw the comments of Boulder but am still puzzled. I mainly compress/encode TV captures movies at a bitrate of 4K/S with small compression % like 82% with DVD-RB. I do notice that the detail on a face isn't real good it looks kinda flat. I am learning and would welcome opinions. Thanks in advance.

Dark Shikari
30th May 2008, 05:33
I do notice that the detail on a face isn't real good it looks kinda flat.Unless I'm mistaken, HC uses luminance-masking adaptive quantization, which won't help in such a case (one needs complexity masking like x264 has).

Boulder
30th May 2008, 06:09
AQ adapts the quantization, LUMGAIN affects the quantization matrix. hank posted the code related to LUMGAIN in the HC Encoder thread which shows how it works. Basically LUMGAIN lowers the coefficients of the base quantization matrix depending on the luminance levels. The strength affects the factor used in determining the new coefficients.

If I'm not entirely mistaken, AQ is meant for shifting bits inside one frame - from sharp edges to the more flat areas. LUMGAIN is supposed to shift bits to low-luminance frames from the brighter ones to prevent blocking in dark frames.

six13
31st May 2008, 01:26
So Boulder, then is it OK to use them at the same time or is it best to pick 1 or the other? In the past you have sugested I use LUMGAIN 4 and i like the output but was wondering if AQ would produce better results then LUMGAIN. What I recently encoded didn't have many dark sections. What do you use to make the decision as to use LUMGAIN or AQ?

Boulder
31st May 2008, 17:52
I use 3 for both AQ and LUMGAIN. They are two different things so they can be used together.

hank315
31st May 2008, 23:42
AQ is meant for shifting bits inside one frame - from sharp edges to the more flat areas. LUMGAIN is supposed to shift bits to low-luminance frames from the brighter ones to prevent blocking in dark frames.
Yes, that's what it does. The final quant for each MacroBlock: Q(i,j) = QMB * Qmatrix(i,j).
QMB is adjusted by the variance of the MacroBlock --> AQ.
Qmatrix(i,j) is adjusted by the average luminance of the frames in a GOP --> LUMGAIN.

Unless I'm mistaken, HC uses luminance-masking adaptive quantization, which won't help in such a case (one needs complexity masking like x264 has).
HC doesn't use luminance-masking adaptive quantization, the quantization is adapted by the variance of the MB so it's some kind of a complexity mask.
This picture (http://i25.tinypic.com/2j67594.png) shows the Quants of the same frame for different AQ values.

Dark Shikari
31st May 2008, 23:50
HC doesn't use luminance-masking adaptive quantization, the quantization is adapted by the variance of the MB so it's some kind of a complexity mask.
This picture (http://i25.tinypic.com/2j67594.png) shows the Quants of the same frame for different AQ values.Oh, so its like VAQ, complexity masking. Good to know that you've implemented a useful AQ method :)

six13
1st June 2008, 04:01
Thanks Boulder, which matrix do you use with those settings in HCenc?

Boulder
1st June 2008, 08:18
The matrix depends entirely on the source. Use the search, there are quite a few threads about this issue.

zeropc
7th June 2008, 14:33
hank, first let me say this is a very nice tool. i just started using it and the results are so far pretty good. but there are some open question for me in fully understanding the usage and some minor issues. i hope you or somebody else can help with this.

1. i currently set aq to 0 and the luminance gain to 0 , is this good or should i raise it? i encode from br/hd-dvd sources at 18mbps
2. i experienced that hcenc seams to lower the colors by a bit. i re-encoded the simpsons movie and saw how the skin colors faded a bit, which kinda bugs me
3. is there a way to scale hd sources to dvd res (pal and ntsc)?
4. is it possible to import .dga files from dgavcindex besides using avisynth?

gizzin
7th June 2008, 22:50
1. I say leave it on, especially at the bitrate you are using.
2. I never heard of that before, but maybe, how/what program are you using, what kind of file (DVD,XVID), essentially what I'm saying is you need to provide more information.
3. Yes
4. Not sure. I wouldn't think so.

Hank, I get this mismatch error with v23. "Error, large source mismatch found in pass 2 starting at frame:0, count :1 frames." I'm using FAVC 1.06. Just thought I'd point that out. It seems to be only this program that experiences this problem, as I use DVD Rebuilder and it never happened.

Graigddu
7th June 2008, 23:35
gizzin i remember that i came across this error before or something similar and after a bit of searching found that ticking reload avisynth during second pass under the settings 3 tab in the HCGUI fixed the problem, remember to save HC Ini in main tab or any settings changes won't take effect

Revgen
8th June 2008, 00:34
Quality is good as long as I keep AQ off. Not much different than HC022.

BDrift
8th June 2008, 03:26
Zones don't seem to work for me :(


*ZONE 3
1 0.2
1200 1.0
163500 0.2


Thats what I use in hc.ini, but when I compare it with a encode without zones, there is close to zero difference visible, not even in a frame by frame comparison. Am I missing something? Shouldn't frames 1-1200 and frames 163500-end have a ~80% lower average bitrate?

For testing I've set end frame to 2000 ... could that be causing trouble?

lithoc
13th June 2008, 18:28
I've found a bug that cause Ifoedit to crash when muxing.

I encoded some 352x240 video. I found out that Ifoedit will crashed at the beginning if the video bitrate is below ~256kbps.

I notice video having a black fade in. When the black is usually low bitrate that's where the Ifoedit crashed.

If I encode the video starting frames of 100 where there's no black screen. Ifoedit mux just fine when the bitrate is > 256kbps.

Can HCenc have minimum bitrate settings?

totya
15th June 2008, 14:56
Thank you (developer) for this great application!

magic75
2nd July 2008, 20:07
I am having problems getting the aspect ratio choice to "stick". With 0.22 I can choose 4:3, hit save hc.ini, and the next time I start up hcenc the aspect ratio is set to 4:3. With 0.23 it seems to "reset" to 16:9 no matter what.

Rogi
2nd July 2008, 21:41
I am having problems getting the aspect ratio choice to "stick". With 0.22 I can choose 4:3, hit save hc.ini, and the next time I start up hcenc the aspect ratio is set to 4:3. With 0.23 it seems to "reset" to 16:9 no matter what.

I don't know what is the problem but on my computer HC 0.23 works well and remember my aspect ratio choice.

krosswindz
4th July 2008, 17:24
I have been using HC enc for sometime. I am trying to use HC encoder inside a VMWare. I tried HC 022 and 023 both crash immediately opening the send report dialog. I would really like to be able to run HC encoder in the VMWare. Any help in solving this would be appreciated.

krosswindz
4th July 2008, 18:10
I looked further into this problem seems like HC Enc and MT_Masktools-26.dll dont like each other. Is this an known issue or something, I am seeing for the first time. The vesion of MaskTools is 2.0.35.0

rendez2k
10th July 2008, 18:35
For the first time, I noticed an error with HCEnc yesterday, ERROR, source mismatch in pass 2 starting at frame: 0 - never seen this before but I'm not sure if its a HCEnc 023 issue or FAVC? What does the error actually mean?

Rumbah
14th July 2008, 14:23
It's probably your Direct Show decoder that does not support frame accurate seeking as the error message means that the first frame in the first pass is different form the first frame in the second pass.

You could try to fix it by enabling the reload Avisynth switch in HCEnc. It was made for these kinds of errors.

Boulder
14th July 2008, 14:30
You could try to fix it by enabling the reload Avisynth switch in HCEnc. It was made for these kinds of errors.You could also try enabling the lossless file option if you have the extra HD space it requires.

rendez2k
14th July 2008, 14:53
It's probably your Direct Show decoder that does not support frame accurate seeking as the error message means that the first frame in the first pass is different form the first frame in the second pass.

You could try to fix it by enabling the reload Avisynth switch in HCEnc. It was made for these kinds of errors.

So does that mean the encode will be damaged in some way? Is there a better decoder I could be using?

Rumbah
15th July 2008, 12:22
If you use reload Avisynth and you don't get an error everything should be fine.