HC encoder

[hank315]

Please post all HC issues here now.

HC can be found in the download section but also here:

HC016 latest release at: http://hcencoder.bitburners.com/

[hank315]

Some issues from the old thread:
Is it possible now to use one pass for DVD encoding (so HC will stay under a certain maximum bitrate, specified before encoding)?I'm with freelock - I'd love to see some sort of combination of constant Q and max bitrate where the encoder encodes at a certain quant unless the bitrate is exceeded and a lower quant is used for that section.This will be in the next release.

Bug:
1.) KVCD-NOTCH matrix didn't work.Yep, I know, will be fixed.

Might be nice to check for any hardware requirements up-front...It does.
To run HC needs MMX/ISSE, if SSE2 is supported it will use it, if SSE3 is supported it will use it.
Only changed the minimum check from MMX/SSE to MMX only otherwise some older AMD's wouldn't run it.

004722FF FF 15 F0 31 47 00 call dword ptr ds:[4731F0h]
00472305 8B 48 0C mov ecx,dword ptr [eax+0Ch] ; EAX == NULLDon't have a clue :) call is to a user32.dll routine, before that eax is pushed on the stack and probably comes out wrong, really don't know.

[dragongodz]

some more Q and A's moved here so they are not asked again. :)

Didn't save settings when quit. Everything is load to default.
yes hank315 knows this. we have discussed it so several times. i think,rightly, he was more interested in improving speed and rate control however for this release.

How fast is HCenc013 compared to CCE or to HCEnc012?
slower than CCE and faster than HC 0.12. speed increase seems to scale with the profile, that is BEST has the largest speed increase while FAST has the smallest. also hank315's P4 gained more increase than my Athlon XP 2400+ proportinatly. try it for yourself and see.

And, is that countdown really necessary? If I'm calling HCbatch from Rebuilder, and not looking at your GUI screen, it seems to be just a waste of time.
hank315 already added the *wait command in 0.12 so exiting could be faster if used.


and finally
i just noticed another little bonus. me mentioned in the thanks.txt. nice. thanks hank315. :D

[ljpp]

"Improved speed" is a huge understatement. On a P4 HT 2.66GHz the encoding speed has roughly doubled since the 0.12, and HC is now 4-5 times faster than QuEnc (profile BEST vs. QuEnc High Quality+Trellis).

I never expected such a speed bump! Awesome work.

[dragongodz]

profile BEST vs. QuEnc High Quality+Trellis
sorry but you are comparing things that 1 encoder does that the other doesnt, that is trellis. HC doesnt do it so if you want a more realistic comparison try QuEnc + HQ versus HC BEST. or you could try HC NORMAL or FAST to QuEnc with HQ and TRELLIS etc turned off.

also as i said P4's get a huge speed increase while Athlons increase ,while still big, is not as large.

[Yuri]

Beautiful Encoder!

Thank you for the great encoder

[onesoul]

@ Yuri

I've seen that same frame on a comparison done by you, it must be haunting you eheh ;).

Would be very useful if you provided all the settings used for each encoder such as max bitrate, GOP structure, number of passes, bias, quantizer precision, DC precision. Quantizer precision and bias only applies to CCE of course.

I did much more testing on interlaced source before, now I started on progressive tests such as an anime monsters_inc and unlike before, CCE is giving better results no matter what (I tried only against HC and amongst many different settings, average bitrate was between 3000 and 3500 and it envolved fading scenes).

I have of course no expertise on video encoding but what I guess is that HC handles fields in a better way then CCE when encoding as interlaced, but I'd like to hear someone else's opinion on that.

I'd like to hear your opinion on progressive natural film also, I will try that as soon as I can too.

[lamster]

Originally posted by hank315
004722FF FF 15 F0 31 47 00 call dword ptr ds:[4731F0h]
00472305 8B 48 0C mov ecx,dword ptr [eax+0Ch] ; EAX == NULLDon't have a clue :) call is to a user32.dll routine, before that eax is pushed on the stack and probably comes out wrong, really don't know.
More specifically, the call is to GetWindowLong(). It's pushing a value of 8 (representing the third integer from the extra window memory). A return value of 0 can indicate an error, but the routine that started at 004722f0 (in 0.13; 0046d510 in 0.12) doesn't check that the returned value is non-0; it just attempts to use it as a pointer.

[lamster]

Someone else reported a crash (in the Rebuilder thread).

Here's the call stack to that routine, in case you can use it to figure out what's going wrong.ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0012fef4 0046d140 00598d64 00598d38 0012ff34 HCbatch_013+0x72305
0012ff04 004174aa 00598d38 00000000 08b81c40 HCbatch_013+0x6d140
0012ff34 0045a6b0 00400000 00000000 00132a57 HCbatch_013+0x174aa
0012ffc0 7c59893d 00000000 00138fb0 7ffdf000 HCbatch_013+0x5a6b0
0012fff0 00000000 0045a5e2 00000000 000000c8 KERNEL32!BaseProcessStart+0x3d

Note that 00598d64 is the hWnd being passed to GetWindowLong().

[hank315]

More specifically, the call is to GetWindowLong(). It's pushing a value of 8 (representing the third integer from the extra window memory). A return value of 0 can indicate an error, but the routine that started at 004722f0 (in 0.13; 0046d510 in 0.12) doesn't check that the returned value is non-0; it just attempts to use it as a pointer.Also looked at the disassembled code, see what you mean. Will try to see where this actually is in my code but because all the Windows calls are interfaced (Fortran --> Windows calls) it may be difficult to find it, this assembler code is probably from one of the interface routines.
Will check my own calls which ends the program.

BTW. if this happens the m2v file is already written and closed so it should be OK, seems it's easier to encode a movie then to end a Windows program :)

[lamster]

I tried putting a break-point on it, but it's called constantly - probably in a message loop.

I reproduced the crash a few times, but also had it end successfully a couple of times (all running against the same .ini file), which suggests it might be a timing problem. Maybe the order in which child windows are closed, or something like that?

Originally posted by hank315
BTW. if this happens the m2v file is already written and closed so it should be OK, seems it's easier to encode a movie then to end a Windows program :)
Well, I'm a developer, so I have the Windows exception handler set to pop into the debugger. If I change it to invoke Dr. Watson, and configure that to not prompt, I could just let Rebuilder chug away and the occasional exceptions wouldn't cause it to wait for a response to me.

[ljpp]

I encoded Disney's classic Robin Hood using HC 0.13 and DVD-RB. This old movie has a lot of noise/grain in the original. The average bitrate for the movie after encoding was around 5500.

The resulting video differed visibly from the original. While it wasn't too bad looking, the noise and grain of the original was clearly smoothed out. There was some artefacting and macroblocks, a bit similar to the cartoon example above.

How could I tune HC to preserve the noise, which creates the illusion of a sharper image, better? I used profile "BEST" and "HC" matrix - should I try another matrix?

[springl]

@hank315
If I use JAWOR1CD matrix, logfile reports "matrix: BACH1"
If I use BACH1 matrix, logfile reports "matrix: JAWOR1CD"
Here HC_013
Greetings,
Springl

[hank315]

I tried putting a break-point on it, but it's called constantly - probably in a message loop.Think I already found it, will PM you about it.


If I use JAWOR1CD matrix, logfile reports "matrix: BACH1"
If I use BACH1 matrix, logfile reports "matrix: JAWOR1CD"will correct that, thanks for reporting it.

[dragongodz]

The average bitrate for the movie after encoding was around 5500.
I used profile "BEST" and "HC" matrix - should I try another matrix?
YES. for a higher bitrate such as that try just useing the default MPEG matrix.

[Yuri]

@ onesoul
I've seen that same frame on a comparison done by you, it must be haunting you eheh .
---------------------
A year ago or so, I found out that the tricky frames (http://sch-yuri.by.ru/zips/tarzan_49_tricky_frames.m2v) were very hard to be encoded properly by CCE even at high bitrate. Now I use them as testing material to check an encoder's engine, this time the wonderous HC.

[fozzieb]

Hi, I'm using avi2dvd 0.2.5 to convert my avi's to dvd. I use the HC encoder but it only allows me to choose built in matrices and i would like to use the Bdvd one, Is there a wat to do this?


Cheers

[freelock7]

I like the picture quality of this new release (smooth without grain).
Faster (twice compared to old versions).
Prediction seems to be good now.
Very good bitrate control & quant_.

[hank315]

@fozzieb
With the batch version you can use the *CUSTOMMATRIX command to use any matrix you want, see the pdf document.

@freelock
Thanks :)

[ljpp]

Thanks dragongodz,

Indeed, the 'MPEG' matrix improved the result. It is now pretty damn close to the original (which isn't artefact free either).

[hoenes]

Hi,
I've used HCenc yesterday for the second time, first time with ver. 0.13 beta. Unfortunately my PC hang before the second pass was finished, and I now tried to use the *RESTART option but with no success. HCbatch reads the *Options frome the .ini file except the *RESTART parameter, .dbs file is allready there, also renamed/copied it to HC.dbs

HCbatch starts the encoding immediately (1st pass, with the parameters from the HC.ini)
HCGUI doesn't follow the HC.ini parameters.

So *RESTART didn't work and an other strange thing is, that HCbatch converts the bitrate parameter very confuse, so .ini file *MAXBITRATE 9000000 become 910065 and *BITRATE 5000000 become 705032 in HCbatch.

Best Regards

hoenes

[petermarina]

What setting should I use for HC 0.13, to get the best image quality. I am using it in conjunction with DVD-Rebuilder 0.85pro. So far I am using the best setting and I still cant get a result that beats DVD-Shrink.... What am I doing wrong?

[DK]

"Improved speed" is a huge understatement

true

while Athlons increase ,while still big, is not as large.

they are still very impressive

i have tested hc 012 against 013 with a 120 min title:

hc012 - "normal" => 228 min
hc013 - "normal" => 195 min

hc012 -"best" => 348 min
hc013 -"best" => 230 min


athlon64 - 3000 - 1gb ram

++++++++++++++++++++++++++++++++++++

cce 270 => 131 min

[dragongodz]

they are still very impressive
huh? who said it wasnt ? the fact is the speed up is smaller on Athlons than on P4s. so people should be aware of that so person A doesnt start asking why they dont get the same speed increase as person B.

just as they should be aware that the higher the profile the larger the speed increase aswell, so Best gets a higher speed increase comparitivly compared to FAST profiles speed increase.

does imparting such information scare people or something ????

I still cant get a result that beats DVD-Shrink.... What am I doing wrong?
first you have to understand that if the orginal bitrate is fairly high and/or the reduction is smallish then a lot of frames with dvdshrink may be the originals and ones changed will only be done so a little. how anyone can expect an encoder to look better than using a lot of the original frames and some little modified ones is beyond me. try a comparison where a large amount of reduction on an already low bitrate source(such as a long movie or one with lots of extras) and you should see the difference.

[scraper]

Great program, this!

Just one question: There is no way to specify if a frame should become an I-frame (like "chapter=..." in ecl-files)?


I'm sorry... I should have read before posting... I know now it may come some day, but has no priority...
Keep up this excellent work! :D


greetz JP

[DK]

huh? who said it wasnt ?

nobody wasn't - neither you nor me

i just wanted to post some results because so far i didn't see anything alike

[hoenes]

OK I got the *RESTART now, I must be blind!

[johnnyquid]

@hank315

I have been trying out the new batch13 version. It is working fine most of the time but it does occasionally goes into an infinte loop when trying to fix VBV buffer underflows during pass 2. The finding and fixing counters just keep on going up with no progress in the number of frames processed. Unfortunately the problem is not repeatable. Rerunning the program using the same input files does not duplicate the problem. Find at the bottom of this post an example of a log file from a job which did not work one time but then did another. What is very strange is that when the encoding does work no underflows are found or corrected but when it does not work the infinite loop of finding and fixing underflows occurs with the exact same input files. Being a programer myself, I realize that this post is not very useful for trying to locate the problem (if it is indeed a problem with HC and not some problem with my hardware/software enviroment) but am posting again since it has happened more than once on different encodings. (If the problem is not due to my setup, memory overwriting or lack of variable initialization would be my guess and those problems can be pains to debug.) I am running Windows XP SP2 on an Anthlon XP 2500 machine.

@all

Has anybody else seen this problem?


Logfile is below:


-------------------------------------------
| HCbatch - MPEG2 encoder - rel. 0.13 beta |
-------------------------------------------

input: g:\rbtemp\d2vavs\v01000000001001.avs
output: g:\rbtemp\d2vavs\v01000000001001.m2v

--------------------
| encoder settings |
--------------------

profile: GOOD
frames: 1 8989
framerate: 23.98
aspect ratio: 16:9
bitrate Kb/s: 3492
max. bitrate Kb/s: 9000
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 9
scan method: ZIGZAG
time code: 0 0 0 0
CPU: MMX/SSE
matrix: MPEG

--------------------
| source stats |
--------------------

nr. of frames in source: 8989
width*height: 720*480
fps: 23.98
nr. of frames to encode: 8989
frames to encode: 1 - 8989

---------------------
| encoding - pass 1 |
---------------------

pass 1 encoding time: 0:06:22 (382 s)
average fps: 23.5

--------------------------------
| encoding - intermediate pass |
--------------------------------

bitrate set to: 3492000 b/s
est. outfile length: 159816 kB
intermediate encoding time: 0.0 s

---------------------
| encoding - pass 2 |
---------------------

pass 2 encoding time: 0:04:04 (244 s)
average fps: 36.9

------------------
| encoding stats |
------------------

total encoding time: 0:10:26 (626 s)

intra matrix used
8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 37
19 22 26 27 29 34 34 38
22 22 26 27 29 34 37 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 58
26 27 29 34 38 46 56 69
27 29 35 38 46 56 69 83

non-intra matrix used
16 17 18 19 20 21 22 23
17 18 19 20 21 22 23 24
18 19 20 21 22 23 24 25
19 20 21 22 23 24 26 27
20 21 22 23 25 26 27 28
21 22 23 24 26 27 28 30
22 23 24 26 27 28 30 31
23 24 25 27 28 30 31 33

nr. of gops: 661
nr. of frames: 8989
nr. of I-frames: 661
nr. of P-frames: 2804
nr. of B-frames: 5524
average quant (non linear): 6.713
VBV underflows detected: 0
VBV underflows fixed: 0
minimum bitrate: 146
maximum bitrate: 7866
average bitrate: 3492

[digitalman]

I get an error when selecting the KVCD-NOTCH matrix, that it is an invalid matrix. Otherwise this looks to be a promising alternative to QuEnc.

[DoctorRad]

Originally posted by ljpp
"Improved speed" is a huge understatement. On a P4 HT 2.66GHz the encoding speed has roughly doubled since the 0.12, and HC is now 4-5 times faster than QuEnc (profile BEST vs. QuEnc High Quality+Trellis).

I never expected such a speed bump! Awesome work.

We try our best... at least I assume I'm 'the dr.' mentioned in the help file... and there should be more to come. Hank is doing a superb job of coding on this one, I'm merely feeding him fast motion estimation ideas, the ones I never had any time to code up.

Cheers,

Dr. Matt...

[dragongodz]

hank315 asked me not to say the things we have and still do talk about, lets just say they are wide and varied including things like ME and RC etc etc etc. ;)

[lunario]

great encoder hank but everytime that i use hcenc it gives me a memory error at the end of the encode (just like in cce 2.70 ) i use avi2dvd with hcenc

[hank315]

@lunario
This should be solved in the next version which will be out very soon.

[hank315]

New release: HC014

- improvement of the encoding engine
- added *CQ_MAXBITRATE command, CQ encodes will now be DVD-compliant
- some other bugs fixed

HC014 will be in the download section soon but also here:

http://hank315.dyndns.org/HC_014.zip

[lunario]

great :) i will test it later

thanks again for this great encoder

[Frameserver]

Originally posted by hoenes
Hi,
I've used HCenc yesterday for the second time, first time with ver. 0.13 beta. Unfortunately my PC hang before the second pass was finished, and I now tried to use the *RESTART option but with no success. HCbatch reads the *Options frome the .ini file except the *RESTART parameter, .dbs file is allready there, also renamed/copied it to HC.dbs

HCbatch starts the encoding immediately (1st pass, with the parameters from the HC.ini)
HCGUI doesn't follow the HC.ini parameters.

So *RESTART didn't work and an other strange thing is, that HCbatch converts the bitrate parameter very confuse, so .ini file *MAXBITRATE 9000000 become 910065 and *BITRATE 5000000 become 705032 in HCbatch.

Best Regards

hoenes

hi hoenes,
hank315 changed the values for the bitrate (in hc_012 I guess) to Kbits and this caused the strange behaviour. So if You use 5000 instead of 5000000 anything should be ok.

@ hank315
impressive work!
The undersizing seemes to be fixed now.
Keep on coding!

Btw I remember Your "Fortran Compiler trouble" may this is interesting for You.

April 20, 2005
GCC 4.0.0 has been released.
GCC, the GNU Compiler Collection, includes front ends for C, C++, Objective-C, Fortran, Java, and Ada, as well as libraries for these languages (libstdc++, libgcj,...).

It is now equiped with a Fortran 95 compiler front end.

http://gcc.gnu.org/fortran/

http://gcc.gnu.org/

frameserver

[FredThompson]

Please allow larger GOPs.

There's work on improving TyTool (TiVo-centric MPEG2 editor) by changing the encoder from mpeg2enc to something else. QuEnc is a possibility. HC should also be a candidate, probably more so, givent he amount of activity in devloping it.

Some TiVo source has very long GOPs. Without getting into too much detail, there are technical reasons to keep long GOPs.

[lunario]

hank i´ve tested the new version and it gives same error at the end ..
same memory error the only encoders that give the error so far are hcenc end cce 2.70 (´ve tested with cce 2.67 and procoder and they don´t give the error.

the only bad thing on this is that the pc wont shutdown because of that error, when i click ok the rest of the job (muxing and authoring ) get´ts done

[gozo200x]

http://img.photobucket.com/albums/v694/gozo200x/hc.gif

I've been trying to run HC since version 0.12 without success. Also with the new 0.14 I get this error whenever I try to start encoding - be it with the standalone version or via DVD Rebuilder (0.86 pro).

Unfortunately I'm not a programmer and don't know what information could be useful for you.

My System:
AMD 64 3200+
1 GB RAM
WinXP Home SP2

Please tell me what other information I could provide, I'd love to give HC a try.

Thanks,
gozo

[lunario]

that is the same memory error that i have but in here only in the end of the encode

[hank315]

@lunario
Could you please post the exact error message.

[lamster]

Originally posted by gozo200x
http://img.photobucket.com/albums/v694/gozo200x/hc.gif

I've been trying to run HC since version 0.12 without success. Also with the new 0.14 I get this error whenever I try to start encoding - be it with the standalone version or via DVD Rebuilder (0.86 pro).

Unfortunately I'm not a programmer and don't know what information could be useful for you.
Curious - the error message says to press Cancel to debug; I only see that if there's a debugger installed (e.g., if you have Visual Studio).

One possible approach would be to select Cancel, see what loads, and post the assembler code around the point of the exception, along with the call stack.

Another approach would be to restore the default exception handler (DRWTSN32 -I) and provide the resulting Dr. Watson log.

[Malow]

dear hank315, i guess that the same problems of lunario is happening with me... this happens on all winxp sp1 machines where i work, but "apparently" no problems on winxp sp2 machines...

the screenshot:

http://www.alphapro.com.br/hcerror.jpg

[lunario]

Originally posted by Malow
dear hank315, i guess that the same problems of lunario is happening with me... this happens on all winxp sp1 machines where i work, but "apparently" no problems on winxp sp2 machines...

the screenshot:

http://www.alphapro.com.br/hcerror.jpg


yes that is the error but i have XP with SP2 (and last updates) so that is not only with machines with sp1

my rig

Pentium 4 2.6HT @3ghz
1GB Ram
XP media center 2005 with SP2

when i use the new cce gives me exactly the same error

[gozo200x]

Originally posted by lamster
[B]Curious - the error message says to press Cancel to debug; I only see that if there's a debugger installed (e.g., if you have Visual Studio).

I had Visual Basic installed a long time ago to recompile something I did even a far longer time ago. After uninstall the option to debug somehow remained on my system, but If I press OK to debug there's an error message that nothing to debug could be found. I really am NO programmer ;) What I did back then was kiddie work.

[Malow]

Originally posted by lunario
[B]yes that is the error but i have XP with SP2 (and last updates) so that is not only with machines with sp1

the sp2 in my home gives the same problems... but, in the machines that work, it have also these updates:

http://ryanvm.msfn.org/updatepack.html

[lamster]

Originally posted by gozo200x
If I press OK to debug there's an error message that nothing to debug could be found.
Try entering (from a command prompt window):
DrWtsn32 -I

This will install Dr. Watson as the default debugger.

[lunario]

Originally posted by lamster
Try entering (from a command prompt window):
DrWtsn32 -I

This will install Dr. Watson as the default debugger.

no debug option for me only the same error that mallow has

[lamster]

After executing "drwtsn32 -I" to install it, you can run it without the -I option to see / update the settings. In particular, you can see what the "Log File Path" is set to, and look for DrW*.log file there (or anywhere on your system if not set - the default location varies depending on which version of Windows you're running).

[gozo200x]

I found what causes the problem.
I got an AMD64, remember? and it has this NX extension. Code execution prevention or whatever it is called in English. Now if I add HC to the list of programs for which NOT to use this prevention thingy it doesn't crash anymore.
HC is in good company with WaveLab on this by the way ;)

now it only crashes upon exit as described above. but drwatason doesn't spring into action, no log or user.dmp is written.

[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

[ukb008]

Thanks, artoor.

Regards.

[Prodater64]

Can CQ_MAXBITRATE option be selected from command line?

[hank315]

Can CQ_MAXBITRATE option be selected from command line?No, that's not possible ATM.

[Rumbah]

Hi!

It would be great if you could set the VBV size because it is needed as I'm writing a plugin for Cuttermaran (www.cuttermaran.de) to support HCEnc. For that project I also wanted to know if HCEnc sets the SequenceDispayExtension (Because Cuttermaran only encodes small pieces of the original Stream, the author said it is important to set it if it was used in the original stream, and a SEC would be MPEG compliant, but not DVD compliant).

[ljpp]

@hank
Uh... always hard to answer this, let's say when it's finished

Dammit Hank - now I can't do any backups because I know that a better version is lurking around the corner :scared:.

I have used HC a lot recently, and it seems constantly to deliver very good results with normal natural source DVD backups. Can't wait for the next version.

p.s. Check your PM Hank!

[artoor]

I'm waiting for new version as well... it looks as if Hank teaches us patience ;)
But seriously - can You tell us (more or less) when the newest version will be release??

Regards

[dragongodz]

can You tell us (more or less) when the newest version will be release??
considering some of the things hank315 is working on it wont be probably released tommorow... or the day after that. :D
seriously though i have talked to him and know some of the things that he is working on and they take time, pure and simple.

and before anyone askes, NO I CANT TELL YOU WHAT HE IS WORKING ON. sorry but he said he will come around and put me through a grinder if i did. ;)

[artoor]

I didn't speak with Hank but I think that I know what He is working on :D (have a guess) It can be 2 important things ;) If I predict well I'll tell You after the newest version will be relesed :)
I'm waiting impatiently

[hank315]

but he said he will come around and put me through a grinder if i did.:) Did I really say that ?
Would never do such a thing, you're just living too far away :D

@ljpp
Already read it, will answer it ASAP.

Next version will still take some time to finish, for the things I want to implement the old database structure wasn't flexible enough.
That part is now completely rewritten, also the database is now compressed, size will be about 30% of the old one.
That was just alot of stupid programming and testing...

Now just see if the ideas I have really work and that again is alot of programming and testing.

[Easy123]

Just tested the Encoder together with DVD Rebuilder and I was stunned.. @Hank: great job done! Thx for this Software... But if I want to use this software as "standalone" is there a possibility to tell the Encoder which frame has to be coded as an I-Frame per commandline (for Chapters)????

[artoor]

Ok... I'll tell You something... As far as I'm concerned I'm waiting for some day when I will see the newest HC version and on the changelog.txt there will be write "- support for Hyperthreading/multiple processor PC's" :D I dream of this ;) I hope that I can have dream like this at last it is a part of "ToDo list"... Am I right?? :dreamer:

Regards

[dragongodz]

:) Did I really say that ?
Would never do such a thing, you're just living too far away :D
well you asked me not to say anything about the things being worked on and planned etc. to me thats close enough as people who know me will know that i dont divulge things when specifically asked not to. :D
as for distance, ye just a little far away. ;)

[ilpippo80]

Originally posted by Easy123
...But if I want to use this software as "standalone" is there a possibility to tell the Encoder which frame has to be coded as an I-Frame per commandline (for Chapters)????

Me too waiting for the possibility to force I-frames, I think that RB is a very good program but I'd prefer to use directly the gui version of hc...
If I remember well, some time ago Hank said that it wasn't urgent and it will be done sooner or later... but I hope that it will come sooner!:p

BTW, thanks for your great work, Hank!:D

[jeanl]

I have started to use HC extensively for my interlaced DV -> DVD conversions, and so far, I'm really happy with the results, both in terms of quality and encoding speed.
I found however, that it was very tedious to have to write avi scripts for each avi file I needed to encode (I usually break my DV footage into many small avi files which are easier to edit and manipulate, and I want to encode them independently to make DVD chaptering easier).

To help with that task, I wrote a tiny application that can scan a folder for all the avi files, and generates a bunch of avi scripts in a "AVIScripts" subdirectory, along with a .bat file that contains the HCBatch commands.

Typically, you would start the app, drag/drop one of the avi files into it, and press "Create Batch". The app assumes there's a HC.ini file that contains your encoding setup. There's a button to edit that file too.

Here's a screenshot.
http://img281.echo.cx/img281/5259/test5kb.png (http://www.imageshack.us)
Anybody who's interested can download the application here (http://jean.laroche.free.fr/Binaries/HCBatchMaker1.0.zip).

If there's enough interest, I'll start a new thread to discuss improvements, but at this point I'm just offering this as a freebie, just in case somebody might find it useful.

jeanl

[jdobbs]

I like to use segmented AVI files with my DV material... I do a lot of encoding of DV to DVD.

[jeanl]

Originally posted by jdobbs
I like to use segmented AVI files with my DV material... I do a lot of encoding of DV to DVD.
Out of curiosity jdobbs, which encoder do you use? I'm assuming your DV material is interlaced, right? What bitrate do you consider appropriate?

I'm still struggling to decide how low a bitrate I should go for, considering this is for archiving but also for viewing. I currently use at least 5500Mb/s.
jeanl

[jdobbs]

I usually encode DV using OPV (CCE) so I can aim for a Q factor as opposed to a bitrate. The only time I wouldn't would be when I'm worried about getting it to fit. I normally set the maximum bitrate to 9000.

Contrary to what I've heard from some others, I am very satisfied with the interlaced output I get from CCE, especially the newer versions. I am considering switching to HC, though... as it seems to handle interlaced sources very well -- and Hank315 has added a (maximum) bitrate controlled OPV mode now.

[Encoder Master]

But the interlaced quality of HCE isn't very well at the moment. Only if you deinterlace your material before giving it to HCE.

How good are your interlaced encodes with HCE?

[jdobbs]

What's wrong with the output from HC -- I haven't noticed any problems?

[Encoder Master]

I never tested it before because my sources are always progressive and so I've only very good results. But in the last time I've see some test pics of QuEnc and HCE with interlaced sources and the QuEnc gives in this test much more quality. The pic of HCE looks not so good like progressive. Does anybody noticed such problems with interlaced sources?
Many people say it that HCE have problems with interlaced sources.:(

[Archimedes]

I’ve made a lot of tests with different encoders and interlaced sources. Subjective and objective tests. The objective tests was done with Fritz Framalyzer.

One of the testclip, i used, is located at
http://www.tecoltd.com/enctest/enctest.htm (test.avi, interlaced).

As a result, the software calculate an average euclidean distance in RGB. Euclidean distance in RGB means the average distance between an encoded pixel and an original pixel in the RGB color space. Lower Values means better quality.


Here are some results:

Canopus Procoder Express
Highest Quality, VBR, 2 pass, 3500, 6500, 8500, DC 8
Euclidean distance in RGB: 7,3347

QuEnc
VBR, 2 pass, 6500, 8500, DC 10
Euclidean distance in RGB: 7,5422

HC
VBR, 2 pass, 6500, 8500, DC 8
Euclidean distance in RGB: 7,8581

FreeEnc
VBR, 2 pass, 3500, 6500, 8500
Euclidean distance in RGB: 8,0893

Cinema Craft Encoder Basic
VBR, 2 pass, 3500, 6500, 8500, DC 8
Euclidean distance in RGB: 8,2326

TMPGEnc
High Quality, VBR, 2 pass, 3500, 6500, 8000, DC 10
Euclidean distance in RGB: 8,7692


The same order comes out with subjective tests. In all my tests, the Procoder produces the best results with interlaced sources. QuEnc produces very good results on interlaced sources also (but it's also the slowest encoder of all).

Josef

[onesoul]

Why did you use dc 10 on quenc and tmpeg?

[Archimedes]

The best result with QuEnc was the setting with DC 10. I didn’t tried many other settings with TMPGEnc, because i saw no chance to get much better results.

Another setting was:

TMPGEnc
Without B frames, High Quality, VBR, 2 pass, 3500, 6500, 8000, DC 9
Euclidean distance in RGB: 8,3593

Josef

[zilexa]

I am creating 3 dvds with each 8 episodes of Lost (source is Xvid/mp3, 350MB,42 minutes, have chosen to do 8 episodes per dvd since I didn't see quality difference with 6 episodes on one dvd with CCE SP 2.70, 4 pass).

Now I am considering switching to a free encoder... since I am using DIKO I was very interested in FreeEnc, but after reading lots of tests and forums... I cannot decide between FreeEnc and HC.

It seems HC and QuEnc are at the same level, QuEnc is able to produce better quality sometimes, but so is HC.... Unfortunately there arent any tests between HC and FreeEnc! That's why I cannot decide.

since these encodings require low bitrates.. and VMesquita has optimized his FreeEnc for low bitrates.. I suppose FreeEnc is the better choice for now..
any comments?

[Encoder Master]

Without B frames

This settings aren't good. The best quality you get with 1 B-Frames in TMPGEnc and also the best compression but this isn't DVD-compliant.

[Mug Funky]

1 b-frame is compliant, isn't it? otherwise scene-detection and autogopping wouldn't work...

[JohnG]

Originally posted by zilexa
I am creating 3 dvds with each 8 episodes of Lost (source is Xvid/mp3, 350MB,42 minutes, have chosen to do 8 episodes per dvd since I didn't see quality difference with 6 episodes on one dvd with CCE SP 2.70, 4 pass).

Now I am considering switching to a free encoder... since I am using DIKO I was very interested in FreeEnc, but after reading lots of tests and forums... I cannot decide between FreeEnc and HC.

It seems HC and QuEnc are at the same level, QuEnc is able to produce better quality sometimes, but so is HC.... Unfortunately there arent any tests between HC and FreeEnc! That's why I cannot decide.

since these encodings require low bitrates.. and VMesquita has optimized his FreeEnc for low bitrates.. I suppose FreeEnc is the better choice for now..
any comments?

HC is better quality than FreeEnc. I use those two encoders almost exclusively. For anything other than a full backup, I use the BDVD matrix in both, and HC is consistently better (kbps range 1500-2500 is where I usually fall for multiple movie, captures, etc. on one DVD) It's simple, when I don't care about the quality difference and want pure speed, FreeEnc is the choice. The quality for HC however, is as good or better than ANY encoder out there (free or otherwise). I have used Procoder, TMPGEnc, CCE etc. When it comes to reliabililty and quality it can't be beat. It's just nice to have all the available choices :D

[Encoder Master]

@Mug Funky

1 b-frame is compliant, isn't it? otherwise scene-detection and autogopping wouldn't work...

Oh, really. I only used 1-B Frame for my ONE-CD-Encode and a very low bitrate to improve quality and save some bits. I don't know how good is the quality on other encoders but with TMPGEnc I got more quality.

I have used Procoder

This make me happy because this is the only encoder which I don't have and so I can't test the quality.:)

[Fl0ppy]

I'm new using HC, but the quality and speed are amazing!! I have a cpu with HT.
It's very good with low bitrate like 1500 etc...in CVD :D

Can somebody try this new matrix for HC?

http://rapidshare.de/files/1880244/ivcd_1_1_0.zip.html

cu.:D

[LigH]

@ Fl0ppy:

Accordiny to my "Custom Quantization Matrix Cross-Compare" (CQMXComp), your iVCD matrix is very similar to "Auto-Q2" by Avalon. (The used similarity metric is a combined Root Mean Square over both intra and inter matrices.)

CQMXComp is a CLI tool, and included in

http://www.ligh.de/software/qmatrix.zip

Usage: ?:\*> CQMXComp *.cqm [...] [> output.txt]

Values near 0.0 mean "not very similar", values near 1.0 mean "very similar", exactly 1.0 means "the two matrices are identical".

*.cqm files are the same plain binary matrix files as used in XviD (*.xcm) or ffdshow/ffvfw (*.qmatrix).

[Encoder Master]

Oh, this is a nice tool. I will test it. Very useful. Thank you LigH.;)

[Fl0ppy]

@Ligh
Thanks for the tool, it's nice. And now i have more than 60 matrices to test it! :rolleyes: It' s lot of matrix.

Wich it's better? The original of mpeg? The tmpgenc..? I think depends of the person and the film.

cu.

[LigH]

Originally posted by Fl0ppy
Wich it's better? ... I think depends of the person and the film.
Of course! It always depends heavily on the subjective preferences, the material, and the target. Can you guess why one matrix was called "28 Days After"? - It was optimized for personal needs on this special movie. Several matrices even had a whole paragraph in a readme which described the exact circumstance they were made for.

There are matrices which are useful for high quality, but require a lot more bitrate to achieve it - in my CQME, you can see that they are rather flat/low. Other matrices can save bitrate, but will reduce details - they raise more quickly, look like mountains. Around half the matrices were made for MPEG-1/2 encoders, their authors may not even know if they can be recommended for MPEG-4 encoders at all!

[zilog jones]

HC (using the GUI) locks up on loading AVS files on my PC (Win2k), unless I turn off the "resident shield" on my anti-virus program (Grisoft AVG Free).

Anyone else having problems with the GUI freezing should try turning off their anti-virus too. Does anyone know why this is happening?

[jeanl]

I think this was mentioned before on this thread or a previous one, the fact that HC froze on win2k, but I don't remember reading about the anti-virus being responsible for that!
jeanl

[doxville]

It was mentioned some time ago by me, but I don't think anyone took notice (scroll down a little in the thread): http://forum.doom9.org/showthread.php?s=&threadid=88888&postid=615630
Sometimes, even when I switched off the AV-guard, the GUI version locks up in the FIRST try, but when I close HC and open it a SECOND time, it usually works. Though i see it more like a 'cosmetical' problem, because it IS possible to use the GUI with Win2K, it would be really nice, if there was a solution to this bug...

[zilog jones]

Yes, actually, it doesn't seem to work every time first time for either when I turn off my anti-virus program. I find it works after a while of me randomly turning off a few other programs (like my Epson printer taskbar dealy), but I don't know if that's actually helping.

[jeanl]

The easiest way to get to the bottom of that would be for Hank315 to replicate the problem which apparently he can't. Next way is to create a version that outputs debugging info in a file so you can narrow the point where bad things happen. It's a bit time consuming because you have to make several tests back and forth before you can pinpoint exactly the offending command. Kind of a binary search type of approach!
I would be willing to help (I have win2K on one machine here, and it HC crashes no matter what) by testing "debug" apps... But Hank315 would have to create that first...
jeanl

[zilog jones]

I seem to be having problems with it making videos correctly too. I'm trying to make it encode an AVS file using ImageSource to make a sequence of test cards, but I'm just getting a diagonal mess. I'll do some more investigating some other time - I really should be going to bed now!

[peteag]

which is the best matrix for content of 1500-2000 at PAL resolution (high motion, sometimes heavy film-damage)?????

[LigH]

2 Mbps, heavy motion, and full resolution? You must be joking... :rolleyes:

Which matrix... In this case: Maybe the one of the Wachowski Bros.! ;)

[peteag]

No! :)

my thread (http://forum.doom9.org/showthread.php?s=&threadid=94298)

[LigH]

Then, I'd almost call it "crossposting", because your topic does not cover the HC encoder development too much...

Let's talk that question there, I'd suggest. :cool:

[peteag]

i heard hc seems to be the best in very low bitrates - so i ask you whats the best matrix for low bitrates at hc? this could be a good question because of including matrices into a new build ... isn't it?

[Guest]

Originally posted by peteag
whats the best matrix for low bitrates According to forum rule 12, there is no best and you should please not ask for it. Thank you.

[onesoul]

Originally posted by peteag
which is the best matrix for content of 1500-2000 at PAL resolution (high motion, sometimes heavy film-damage)????? Maybe you should try xvid or other mpeg4 encoder instead...

[LigH]

(@ onesoul: Your avatar looks familiar... The "killer rabbit" by Monty Python? :D)
__

@ peteag:

In general, for low bitrate encoding, you would use matrices which have rather high values (compared to the default MPEG matrix), and values that raise rather quickly from the top left corner towards the right and lover edge. Those matrices will reduce details to avoid too much block/ring artifacts. Already built-in are e.g.: QLB, BACH1, Jawor, AutoQ2.

In contrast, high quality matrices have values which raise slower than those of the MPEG matrix, or even stay below them. They will restore more detail, but will require more bitrate to achieve that goal. Already built-in are e.g.: the 3 HVS.

(HC and NOTCH are hard to decide for me ...)

Look for my thread about my "Custom Quantization Matrix Editor" CQME. You will find there an archive of many collected quantization matrices. Use them for your own experiments. And always be aware: The possible quality of the quantization result is a (multiplication) product of a per-block quantization factor, and the per-frequency-component matrix entry. Smaller products give better quality for those frequency components, but require more bitrate. As long as you don't understand this concept, you won't understand your own question about the "best matrix"!

[onesoul]

@ LigH

Good guess! Yep, "That rabbit's dynamite!" :D

[Amnon82]

@ Fl0ppy:

Accordiny to my "Custom Quantization Matrix Cross-Compare" (CQMXComp), your iVCD matrix is very similar to "Auto-Q2" by Avalon. (The used similarity metric is a combined Root Mean Square over both intra and inter matrices.)

CQMXComp is a CLI tool, and included in

http://www.ligh.de/software/qmatrix.zip

Usage: ?:\*> CQMXComp *.cqm [...] [> output.txt]

Values near 0.0 mean "not very similar", values near 1.0 mean "very similar", exactly 1.0 means "the two matrices are identical".

*.cqm files are the same plain binary matrix files as used in XviD (*.xcm) or ffdshow/ffvfw (*.qmatrix).

@all: Sorry for this (I think) offtopic post.

@Fl0ppy:

Old Times come back. Avalon was my nic at www.doom9.de. Here I used Amnon82. Greetings to LigH ;)

AUTO-Q1 (AVAMAT6/CYMAT 1.1) and AUTO-Q2 (CYMAT 1.2) are my matrices. You can find them in my programs QCCE-CYBEREDITION 1.12 (http://forum.doom9.org/showthread.php?s=&threadid=77825&highlight=QCCE) and in Auto(C)Q 1.5.3 (http://www.autoq.fx.to).

As I remember right, You wanted me once to add Your matrices called PVCD into QCCE-CE. Here the matrices to remember:

PVCD 17d

8 8 15 18 24 28 35 43
16 17 18 21 27 30 35 46
20 18 20 24 27 33 36 50
21 24 28 30 34 38 40 45
24 30 27 34 38 39 46 60
26 30 35 40 45 50 60 70
34 39 41 46 52 61 70 80
30 41 47 48 54 67 80 84

16 18 20 22 23 27 32 40
18 20 22 24 26 32 36 42
20 22 24 26 33 38 42 44
22 24 26 34 38 44 44 46
23 26 33 38 44 44 46 48
27 32 38 42 44 46 48 50
32 36 42 44 48 48 50 52
40 42 44 46 48 50 52 58

PVCD 18a

8 9 16 18 25 28 33 44
15 16 17 20 27 29 34 47
19 19 21 25 28 34 37 48
22 27 30 30 34 37 38 50
24 32 30 35 39 40 48 58
25 32 37 42 46 50 58 68
35 37 41 45 50 56 66 79
40 39 47 48 54 66 79 83

16 18 20 22 23 27 32 40
18 20 22 24 26 32 36 42
20 22 24 26 33 38 42 44
22 24 26 34 38 42 44 46
23 26 33 38 42 44 46 48
27 32 38 42 44 46 48 50
32 36 42 44 48 48 50 52
40 42 44 46 48 50 52 58

and Your newest I found today on Your Homepage (http://usuarios.lycos.es/pvcd/html/) (24e):

8 8 15 18 24 28 35 43
16 17 18 21 27 30 35 46
20 18 20 24 27 33 36 50
21 24 28 30 34 38 40 45
24 30 27 34 38 39 46 60
26 30 35 40 45 50 60 70
34 39 41 46 52 61 70 80
39 41 47 48 54 67 80 84

16 18 20 22 24 27 32 40
18 21 22 24 26 32 36 42
21 23 24 26 35 38 42 44
23 24 26 32 38 44 44 46
25 26 31 36 44 45 46 48
27 34 37 42 46 46 48 50
31 36 42 43 48 50 52 54
39 39 43 46 49 52 54 57

... are You realy shure what You're doing ... :confused:

[lbecque]

I tried 0.14 beta version on a MPEG2 file that I ran through avisynth, cropped adn resized before frameserving to HC.
Sometimes HC would just exit in the middle of its second pass with no warning or error message.
If I used the option to restart the 2nd pass it would finish.
What's that all about???
Am I doing something wrong?

The .avs script was running through DirectShowSource.
I haven't retried it with DGDecode.dll and mpeg2source yet.

[Prodater64]

HCBatch_0.14 doesn't show accurate info in main window (neither in log file).
As example, source total frames (155731) doesn't match processed ones (175028). I see that in CQ processing mode.

http://img249.echo.cx/img249/1917/hc3wa.png

Thanks to ImageShack for Free Image Hosting (http://www.imageshack.us)

[feedback]

@JohnG
I use the BDVD matrix in both, and HC is consistently better (kbps range 1500-2500

I used HC and tried the BDVD matrix, however the resulting DVD would not play
on one of my standalone players. Do you have this problem and if not how
did you fix it?

Regards,:)

[hank315]

HCBatch_0.14 doesn't show accurate info in main window (neither in log file).
As example, source total frames (155731) doesn't match processed ones (175028). I see that in CQ processing mode.Just found the error and fixed it.
The source total frames should be correct.
Thanks for reporting it.

[Encoder Master]

I saw the correct total frames only in the log file. :)

I used HC and tried the BDVD matrix, however the resulting DVD would not play

I heard of this problem. But I can't believe it because I never hear of imcompatibility with a q- matrix.
Do you use another matrixes of HC which also deletes few details like HC or perhaps autoQ matrix?

[PJones2101]

Just wanted to say thanx to Nic for a GREAT compressor. Your hard work is well-appreciated. I can compress directly from VOB files to a m2v stream at 720x576 (PAL Of course) at a BitRate of 1600 Ave and Max of 3000 using HVXBest. Average file size for 90 min is a about +-1.1gig to 1.2gig. Add the ac3 and a final DVD of 1.4-1.5 Gig. Absolutely amazing work. And the quality is still good enough to watch on PC. I remember someone asking if you were going to make a DLL out of the encoder, but I can't remember seeing an answer.
Once again, thanks for the great work ....... Keep it uphttp://forum.doom9.org/newreply.php?do=newreply&noquote=1&p=661971#
http://forum.doom9.org/newreply.php?do=newreply&noquote=1&p=661971#

[onesoul]

@ PJones2101

You are a bit confused aren't you?

And what kind of link is that? lol

[jeanl]

I think PJones2101 meant to post in the Quenc thread... But go easy on him, that was his first post! :D
I'm sure nick appreciates just the same!
jeanl

[PJones2101]

Sorry Guys, I meant Hank, I has been awake working for 48 straight hours so please forgive.

[PJones2101]

Thanks JeanL - Appreciate the assist.

[jeanl]

Sorry Guys, I meant Hank, I has been awake working for 48 straight hours so please forgive.
48 straight hours? Are you out of your mind?! :D I hope it's fun at least!
jeanl

[Prodater64]

CQ OPV encoding with prediction.

HC-Qmatic (http://forum.doom9.org/showthread.php?t=95428)

[peteag]

what's OPV?

[onesoul]

One Pass Variable bitrate.

[EpheMeroN]

Is it normal to get some VBV Underflows during an encode using HC Encoder v0.14 Beta? I got 27 during my last 2-pass encode using 6470 avg and 8000 max bitrate. I didn't worry too much though because it said that all 27 were fixed. I did notice that I got more underflows though when I used LimitedSharpen in my script.

[ljpp]

Has anyone tried encoding the AC/DC - Family Jewels (PAL) DVD with HC?

I think it could be considered as a problem case for HC, as the quality reduction seems worse than I would have expected.

This is most visible in the last song of Disc 2 - "Are You Ready". Like most AC/DC videos, it consists of shaky camera, audience clapping hands, and some colorful light effects. Especially through the blue lighted sequences, shots of the band members and audience I got pretty bad/rough blockyness. This is clearly visible with the 29" 4:3 Sony TV. Now the source ain't perfect either - crap in crap out, as they say. But still this is the worst case I've seen so far with HC.

I applied MenuShrink and then encoded with DVD-RB .93 Free+HC .14. The source is interlaced, reduction is around 70% and overall bitrates above 5000kbps for both discs.

Any tune-up ideas?

[hank315]

Any tune-up ideas?Yes, the next release...
It should do a better job with these kind of sources.

Is it normal to get some VBV Underflows during an encode using HC Encoder v0.14 Beta? I got 27 during my last 2-pass encode using 6470 avg and 8000 max bitrate. The average bitrate is already pretty high so yes this can happen.
As long as the muxing program doesn't complain about buffer underruns it should be OK.

[genesabas]

Hello,

To hank315, When the next version of HC?


Thanks for your work.

[ilpippo80]

And with which improvements?
I think we're all so curious! ;)
Thanks again!
Pippo

[LigH]

One thing that may be whistle-blown:

Loading AviSynth scripts under Windows 2000 shall be fixed now.

[jeanl]

hi hi hi, LigH, couldn't resist huh! ;)
jeanl

[LigH]

Why not. It took a while, and several test builds (mainly for katjarella and me), but the last one worked reliably in several test cases.

[hank315]

When the next version of HC?Next release is almost finished.
And with which improvements?- compressed database, size will be 30% of the old one
- improved motion estimation, means better quality especially for high motion scenes
- biased compression curve
- shutdown command

And yes, the W2K Avisynth issue seems to be solved thanks to numerous tests done by Katjarella, LigH and Jeanl.

[dbloom]

- compressed database, size will be 30% of the old one
Speaking of which, what kind of format is the database in? I'm thinking of revising my mpeg-2 utility (http://davidbloom.home.mchsi.com/readme/readme.html) to use HC instead of TMPG (tmpg, being GUI only, requires a lot of complicated repetitive user interaction to get things to work right). I would need to read and change the encoding bitrates HC has for various sections of the video, based upon the framerate they will be slowed down/speeded up to.

If this would be practical with HC, that would be wonderful, because TMPGEnc is getting kind of messy for this.

[STR]

To hank315,

just wondering if there could be a 3 pass conversion

P.S.
Awesome tool ;-))

[ukb008]

I don't know. A tool that needs more than 2 passes has to have some drags in the code. Or that's what I always thought.

Regards.

[Trahald]

I dont know if its been mentioned, but are there plans to support chapter setting? ie setting a i-frame (kindof a force scene change) at given frames of an encode based on a list. i have written support for hcenc in an app (it uses trims to split by chapters) but generally being able to encode in one chunk would be desirable.

[Hostile_Monk]

Thanks for all the hard work Hank, I've been using this encoder a lot lately. Any word on v.15b? :)

[hank315]

About HC015, actually it's finished.
ATM it's being tested by some people (I hope :) )
If the tests run OK it will be released in a few days.

@dbloom
The database as it is now is not record based anymore, it's just a continuous compressed bitstream.

@STR
HC will always be a 2 pass encoder.

@Trahald
Chapters (forced I-frames with closed GOPS) will be in the next version I think.
Tried to implement it but still have some problems to get it to work with the scene change detection.

[Trahald]

@hank315
great to hear!

[hank315]

New release: HC015

- better motion estimation
- compressed database
- added *BIAS command to tweak the compression curve
- added *SHUTDOWN command
- as usual some bugs fixed

Get it at http://hank315.dyndns.org/HC_015.zip

Will also be in the download section soon.

[LigH]

Thank you, hank! That's a fine birthday gift for me today! ;)

[hank315]

@LigH
Congratulations, 30, a real milestone... Already a long time ago for me :)

And thanks again for testing to get the W2K problem solved.
Thanks also go to Katjarella and Jeanl for this.

[lunario]

thanks you for this version hank :)

about bias settings for best quality what do you thing is the most used setting ? RB uses 25 in cce by default ( i think) is that a good setting in HC ?

hc gui default is 0

any help on this would be apreciated

[feedback]

I know the CCE guys don't like to hear it but I use your encoder almost exclusively.

HC is just as good in quality output as CCE IMHO.

I do test different Matrices and get mixed results of course (some not made for mpeg2). I use HC in DVD-RB Pro. and the Newer Rockas Rebuilder Editor v.0.1.8 which now directly imports (don't have to convert to text files anymore) .CQM and .XCM Matrices that you can use in DVD Rebuilder Pro v.93.2

Regards,:)

P.S. I like LigH's Custom Quant. Matrix Editor 1.0, also.

[jdobbs]

Great job, as usual.

:D

[hank315]

@lunario
Hard to say what the "best" setting is, it will depend on the source etc.
Did some test encodings with bias 30 which looked pretty good.

@jdobbs
Thanks...

Some additional info:
The new database used will be much smaller, for 1 hour video at full DVD resolution the size is approx. 250 MB.
For those who need it, dc precision 11 can also be used, just remember it's NOT DVD compliant.
On my system (P4) the new version runs a little bit faster, about 5%
Differences in quality for the encoding profiles are now smaller, so using NORMAL instead of BEST should give some speed gain.

[lunario]

thanks hank :)

[i4529]

To Hank315
Great encoder!!

Would the new release 0.15 fixes the "Hcbatch.exe -Application Error" below ?

[The Instruction at "0x08ea8bfc" referenced memory at "0x08e139c8".The Memory could not be "read".
Click on Okto terminate the program]

[Frameserver]

@LigH
Congratulations, 30, a real milestone... Already a long time ago for me :)

And thanks again for testing to get the W2K problem solved.
Thanks also go to Katjarella and Jeanl for this.


@LigH congratulations to your birthday, 30 is indeed a milestone :cool:

@hank315 will test that version, especially the gui version, because I'm one of the "W2k won't work" members. Let's see what happens this time :sly:
Btw. hcbatch works fine all the time, use it much, great encoder. :thanks:

frameserver

edit: Test succeeded hc_015 works on W2k with avisynth now. Great Work !! :D

[DK]

my first experiences with 015 are:

- 015 works considerably slower

a 100min source took me:
Phase II ENCODING completed in 234 minutes with 015

Phase II ENCODING completed in 156 minutes. with 014


at first i didnt realize it had to do with the new version, because i was building a new system and thought: *high time you optimized your system*

i did 4 conversions with different machine settings using 015 until i tried 014 on the new hardware again and i was reliefed to find the hardware was fine :rolleyes:

[freelock7]

Good job Hank. HC15 becomes slowly my favourite encoder.
Picture quality is increased once again!
What about the new bias setting? Same as CCE?

[vhelp]

:helpful: with HC.

FWIW, (and after 10 pages) I finally got HCenc to work on my w98 gold.
So, this is my test with HC.

I did notice quality was very good :)

However, I have three issues of concirn I found so far:

Does HC have problems with windows 98 resources ?? ..because I found that
it had depleated my resource down to 3% and when I closed HC to regain,
my system hung, and I had to reboot. This was happening when I was
working w/ an AVS script on a short 60 second VOB file as a test file.
If memory serves me, I peformed about 8 encoding scenarios, before the
resources gave out.


Can not open .d2v files. I put the "DGDecode.dll" inside my \windows\system
folder, and even in HCenc folder, where my VOB; *.d2v; and AVS script files
are located, but it does not want to open the .d2v file.
.
The error message is:
can not load movie, error in D2V file ?


YV12 color space. When I was finally able to work with it through
AVIsynth script, and opened the script
and encoded it with HC, and once encode to MPEG, the color space seemed
to be too bright.. sort of washed out.
.
Here is my script history.. After making my .d2v file from dvd2avi v1.76
I opened in VFAPI and converted to psuedo avi file. Then, through a script,
I imported the avi file, and finally, encoded inside HC.
.
--> VOB --> dvd2avi 1.76 --> VFAPI --> AVS script --> HCenc GUI
.
I was hoping to utilize the directness of HC's power when working with
sources in same format (ie, YV12 sources) and the .d2v route I thought
was the best one to use, because I'm under the assumption that the .d2v
file color space is YV12 -- now, I'm not sure, either way, if the above
proves too light, will the .d2v route prove the same results ??


One question ...

If I check this box, does that mean, [ ] Constant Q = CBR ??


Another fwiw.., I found that interlace doesn't seem to agree with HC
(for the moment) [u]But, progressive sources seem to encode without much
blocks, if any. And, the speed is perfectly acceptable, given my
CPU: AMD XP 1800+ setup w/ 512mb ram. I am impressed with this new encoder, HC :)

-vhelp

[Guest]

Regarding the D2V file opening, you have to make the D2V with the DGIndex program that matches the DGDecode you are using. You can't use DVD2AVI. Get the matched DGIndex/DGDecode pair here:

http://neuron2.net/dgmpgdec/dgmpgdec.html

For best results, don't use VFAPI or open the D2V directly. Make the D2V with DGIndex and then make an AVS script like this:

loadplugin("dgdecode.dll")
mpeg2source("yourfile.d2v")

Then load that script into HCEnc. This will deliver YV12 to HCEnc with no color space conversions. It also gives you all the flexibility and power of Avisynth scripting.

[vhelp]

Ah, yes. Thank you. I will D/L as you suggested.

However, my W98 resources still remain worrysome to me. It seems to
be depleating on me.. now down to 19% and counting. If I close HC down,
I regain 8 percent, brining me back up to 27% percent. hmm.. Anyways.

.
.

Later on..

I wanted to share my current status so far.

The YV12 color space brightness problem has been adressed and solved..
things are looking much better now. Thanks Neuron2.
.
oh, fwiw.., I did not use your suggestion w/ going the script route.
Since I do not have a need to filter my source (ie, ivtc; resize; color
space; or function creativity purposes, etc) I prefer to go the direct
route. In my recent endeavors w/ HC, I fed the .d2v file directly, and
all worked well. Color space was back to normal, according to my usual
taste.

.
.

The encoding is working fine though. And, the quality is looking better
than before. But, it seems that [ ] Constant Q does not equal CBR. Oh well.
.
I won't say that HC passes TMPGenc in terms quality, but it is definately
approaching it. My weighing scale is different than most. Since I do
mainly CBR 9000 bitrate in TMPGenc, I can't make any fair comparisons.
So Hank315, if you're lurking, you're out of the heat. Nah..
just kidding.

-vhelp

[Guest]

HCEnc doesn't do CBR.

Hank will have to address your resources issue. Why don't you upgrade to XP?

[LigH]

A constant quantizer cannot result in constant bitrate, as long as the content of the video changes: Low detailed scenes will compress much better, high detailed scenes (due to more different quantization values for high frequencies) instead harder.

[vhelp]

Regarding the resource issue. I was just mentioning it here fwiw,
since it wasn't reported.

And as for the reason why I don't install XP ..
(will try and use minimal words) Although I do have XP (home edition)
it is too bothersome for me to deal with my tipcle crashes, and
reinstallations and setups for my multi-pupose system, and then having
to resort to re-registering it to MS every time I crash, or make a change.
There are other reasons beside these.


Thanks LigH, for your CQ explanation. I was too quick to realize this.

In the mean time, I will continue to play with HC.. ( under win98 )

-vhelp

[Guest]

XP crashes for you more than 98? That's a shocker.

[hank315]

What about the new bias setting? Same as CCE?Don't know, can't look at their source code :)
Short explanation: HC calculates a minimum bitrate using the values for max. and average bitrate.
Using this min. and max. bitrate the (VBR) compression curve is calculated.
Using the bias command means the compression curve is pulled towards the average bitrate.
I don't know if the method and scale is the same as CCE, using a value bias=30 produced pretty good results during my tests.

@vhelp
HC doesn't use that many resources, if the GUI version is started you can see it will use about 125 MB virtual memory.
Because HC itself doesn't use dynamically allocated memory it will NEVER use more...
If I start an avisynth encode memory use goes up to 260 MB on my system,
starting a d2v project memory only goes up to 148 MB.
I also tested HC with DVD Rebuilder on a system with 256 MB installed using XP without any problem.
And you may have your reasons still using W98 but I can still remember all those restarts I didn't ask for...

[zilexa]

Don't know, can't look at their source code :)
Short explanation: HC calculates a minimum bitrate using the values for max. and average bitrate.
Using this min. and max. bitrate the (VBR) compression curve is calculated.
Using the bias command means the compression curve is pulled towards the average bitrate.
I don't know if the method and scale is the same as CCE, using a value bias=30 produced pretty good results during my tests.


I guess, if your average bitrate is high enough (3mbps or 4 or higher?), you could set the bias to 30... but if your average bitrate is lower (like 1.9-2.5 with cce when encoding 8 episodes of Lost(xvid) to 1 DVD) perhaps it is advicible to put the bias a little bit lower? like 20?

[parcival]

Dear Hank315,
This is the first time I use HC (that is HC015) so I am not sure if I am doing something wrong. I am trying to encode a dvsd video (DVC/DV Video from a camcorder) and I am using the following script:
a = DirectShowSource("D:\road.avi")
b = a.TomsMoComp(-1,5,1)
c = b.Undot()
d=c.ConvertToYV12()
return d

I also tried:
a = DirectShowSource("D:\road.avi")
b=a.ConvertToYV12(interlaced=true)
return b

And even this:
a = DirectShowSource("D:\road.avi")
b=a.ConvertToYV12()
return b

I always get the same completely distorted result. What am I doing wrong?
If you want I can send you a dvsd sort video (2 sec only but 6.8MB size).

[Kika]

HC calculates a minimum bitrate using the values for max. and average bitrate.

I'm a bit curious: Why a user can't define the Min. Bitrate?
I'm mostly using TMPGEnc in CQ Mode, so i tried HC in CQ Mode too. But i was not able to prevent HC from choosing too low bitrates for some still or dark scenes. Guess that's why i have these strange results in my tests:
In some scenes HC did a better job, in some scenes TMPGEnc did. Surprisingly the low bitrate scenes came out better encoded by TMPGEnc.

[LigH]

@ parcival:

(Welcome to the doom9 board...)

You don't really need all those clip variables in your scripts. They are only necessary if the video processing path splits or joins. But your scripts are pretty linear. So e.g. just useDirectShowSource("D:\road.avi")
TomsMoComp(-1,5,1)
Undot()
ConvertToYV12()Read the documentation, which was installed together with AviSynth, about the implicit "last" variable.

BTW: I got distorted video, too -- as long as I ran AviSynth 2.56 betas. When I downgraded back to AviSynth 2.55, everything looked fine again.

[parcival]

Thanks LigH for your help!
I had to use clip variables for adding a lot of videos (140!) into a single one, something like:
a1 = DirectShowSource("D:\road 1.avi")
a2 = DirectShowSource("D:\road 2.avi")
a3 = DirectShowSource("D:\road 3.avi")
...
b = a1 + a2 + a3 +...
...

I tried to give a simple example but I forgot to remove the clip variables.
Yes, I had installed AviSynth 2.56 Beta 3 just a few days ago. I will try good old AviSynth 2.55 and get back to you.

[parcival]

Yes! AviSynth 2.55 did the trick!
Whoau!!! What else can I say about this excellent encoder?
Well done Hank315!

[johnhamler1]

hello,

for what I am concerned, the 0.14 Hc works perfectly, and give me 4.3 Gig as file output, what is new in the 0.15?

does it worth to install?.
Will try a test with the excorsist pal version.

Guys, how do you see a difference on your little screens, I watch movies from a beamer, and I can not tell any difference?


are you a kind of superman, do you see through walls too?

[hank315]

I'm a bit curious: Why a user can't define the Min. Bitrate?Well, I tried to create an encoder with not that many settings.
And if the minimum bitrate setting is too low the result is just horrible.
But maybe one of the next versions will have this min. bitrate setting.

I'm mostly using TMPGEnc in CQ Mode, so i tried HC in CQ Mode too. But i was not able to prevent HC from choosing too low bitrates for some still or dark scenes. Guess that's why i have these strange results in my tests:
In some scenes HC did a better job, in some scenes TMPGEnc did. Surprisingly the low bitrate scenes came out better encoded by TMPGEnc.Don't really understand this, running CQ mode means it runs with a constant quantizer, bitrate just comes out as a result how well the source can be compressed.
If there's not much to quantize, like in dark scenes, bitrate will be low.

[Encoder Master]

I'm mostly using TMPGEnc in CQ Mode, so i tried HC in CQ Mode too. But i was not able to prevent HC from choosing too low bitrates for some still or dark scenes. Guess that's why i have these strange results in my tests:

And I don't recommend the CQ mode because you have to predict and this don't give you the best quality. The best quality you get with 2pass und a perfect average Bitrate. With 2pass it looks better, in low bitrates, even TMPGEnc's mpeg-1 mode.

[jdobbs]

The quality in CQ mode will be just as good as you set it... it could be better or worse than 2-pass... you just don't know how big it will be until it's done (or you've done as sample pass in an attempt to predict it).

No doubt, though, if you have a target size you have to hit, you are almost always better off with 2 pass.

[rail grinder]

GGRRRRR

i hate hc .......... my uncle came over the weekend and was watching one of my backups and was so shocked at how good the quality was that i've now been made his official backup monkey :angry:

keep up the awesome work hank ;)

hehee i feel like using dvdshrink or dvdxcopy on his backups just to get him off my back :D

[freelock7]

-Hank315
Problem with the shutdown option:
the cpu is still runing (but win xp is closed correctly).

[Kika]

@jdobbs, Encoder Master, hank315

I know how CQ works... use it since years because i get much better results with CQ than with 2pass (in TMPGEnc). ;)

running CQ mode means it runs with a constant quantizer, bitrate just comes out as a result how well the source can be compressed.

True, but: The choice is done by the Program based of it's routines. And i think, in some cases, the choosen Bitrates are too low to get a real good result. That's why i asked for the possibility to define a Min. Bitrate. Not to set it to a very low state - it's to set it to a higher Value than HC will choose in some cases.
In TMPGEnc, there's the possibility to do this, and a well choosen Min./Max./CQ-Setting will result in a very high quality in all scenes of a Movie. With HC, i get very good results in high motions scenes, but bad results on still scenes or scenes with low contrast.

And, as i said: I don't think 2pass will give you better results, it's just time conuming.

@Encoder Master
MPEG1? This old way to encode? Oh no... :D

[Xeno86]

hi

I haven't been here since hc012 ;) . Hank315 I must say that you did much progress with your encoder :) . The new version has better quality than 014 and 012 and is faster. However I've found some new bugs:

1. If I select "Constant Q" and "check max br" I'm not able to set max bitrate to lower than 4000, unless I unselect "Constant Q", enter a lower avg bitrate value and select "const. Q" again.

2. If I Stop the encoding in the middle using "stop" button m2v file remains locked so if I want to see the encoding I have to close HC.

3. Resource leak issue in Windows 98. In fact it only occurs if you have encoding preview turned on.

[Encoder Master]

Problem with the shutdown option:

Yes same here. Windows say that I can turn off my PC.


@Kika

For ONE-CD-Encodes encoded with TMPGEnc, MPEG-1 gives you much better quality then TMPGEnc's MPEG-2 mode. But now we have HC. :p

[LigH]

Windows say that I can turn off my PC.
This would be the usual reaction for a "Standard PC" without ACPI functionality.

Due to severe IRQ assignment problems with ACPI (6 devices sharing 1 IRQ is nonsense), I chose this mode for my system, so I was not able to tell any difference in my beta tests. :o

[Kika]

For ONE-CD-Encodes encoded with TMPGEnc, MPEG-1 gives you much better quality then TMPGEnc's MPEG-2 mode.

Hehe, you've never seen my MPEG2-1CD-Encodings... ;)

OK, back to topic.

3. Resource leak issue in Windows 98. In fact it only occurs if you have encoding preview turned on.

Yes, same here. That's a bit funny. It's not realy a problem, but looks very strange.

[Encoder Master]

Hehe, you've never seen my MPEG2-1CD-Encodings...

But not with TMPGEnc, or which encoder do you use for your encodes.

[Kika]

TMPGEnc is my "Baby". I know a couple of tricks. :D
It's no big thing to beat MPEG1 with MPEG2 - even with TMPGEnc. But you need completely different settings to do that. If you use the same settings for MPEG1 and MPEG2 in TMPGEnc, MPEG1 might be a bit better. But only in this case.

My 1CD-Encodings are done in 352x288 anamorphic or 352x576 anamorphic (13th Warrior on a MiniDVD, 698 MByte, 192 kbps AC3 2.0 Audio from DVB-S). I never tried it with 4:3 source.

But this is a thread about HC, right? If you like, we can discuss this in an other Thread.

OK, here's something more on my wish-list for HC: Realtime display for the size of the I-, P- and B-Frames, similar to TMPGEncs log.

[hank315]

If I select "Constant Q" and "check max br" I'm not able to set max bitrate to lower than 4000, unless I unselect "Constant Q", enter a lower avg bitrate value and select "const. Q" again.Max. bitrate just can't be smaller than average in general, will correct this for CQ encodes.

If I Stop the encoding in the middle using "stop" button m2v file remains locked so if I want to see the encoding I have to close HC.Next version will close the m2v file if STOP is pressed.

Resource leak issue in Windows 98. In fact it only occurs if you have encoding preview turned on.Another funny Windows issue...
Seems it doesn't appear in XP/W2K
Was this introduced in HC015?

The choice is done by the Program based of it's routines. And i think, in some cases, the choosen Bitrates are too low to get a real good result.Sorry but I still don't get it...
Running with a constant quantizer there's nothing to choose for bitrate.
The only thing i could change is to code every P and B frame completely intra and even then it's possible the min. bitrate isn't respected.

[LigH]

A CQ encode with a minimum bitrate can be achieved - for example - by stuffing the video stream with 00 bytes up to the minimum, if the fixed quantizer results in frames way smaller than the desired minimum bitrate.

There are DVD players which have VBV overflows or similar problems if the bitrate drops e.g. below 300 kbps.

[Kika]

@hank315, LigH
I don't know how TMPGEnc is doing this, but it isn't a simple padding.
In 1pass CQ VBR (not CQ_VBR-Mode, that's different), you can set Max., Min. and Q. And TMPGEnc tries not to fall short of the Min.-Setting (sometimes it does).
But i guess, there's a missunderstanding. CQ in TMPGEnc means constant quality and that's not the same than constant quantizer. So i think, to implement a Min.-Setting in HC, you have to change the quantizer in scenes with a lower than the given bitrate.

And as LigH said: A couple of player will get into trouble on lower bitrates (my Affrey as an example).

[LigH]

This leads to the question, how the "quality" is measured - as a precondition to keep it as stable as possible: Most probably a weighted PSNR (e.g. 4xY+U+V)?

[hank315]

A CQ encode with a minimum bitrate can be achieved - for example - by stuffing the video stream with 00 bytes up to the minimum, if the fixed quantizer results in frames way smaller than the desired minimum bitrate.

There are DVD players which have VBV overflows or similar problems if the bitrate drops e.g. below 300 kbps.
Yes I know but that will not raise quality, it's just a way to keep CBR really CBR or to make sure it will play on every HW-player.

Maybe there will come a time when all DVD players are really DVD compliant...

[hank315]

But i guess, there's a missunderstanding. CQ in TMPGEnc means constant quality and that's not the same than constant quantizer. So i think, to implement a Min.-Setting in HC, you have to change the quantizer in scenes with a lower than the given bitrate.OK, this make sense.

But... can someone explain what constant quality is :confused:

(Saw LigH already asked something similar while typing this.)

[Kika]

I try to explain this to LigH in the german Doom9, my english isnt good enough for such complicated things...

OK, point 3 on my wish list:
I do a lot of capturings from VHS. My Scripts are providing a luma range of 16-235. That's the standard for MPEG. But if i use HC with these scripts, the luma range is compressed to 32-219 and this results in videos with low contrast.
I know, this can be solved by AVISnth, but i hate to do more than necessary color(space) conversions.

[hank315]

@Kika & LigH
Just read your posts in the German forum, think I know what the difference is between constant quantization (HC) and constant quality (TMPGenc).

Aber selbst wenn hank keinen dynamischen Quantisierer einbauen kann oder will, sollte es möglich sein, die Quantisierung dann zu ändern, wenn ein vorgegebenes Bitraten-Minimum unterschritten wird. Das ist eigentlich das, was ich gerne hätte.HC doesn't do that ATM for CQ.
But using a dynamic quantizer is more like VBR, using lower quants to hold the min. bitrate.

[LigH]

As far as I understood Kikas descriptions of old mails, TMPGEnc calculated the quality using a weighted average over a specific amount of frames, e.g. a GOP. The quantization is adapted according to the calculated quality, it is definitely not constant.

And furthermore: Basic stuffing won't be a good idea, because an authoring tool would most probably strip those stuffing bytes off of elementary streams while multiplexing. So lowering the quantization factor is the only useful way to raise the bitrate above a desired minimum.

"Constant Quantizer" always results in variable bitrate if the movie content is changing. "Constant quality" usually will as well.
__

Nice statement for posting #1000?! ;)

[hank315]

Basic stuffing won't be a good idea, because an authoring tool would most probably strip those stuffing bytes off of elementary streams while multiplexing. So lowering the quantization factor is the only useful way to raise the bitrate above a desired minimum.Totally agree ;)

And yes another milestone: 1000 posts :D

[vhelp]

Ok then... So in HC, we should be refereing to it from this point
onward as:

CQQ = "Constant Quantizer Quality"

-vhelp

[Xeno86]

Another funny Windows issue...
Seems it doesn't appear in XP/W2K
Was this introduced in HC015?

It doesn't appear in xp or w2k because they both don't have silly 64kB resource limit - in xp resources can use whole system memory so you won't see the leak... http://aumha.org/win4/a/resource.htm

I checked HC011 and it also has this problem...

[Kika]

@vhelp
Interesting idea. ;)
All this Q, CQ-Stuff in the different encoders is a bit confusing, because they have totaly different meanings.

In HC: Setting the Quantizer
In TMPGEnc: Setting a quality factor
In CCE: something in between of the above

I have done some tests now with HC... promissing Encoder, realy.
But (ok, maybe i'm a freak on this) there are some options in TMPGEnc, i won't miss if i'm playing around with MPEG-Encoding.
1. The realtime log-File. It shows me, how the Bitrate is allocated to the types of Frames
2. The possibility to influence how the bitrate should be allocated to the Frametypes

These both things are very usefull to find a way to do better Encodings.

As an example: I had a Hi8-Movie with to surface of a lake. It was terribly blocky after encoding ( i always use TMPGEncs CQ-Mode). So i did a frame by frame analysis. I-Frames, OK, P-Frames, OK, B-Frames, oh my god...
So i raised the Max.-Bitrate and the allocation to the B-Frames. In the next try, i saw in the log, that the B-Frames now went out bigger (and better). While 3 or 4 Tests i found a good setting with no more blockyness at the same bitrate than before.
That's something, you can't do in HC yet. But i must say: On standard settings, HC is very similar in quality to TMPGEnc, maybe a bit better.
But because of the different ways to handle Luma Range, i have to do some of my tests again.

[zilexa]

using HC (0.15) for the first time now (with DIKO). Am using NOTCH matrix.

When only 1 second was left for the 2nd pass, I got an error... something about read/write to the memory :( !
Since I let it encode 8 files the whole night... and this error came in the 1st file... it never started with the second... waste of time...

I've then checked the file (.mpv), it was 484 mb, and thats what it should be.... it played fine... only the time indicated 8:23 minutes instead of 40 minutes...

still have 7 more files to encode... it is now doing the 2nd file... hope there will be no error again.

[Archimedes]

On my last (“objective”) test with interlaced sources, i came to the same conclusion. TMPGEnc (with CQ mode) was very close to the HC encoder (nearly identical). Tested with Fritz Framalyzer. Nice to see, that the "objective" values are corresponding with the visual values.

Best regards
Josef

P.S.: Version 0.15 of the HC encoder also produces better results than version 0.14.

[zilexa]

Just did another episode of Lost... same problem... an error when there is only 1 second left for the 2nd pass :(

[MuttLover]

Test your memory with memtest86 (http://www.memtest86.com/) -- sounds like it may be a hardware problem to me.

Good luck!

[johnhamler1]

did aviator (pal),4,3gig, this HC is great!

mupet question:is it possible to make it work with 2 matrix in same time , one for low bit and high bitsetting ?

[lunario]

Just did another episode of Lost... same problem... an error when there is only 1 second left for the 2nd pass :(

i have the same memory error but not in DIKO
diko is the only prog that doesn´t give me the error

avi2dvd , avixdvd they both give the error

pS dvd-rb doesn´t give me that error

[skipper152]

Hi,

Received an "Illegal instruction" with my Athlon using the batch 015 at the end of the encode, but the log seems to indicate it has encoded everything; I haven't looked at the encoded file yet. (I only did one encode).

Seems if I suspend the encode and then exit the batch encoder I can get the "Illegal instruction" consistently (I haven't fully tested yet). Will try with the hcgui015 only and see if I can duplicate it. Feeding HC with an AVISynth script (same as I used with 014, different avi file).

014 has been working fine on the Athlon.

batch015 works on my Pentium M laptop, no problems.

Skip

[doxville]

Some good news from me, seems as if the Win2000 bug is truly solved, I can use the GUI version without any problems now!

Thanks! :)

[feedback]

mupet question:is it possible to make it work with 2 matrix in same time , one for low bit and high bitsetting ?

Using the HC_15 in DVD Rebuilder Pro. you can choose up to four different Matrix types for one DVD; one for Main movie, one for low bitrate <3Mbs, one for very low bitrate <2Mbs, and one for the Extras.

Regards,:)

[urvieh]

Just tested 0.15 with Predator, avg bitrate about 5000, prec. 9, MPEG matrix, BEST quality, scene change ON. It's given me heavy blocking right from the beginning, e.g. after a few seconds, when the alien spacecraft is flying by, and the change from the intro to the approaching helicopters over the sea.
Burnt the movie again, to no avail.
QuEnc did its job.

No competition meant, just my two cents.

[Kika]

What did you use? 2pass, 1pass?

[urvieh]

What did you use? 2pass, 1pass?

I did a two-pass encode. I have now discovered even worse blocking with Mission Impossible 1. This only occurs with HC. All other transcoders and encoders work flawlessly. Weird.

The movies look fine, however, on the computer panel. The stand-alone player is a Pio 520.

[johnhamler1]

it is your DVD player who mess!
ur burning is bad maybe , did you test ur DVD with Kprobe??.
check taht, some of my backups are totally screwed, and it is not the fault of HC.

[urvieh]

it is your DVD player who mess!
ur burning is bad maybe , did you test ur DVD with Kprobe??.
check taht, some of my backups are totally screwed, and it is not the fault of HC.

Well, it is not the cheapest player, it is a dvd recorder, and not the worst one, believe me :-). Could it be the decoder chip is different because it has to do both, decoding and encoding?

Secondly, I've tested with the Plextools; the burns are perfect.

OTOH, and as I reported in my first post, this does not happen after encoding with QuEnc or IC8 or Recode or Shrink.

HC tends to sharpen more than the other candidates do -- could this be the problem? (Plus the chip on the DVD-R?)

[johnhamler1]

well, the cheapest player work better.I have 2 (standalone)players at home , the most expensive one accept only 50% of my discs, then the one at 40$ play all discs.

[urvieh]

well, the cheapest player work better.

Well, might be true. However, I had no problems until v0.14 :-). Perhaps the facts will help the programmers.

[Heathcliff!]

Hi everyone. First I want to compliment Hank on his excellent work. HC is a good and promising encoder.

Lately I have been experimenting with a technique named RoBa (http://forum.doom9.org/showthread.php?s=&threadid=57518). I'm no expert, but I will try to explain this a bit (sorry if I've misunderstood some things about Mpeg-encoders or RoBa).

When video is encoded using multiple passes a database is build with information about the relation between the bitrate and the quality of different frames and areas in frames. The target of the encoder is to create a video of highest quality within the given size (bitrate). To achieve this, the quality of the movie must be as constant as possible. In every pass an estimation is made of what quality (quantisation-factor) is created within a certain bitrate. The previous bitrate-calculations are used and then revised to get a better average quality.

According to the RoBa technique, first there will be made a quality-estimation to determine which quantisation-factor will result in a video with the desired size. Some video-samples (short clips) are encoded using different quantisation-factors (this can be done with AviSynth). Then one factor is determined to encode the full video. Constant Quality encoding is used and a database is also created during this pass(!) In many cases the size of the resulting video is in close rage of the desired size. If the video is too big it might be shrinked with a transcoder. If the size is too far off, an extra encoding pass is needed to get to the desired size. This pass is a normal VBR-encoding pass and the database from the CQ-pass is used. The advantage is that all bitrate information in the database is already structured for a perfect constant quality and needs to be slightly adjusted for the final bitrate. This way the highest quality encoding is possible with a maximum of only two passes (often only one pass).

Using HC encoder, first an ini-file must be made for the CQ-encoding-pass and then, if neccesary, a second ini-file must be made for the VBR-encoding pass. But to do this, HC encoder should create a database-file during the CQ-encoding. Is it possible to implement this feature in a next version of HC-encoder? I would very much appreciate this and I am curious to see if it is possible to get even higher quality video's with HC-encoder this way.

Thanks alot and keep up the good work!
Heathcliff

[dragongodz]

urvieh - did you make sure you encoded with "seq encode" turned off ? if not then please try that.

[urvieh]

urvieh - did you make sure you encoded with "seq encode" turned off ?

Thanks for your reply. All I have found in the documentation is "*NOSEQ_ENDCODE". Is it this parameter? I'll give it a try. If it is not, how do I disable it for the batch encoder?

[LigH]

This must be the one. The "Sequence End Code" is usually important for other uses than DVDs. And it can confuse the decoder when several videos get joined so that such a sequence end code appears in the middle of the stream.

But still, because a sequence end code appears only at the end of an encoded file, I wonder why it shall influence the quality of the beginning of the video... Thanks forward for anyone who can explain this in detail.

[urvieh]

I'll try and turn off scene detection first. Don't expect further results before tomorrow night MET :) .

[hank315]

But still, because a sequence end code appears only at the end of an encoded file, I wonder why it shall influence the quality of the beginning of the video... No, it doesn't.
The sequence end code just marks the end of a sequence and is in fact obsolete for these kind of encodings.
For DVD it's required that every GOP starts with a sequence header, this header contains info about aspect ratio, frame rate, horizontal and vertical size etc.
But you're not allowed to change this header info, only after a sequence end code these items can be changed in the next header.
This way you can concatenate two video streams with different aspect ratio's etc.
You may even use a sequence end code after each GOP but some players don't handle that very well...
So the normal way to do it is to put one sequence end code at the end of the stream.

@urvieh
Could you test it with the next settings:
*PROFILE NORMAL
*GOP 12 2
*NOSCD
*DC_PREC 9

[urvieh]

@urvieh
Could you test it with the next settings:
*PROFILE NORMAL
*GOP 12 2
*NOSCD
*DC_PREC 9

I will. My hc.ini will then look like

*PROFILE NORMAL
*GOP 12 2
*NOSCD
*DC_PREC 9
*maxbitrate 9500
*dc_prec 9
*logfile i:\filme\test.log
*wait 0

I'll use DVD Rebuilder Pro.

[cmsoliveira]

@urvieh

What version of predator do you have? I own the special edition, region 2, and i've just backup using rebuilder (0.93,free) and hc0.15 and the result was "perfect". Absolutly no problems like the ones you've described (just finished analysing the m2v files created by hc).

My ini for this movie is

*MATRIX MPEG
*PROFILE BEST
*NOSEQ_ENDCODE
*LOGFILE c:\predator.log
*WAIT 0

All the other parameters are defined by rebuilder (gop size, dc_pred...) or are default of hc0.15, with an average bitrate of 4220 KB/s.

[johnhamler1]

use profile best if you want a better quality!com'on !??!!

[urvieh]

@urvieh
What version of predator do you have? I own the special edition, region 2

I have the same as yours, I suppose. The movie looked fine on the display, but the pio 520 can't handle it.

[urvieh]

use profile best if you want a better quality!com'on !??!!

Normally -- yes. But we are still testing what's causing the problems.

[urvieh]

Now that's weird again: I don't seem to stand a chance of turning scene detection off, although this has been done in DVDR and the ini file.

I'll play around with it for a while and keep you posted.

[cmsoliveira]

urvieh, have you tested the backup on any other player besides your pio 520?

also, does the problem only occured on the parts you've mentioned, i.e, in the beginning of the movie? Perhaps it occurs due to low bitrate...

[urvieh]

I have no other stand-alone device. Maybe it is of importance: The TV set is a 100 Hz-device.

The blocking occurs in every area where there is rapid movement. I haven't had this with version 0.14 or any other encoder/transcoder.

I've just encoded MI1 again, but will burn it tomorrow.

[LigH]

Blocking on rapid movement ... my "guess of the day": Interlaced material was encoded in "progressive mode".

[Heathcliff!]

@Hank

Hank, could you please comment on my previous post about RoBa? Would it be possible to create a database during CQ (OPV) encoding and then do an additional VBR encoding pass using this database?

Thanks,
Heathcliff

[urvieh]

Blocking on rapid movement ... my "guess of the day": Interlaced material was encoded in "progressive mode".

Not sure about that. HCBatch showed clear "interlaced" and "tff" settings.

[urvieh]

@urvieh
Could you test it with the next settings:
*PROFILE NORMAL
*GOP 12 2
*NOSCD
*DC_PREC 9

Alright. I've just burnt the dvd and watched the beginning of the film. No change, blocking all the way. I'm sorry.

[johnhamler1]

why the sound and the image doesnt match?(no synchronisation)
the sound come 0.5 seconds after or before!
by chance it is only on 2-3 movies and only for a few minutes.

[urvieh]

Okay, latest results:

Encoded movie: Mission Impossible 1, main title only.

Profile NORMAL, no sequence end code, etc. => heavy blocking
Profile BEST, no hc.ini, just the parameters handed over by DVD-RB => heavy blocking to the same extend, at the same places at the same time.

I gave QuEnc a chance, and it has turned out fine, although a bit undersized.

[hank315]

@urvieh
I also did a test:

DVD-RB PRO 0.93.2 and HC015
movie: Matrix Revolutions, PAL
movie only, profile best, matrix QLB, interlace disabled
Encoding time: 167 min. (movie: 124 min)

There are some pretty heavy action scenes in it but it played OK on my PC (using PowerDVD) and on my HW player.

In your case the movie plays fine on a PC but not on your HW player.
Blocking appears in heavy action scenes where motion vectors can be long,
seems your player doesn't like that, however it is DVD compliant.
Until now I didn't receive any other messages about this blocking.
Will PM you...

@Heathcliff!
What you want isn't possible with HC.
Ofcourse I can write a database file during a CQ run and do a second pass,
this is also the normal way for HC to do a 2-pass encoding:
CQ run --> construct compression curve --> run VBR second pass.
But the second pass requires that the first pass is done with a fixed CQ and I really mean fixed (set by HC)
otherwise the bitrate control doesn't work properly in the second pass.

[Heathcliff!]

CQ run --> construct compression curve --> run VBR second pass.
But the second pass requires that the first pass is done with a fixed CQ and I really mean fixed (set by HC)
otherwise the bitrate control doesn't work properly in the second pass.

Thank you for this explanation. But this actually raises some more questions for me. You explain that in the first pass of VBR encoding a fixed CQ-factor is determined. I wonder how you can do this. Most encoders would need multiple passes in which the quantisation / bitrate database is fine-tuned everytime. Every pass the values are closer to a constant quantisation factor. The other way to do this is by sampling the video and estimate a CQ-factor. There are some CQ-calculators around to do this (http://forum.doom9.org/showthread.php?t=96205). But the problem is that they do not provide an acurate videosize. And this is what RoBa is all about. With the data of the first CQ-pass a second VBR-pass can be done to get an acurate filesize for the resulting video. You somehow do all this natively? I am really curious about the technique you use in the first pass to build the database for the constant quantisation database. Can you explain this a bit more?

Thank you,
Heathcliff

PS. uit welke plaats in Nederland kom je eigenlijk?

[Marius-the-Mad]

hank315, I wanted to say "thank you".

Your encoder is very, very good. Thank you for creating and maintaining it - and thank you even more for doing it for free. HC is my encoder of choice. :)


Best regards,
MTM


P.S. Will you accept a minor-bug report ? ;) In the log file, HC reports a usage of HVSGOOD when HVSBEST is selected - and vice versa. But judging by quality, HVSBEST is being used when I select it. Sorry I didn't have time to check it and make sure - I just discovered it.

<edit> Bitrate with CQ seems to confirm it's only a log issue.

[TFM_TheMask]

Hi,

Everytime I use HCBatch I got an read address error at the end when HCBatch is closing.

This is the commandline I use:

HCBatch.exe -i "F:\The FilmMachine\Programma\Output\TFM_Avisynth_Script_File.avs" -o "F:\The FilmMachine\Programma\Output\TFM_Enc_Video.m2v" -b 9608 -maxbitrate 9808 -aspectratio 16:9

I have tried to change the parameters but it doesn't change anything.

Does anyone has the same problem or knows how to solve it?

[Mug Funky]

a little info aboot your system? all the machines i've tried batching on have been fine (p3, a p4 and another p4 with hyperthreading turned off)

[PJones2101]

Hey.

Once again Hank does a brilliant job. Guys please remember, Hank does this in his free time so lets appreciate his work.

Suck up !!!!!!!!!!!! :-)

Hank: When encoding PAL movies with a low bitrate ( Ave:1600 Max:4000 ) I get a brilliant picture and a 90 min movie to +- 1.2 Gig. However I noticed night areas with a minimum difference in color cause blocky playback ( PC with WinDVD through a TV out ). Could it be the matrix ( HVSBest ) ??

[urvieh]

a little info aboot your system? all the machines i've tried batching on have been fine (p3, a p4 and another p4 with hyperthreading turned off)

A normal p4 system with standard components only. I think Hanks is tracking down things. As soon as he has found a solution, he'll inform you. I'm not sure if I'm allowed to give details here. :)

[TFM_TheMask]

Don't understand me wrong I really appreciate the work Hank is doing, but I think he like to know if somethings don't work on some computers.

My specs are:

AMD Athlon 64 3400+

[urvieh]

PIV3200 (Prescott), 1 GB DC-RAM

[PJones2101]

Ya of cource. I'm not bickering. I'm just reminding people about the fact. I also posted a problem/question ( proberly mine, not his ).

I was just concerned people forgot this is a part-time project and expect him to jump.
I'm full up for reporting bugs and asking help.

Just a reminder. That's all.

[hank315]

@TFM_TheMask
This error has been reported a couple of times but because i've never seen it happen on my system it's hard to find.
Will PM you.

@Marius-the Mad
You're right, HVSGOOD and HVSBEST are switched in the logfile of the GUI version, will correct that, thanks for reporting it.

@PJones2101
Those dark scenes can be hard to encode.
Try the bias command, it will give some more bits to these scenes which might reduce blocky playback.
Also you could try the NOTCH or HC matrix.
And ofcourse, an average of 1600 is pretty low ;)

[johnhamler1]

got an error 6, it says: there was a problem to rebuild, something like that.
what is that?

i did 10-20 encode with no problems...why i have some problem sudenly?
Ok, I have canceled some FBI warning with, and I have controlled if DVD shrink loads the movie to be sure the files are in a correct order.they are!

but what is error 006?

updated: well, my problem is with DVD rebuild, old version!

[skipper152]

Hi Everyone,

You can see my other post here...
http://forum.doom9.org/showthread.php?p=677711#post677711

@TFM_TheMask
I had the same problem, but I managed to fix it (not sure how). I can give you what I did, not in any particular order, since this is over several days of trial, error and several late nights. Use the information at your own risk!

My System: Athlon 64 3500+, 1GB Ram

- AOL was starting it's connectivity service. Changed this to manual and hc015 seemed to work. I then changed it back to Automatic, but I could not duplicate the problem of the memory error.
- Deleted everything in the c:\windows\prefetch directory
- Regedit. Deleted references to hcbatch_015.exe, hcgui_15.exe, hcbatch_014.exe, hcgui_14.exe after reviewing the entry.
- External commands were not working (like more, fc). Found when I did a set, my path was coming up with %SYSTEMROOT%, rather than c:\windows. Internal commands (dir) worked fine. Changed the environment path from %SYSTEMROOT% to c:\windows where necessary, and my external commands started working.
- Changed the comatibility of the HCGui to win 98 / me

It doesn't seem like anything should have made a difference. Both applications seem self contained (using only system dll's).

Now for the kicker....
In my previous post, I mentioned that my laptop Pentium M was working fine. Came in one day and it started having the memory problems with hcgui_015, 14 is still working fine. I tried all of the stuff above, but still nothing.
- This machine had avisynth 2.5.6 installed on it. Last I remember, this was still in development. I uninstalled and reinstalled 2.5.5, but still no success.

With both machines, I have been installing and uninstalling some of the other great programs people here have been working so hard on to try them out.

@Hank
I'm not sure if this will help, but I can get HCgui_015 with the memory error if I just load an avs script, not change any configuration on the screen or do any processing, but just exit the application. If I don't load a script, I can exit the application with no problem. This same script works fine in 14. I haven't tried a .d2v file.

Hope this helps someone...

[skipper152]

Sorry for posting again so soon, but I just tried something. Maybe it will give Hank some more firepower during the debugging process....

This script doesn't work....

AVISource("E:\Down\test\test.avi")
LanczosResize(352,128,0,0,640,256)
AddBorders(0,48,0,64)
KillAudio()

But this script with the 1 line does

AVISource("E:\Down\test\test.avi")

I've tested this several times on my pentium M just now...
I've loaded the bad first or the good first, but the bad keeps giving me the memory reference error. I've also tried different resizings in the script too.

I've attached the files (1st time I'm doing this), so hank can use exactly what I am using. Not that is should make any differnce, but the avi referenced is XviD-1.1.0-Beta2-04042005 _Beta Release_

Skip

[TFM_TheMask]

I confirm that it has to do with the Avisynth Script.

I think it has to do with the line AviSource, because when I change this line in DirectShowSource the error doesn't show (I only tried with the gui and not with the batch, will test that tomorrow)

The only thing I did is open the scriptfile and then close HCgui.

[TFM_TheMask]

Ok did test HCBatch with this script:

# 16:9 encoding
DirectShowSource("D:\JamesBondTest.avi", fps=23.976)
ConvertToYV12()
LanczosResize(720,356,0.0,0.6)
AddBorders(0,62,0,62)

and it worked without the error. When I use the old script:

# 16:9 encoding
AviSource("D:\JamesBondTest.avi", false)
ConvertToYV12()
LanczosResize(720,356,0.0,0.6)
AddBorders(0,62,0,62)

I got the read error. So I think something is wrong with reading and releasing the command AviSource.

[LigH]

Which AviSynth version - 2.55?

[hank315]

I also tried these scripts.

My sytem: P4 3.2 (Prescott), 1 GB memory.
Avisynth version: 2.56, build: jan 31 2005

DirectShowSource("test.avi")
ConvertToYV12()
LanczosResize(720,356,0.0,0.6)
AddBorders(0,62,0,62)

runs OK.

Avisource("test.avi",false)
ConvertToYV12()
LanczosResize(720,356,0.0,0.6)
AddBorders(0,62,0,62)

also runs OK.

Whatever I try it just always works OK...

[LigH]

Then there must be some garbage in the ICM / VfW system, maybe several colliding codecs. Either due to unusual registration (e.g. by an evil codec pack), or due to evil code (one example: AngelPotion), or due to misconfiguration (yes - you can ruin it through ffdshow with several RAW video settings)..

[TFM_TheMask]

I use Avisynth 2.56, build sep 28 2004 on AMD 64 3400+

Will try the new build.

[TFM_TheMask]

@Ligh

Why is it then that CCE and QuEnc and Procoder are working correctly with the same scripts?

[Inc]

I dont know if HC encoder uses a diff. way but usually serving an avi (avs) stream or frames within an applikation to an encoding procedure will be done via the vfw api.
Means AVIfileOpen(), AVIFileReadStream() etc.
And so the system internal vfw core does just use (imho) the framework of avisynth.dll to serve the bitstream out of the avs resulted textfile.

Means ..... I do still think your avs setup is messed up or something like that.

[LigH]

AviSynth 2.56 beta 3 messes the video (see here (http://forum.doom9.org/showthread.php?p=676120#post676120)) - better stay with AviSynth 2.55

[TFM_TheMask]

Just de-installed version 2.56 and installed version 2.55 but no difference, still the read error.

Maybe it only happens on AMD 64 processors?

[DrShrinker]

I read the posts by TFM_TheMask and wanted to try his scripts on my brand new AMD 64 3000+ in Windows XP. I also get a read error:

The instruction at "0x085d8bfc" referenced memory at "0x086036e8". The memory could not be "read".

Here's what I fed HCBatch:

HCBatch.exe -i "F:\Temp\Movies\Sample\test.avs" -o "F:\Temp\Movies\Sample\test.m2v" -b 9608 -maxbitrate 9808 -aspectratio 16:9

Here's the avisynth script:


#ASYNTHER AVISource
AVISource("F:\Temp\Movies\Sample\sample.avi")
ConvertToYV12()
LanczosResize(720,356,0.0,0.6)
AddBorders(0,62,0,62)


I have AviSynth version 2.55.

HCBatch works great with DVD Rebuilder, but then again that doesn't use AVISource.

Is AMD 64 the problem?

[DrShrinker]

I just tried the same script in HCGUI_015.exe (same version as the HCbatch I used) and I did not get an error message when the encoding finished. But when I tried to close the GUI, I got the error message. I used the same settings, too: average bitrate 9608, maxbitrate 9808, 16:9. Weird.

[doxville]

I read the posts by TFM_TheMask and wanted to try his scripts on my brand new AMD 64 3000+ in Windows XP. I also get a read error:

The instruction at "0x085d8bfc" referenced memory at "0x086036e8". The memory could not be "read".

Do you have ffdshow installed? I usually get this kind of error, when I installed ffdshow with the makeAVIS-part. When I choose to leave makeAVIS uninstalled, i never get this message. That's some mystery to me, why ffdshow crashes different programmes when closing them. :confused:

[LigH]

Just found out (I hope not too many people posted this without me noticing that):

There is a "provider" for Cuttermaran to support HC as "GOP recoder":

http://prdownloads.sourceforge.net/cuttprov/

[hank315]

Maybe it only happens on AMD 64 processors?Yes, what I've seen so far it only happens on AMD processors.

Maybe I should switch to AMD to see what actually is going wrong :eek:

[DrShrinker]

Do you have ffdshow installed?

Nope.

[Xeno86]

@TFM_TheMask: What OS do you use? Is is Windows XP 32 or 64 bit?

[TFM_TheMask]

Windows XP 32 bit with SP2.

[DrShrinker]

Windows XP 32 bit with SP2.

Ditto here. But my processor is the AMD Athlon 64 3000.

[osho]

I must say HC works amazingly great on x64.

I my previous install of x32 win pro HC froze the whole pc basically every 10 mins.

now on x64 it runs far better. dont know if it is by reinstall of whoel win but it also runs faster. getting now around 70fps on the first part of the pass.

[_argos]

i can confirm this error on exit thingy. got an error when using AVISource but NO ERROR with DirectShowSource.

my Cpu is Athlon64 3200+ with WinXP SP2.

_argos

BTW: I uploaded an altered version of the HCProvider for Cuttermaran with the DirectShowSource-Workaround. Get it here (http://home.arcor.de/frostyboy/data/HCProvider_altered.7z). Source (AutoHotkey) is included.

[skipper152]

Hi,

My system (with the applications mentioned installed)
AMD Athlon 64 3500+
1 GB Memory
WinXP 32-bit SP1
ffdshow version oct 12 2004 08:43:06
AVISynth 2.55 build sep 1 2004 [16:49:49]
XviD XviD-1.1.0-Beta2-04042005 _Beta Release_

It seems the only time I have problems with HC_015 is when I have AOL running. So for me to get the avs to crash using AVISource on exit I have to load up AOL. So, I'm confused as to why the exiting problem doesn't happen on my Athlon 64...

Changing the script from AVISource to DirectShowSource works fine (mentioned by TFM_TheMask).
I have nothing checked in the ffdshow raw-only filter configuration (mentioned by LigH).

I've tried QuEnc and there have been no problems with the avs scripts at all.

I don't know too much about video processing, but if there is something I can look at or try to help out, let me know. (I'm working night shift this week, so I'll try to get back as quickly as possible!)

Skip

[_argos]

another thing i've noticed is: the crash only seems to happen if the hc_batch.exe is called from within another program as in dvd-rebuilder or in my case from Cuttermaran-"Provider" (which is an AutoHotkey script turned to .exe). when i launch the program from the command line the error does not happen. strange, eh?!

_argos

[DrShrinker]

another thing i've noticed is: the crash only seems to happen if the hc_batch.exe is called from within another program as in dvd-rebuilder or in my case from Cuttermaran-"Provider" (which is an AutoHotkey script turned to .exe). when i launch the program from the command line the error does not happen. strange, eh?!

_argos

I ran it from the command line and got the error. :confused:

[_argos]

I ran it from the command line and got the error. :confused:
Ok, screw my theory. seems it'll happen random. :devil:

[jul059]

Hey.

Once again Hank does a brilliant job. Guys please remember, Hank does this in his free time so lets appreciate his work.

Suck up !!!!!!!!!!!! :-)

Hank: When encoding PAL movies with a low bitrate ( Ave:1600 Max:4000 ) I get a brilliant picture and a 90 min movie to +- 1.2 Gig. However I noticed night areas with a minimum difference in color cause blocky playback ( PC with WinDVD through a TV out ). Could it be the matrix ( HVSBest ) ??

I actually got a simillar scenario as yours and as urvieh's, but with medium bitrates. There is abnormal blocking on certain scenes (molsty darker but not necessarly black background) when I encoded the movie Hitch. I used the default matrix from HC for everything except menus and extras (which were 33% decreased in quality and used BACH1). the extras are actually VERY blocky, I would say much more than 1000 kbps MPEG1.

I can give more information if needed.

[Kika]

What encode mode do you use? 2pass or single pass?
At single pass, sometimes the constand quantizer itself is the problem. And there's not much you can do.
At 2pass, you can change the VBR behavior to get better results.

[jul059]

I always use 2 pass with the profile best. My matrix for the movie was HC default (I don't know if it's any good. Is it?). for the extras, BACH1. DC and GOP use the DVD-RB defaults. What exactly did you mean by changing the VBR behavior?

[Kika]

What exactly did you mean by changing the VBR behavior?

VBR bias
Set it around 20-40 and you will get better results in low motion/low contrast scenes.

[Prodater64]

I got a Visual Fortran run-time error twice, with same source:

http://img150.imageshack.us/img150/473/screenshot7gv.png

What is this?

[PJones2101]

I actually got a simillar scenario as yours and as urvieh's, but with medium bitrates. There is abnormal blocking on certain scenes (molsty darker but not necessarly black background) when I encoded the movie Hitch. I used the default matrix from HC for everything except menus and extras (which were 33% decreased in quality and used BACH1). the extras are actually VERY blocky, I would say much more than 1000 kbps MPEG1.

I can give more information if needed.


Hi jul059 - Help would be appreciated PLEASE.
Here are the settings I normally use.
Bitrate Ave : 1600
Bitrate Max : 4000
DC Precision : 10
CPU : SSE3
Scan Method: ZigZag
Matrix: HVSBest
Profile: BEST

As stated by you and me :-) The light areas come up perfectly, however the dark areas, if the colors are closely the same, gets blocky.

You are welcome to contact me via EMail directly - if we are allowed to post an EMail address here.

[Fishman0919]

Hi jul059 - Help would be appreciated PLEASE.
Here are the settings I normally use.
Bitrate Ave : 1600
Bitrate Max : 4000
DC Precision : 10
CPU : SSE3
Scan Method: ZigZag
Matrix: HVSBest
Profile: BEST

As stated by you and me :-) The light areas come up perfectly, however the dark areas, if the colors are closely the same, gets blocky.

You are welcome to contact me via EMail directly - if we are allowed to post an EMail address here.

The matrix you are using (HVSBest) is compressing to much with the dark scenes and causing the blocks most likely, try BACH1 (it's a little better with the dark scenes and great for encoding around 1000 to 1800k)it will help with the dark scene blocks... also try DC Precision 8, with as low of a bitrate you are using it will also help... setting VBR Bias to high with a low bitrate can hurt more then help, with the avg and max bitrate you are using the default setting is probably the best way to go.

[gigah72]

is it possible to implement or use such an auto matrix option in hc encoder like inautoqmat?

[SAPSTAR]

is it possible to implement or use such an auto matrix option in hc encoder like inautoqmat?
You can use QMatOp...it's not as good/fast as the version implemented in AutoQmatEnc ...

[hank315]

I got a Visual Fortran run-time error twice, with same source:Seems HC tries to write or read from unit 23 (database file) which doesn't exist.
Could you give some more info about your encoding settings.

@jul059
2 questions:
- is playback the same on your PC and HW player for those scenes
- what is the average bitrate for these scenes

[jul059]

@hank315

yes, the playback is pretty much the same on both my hardware (Panasonic RV31) and my computer (both nero showtime and winDVD).

for the average bitrate, the only way I thought about is reading the values given from SmartRipper (because I have deleted the .m2v files...) and I got extremely strange results:

average bitrate is 456 kb/s for the main movie!!!!

the extras are all around 200 kp/s.

I don't understand, the DVD is full and the resulting files were almost oversized (but fitted just right on a DVD). maybe it's just SmartRipper. If you could give me another way, maybe I could check the "real" bitrate...

anyway, here's a screenshot of one of the extras: http://img110.imageshack.us/img110/2713/badblocks4fw.th.png (http://img110.imageshack.us/my.php?image=badblocks4fw.png)

[Mug Funky]

try bitrateview :)

[Kika]

@jul059

That's the result of high quantisation at low Bitrate (or too low bitrate only).
This often happens if the Matrix is one of those optimized for high compression (Bach1, as an example).
Playing around with the Matrix isn't as effectiv as using good settings for Bitrate. Like i wrote: Change the Settings for VBR bias to get a higher Bitrate in such parts of the Video.

[PJones2101]

Thanks to all for the advice - I know my rates are very low but HC does such a great job.

Anyway, Im going to spend a few days trying all the advice.

[jul059]

@jul059

That's the result of high quantisation at low Bitrate (or too low bitrate only).
This often happens if the Matrix is one of those optimized for high compression (Bach1, as an example).
Playing around with the Matrix isn't as effectiv as using good settings for Bitrate. Like i wrote: Change the Settings for VBR bias to get a higher Bitrate in such parts of the Video.

indeed, I think you were right. The average quantisation on the extras is extremely high: around 17, while the bitrate is around 1400. (thanks Mug Funky for bitrateviewer!)

but that doesn't explain why I get abnormally blocky (but not unwatchable) scenes in the main movie, where the average bitrate is around 3400.

Also, is there a way in DVD-RB to automatically change the VBR biais on the extras?

[Kika]

but that doesn't explain why I get abnormally blocky (but not unwatchable) scenes in the main movie, where the average bitrate is around 3400.

Always look at the Bitrate AND the quantisation. HC acts very similar to TMPGEncs new 2pass Mode. If you are interested in some testings, try TMPGEnc with the old(!) 2pass Mode. After that compare the encodings with Bitrateviewer and look at the image quality. I know the result right now: in some scenes, HC will do the better job, but in some scenes, TMPGEnc will be the winner. And with the data from Bitrateviewer, you can see, where and what the problem is.

[Rumbah]

In the German Cuttermaran Forum a user also got the error message:

Die Anweisung in "0x09168bfc" verweist auf den Speicher in "0x09043628". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.

He has a P4 3Ghz HT on WinXP SP1 with Avisynth 2.55 and XVid 1.03. As I thought it might be something with the YUV Codec (Cuttermaran delivers YUV avi), I suggested that he might try the Helix YUV codecs. So he deinstalled XVid and installed the Helix codecs and everything worked fine. Then he deinstalled the Helix codec again and installed Xvid and the error was there again. He didn't try to install Xvid and the Helix codecs, so I cannot say about that. So the error could be between Xvid and HC. So you guys with the error could perhaps try the Helix YUV codec and report if it works for then.

Rumbah

[Amnon82]

Is there a switch for the batch-version of HC to enable"check max br"? I hope with this HC doesn't go over the max bitrate anymore. ... will be helpful for AutoCQ.

[manolito]

Is there a switch for the batch-version of HC to enable"check max br"? I hope with this HC doesn't go over the max bitrate anymore. ... will be helpful for AutoCQ.
It's not a switch, it is a different parameter in the HC.ini file (introduced in version 0.15). Instead of "*CQ" you have to specify "*CQ_MAXBITRATE".

Cheers
manolito

[LigH]

According to katjarella, HC encoder works well with AviSynth 2.56 b4:

Example picture (http://katjarella.gleitz.info/sub/hc15beta.jpg)

[PJones2101]

Does anybody know of a good Matrix to use for animation. I have South Park episodes in DVD format, however I want more than 4 on a DVD and plan to put 8-10 on a disk.

Thanks in advance.

[LigH]

You may try the Kika matrices. They are included in my collection you can find in the thread about my "Custom Quantizer Matrix Editor" (CQME).

[gigah72]

Does anybody know of a good Matrix to use for animation. I have South Park episodes in DVD format, however I want more than 4 on a DVD and plan to put 8-10 on a disk.

Thanks in advance.

how do you want to put 8-10 on one disc, like create own menu and then author yourself, or what way?

[PJones2101]

Yup.

I have the 8 files in AVI format and will convert to m2v with HC.
I use DVDLabPRO so I'll create my main menu, chapters, episode menu etc with that an imported my convert m2v and ac3 into that.

I just need a good matrix for compressing the animation. I know this is picky ( fussy me ) - but the lower I can get the filesize the better. I test all files compressed on a ATI TV-Out card and on a DVD-/+RW on my DVD player first.

I'm just looking for that extra space.

[PJones2101]

You may try the Kika matrices. They are included in my collection you can find in the thread about my "Custom Quantizer Matrix Editor" (CQME).

OK I must be a complete idiot - well most of the time - can you possible post a link please ( If it's allowed here ).

Thanks in advance.

[LigH]

Okay - for someone who may be too lazy to type "CQME" into this board's "Search" function:

http://forum.doom9.org/showthread.php?t=73666&highlight=CQME

http://www.ligh.de/software/qmatrix.zip

[PJones2101]

I Typed "Custom Quantizer Matrix Editor" instead - I'm just useless.
Thanks, besides, I'm sure you helped someone else as well.

By the way - Awsome tool - Great job and very appreciated.

[LigH]

My fault - it's called "Custom Quantization Matrix Editor" instead. :o Little typo, big fault.

[PJones2101]

Not a problem because it led me to a lot of Matrix's to play with.

If anyone else is looking for Matrix's type "Custom Quantizer Matrix Editor" into the Search box and go through the 5 forums.

[feedback]

@PJones2101
Here is a link to a matrix zip folder. Some included are the same as in LigH's zip but some are different.

Matrix Zip Folder 1. (http://forum.doom9.org/attachment.php?attachmentid=4081)

Regards,:)

[Xesdeeni]

I authored a DVD with two different authoring programs based on an MPEG created with HC. On two DVD players, I get audio (AC3 from the original ATSC stream) with no video. If I fast forward 8x or more, I get individual frames. On two others, and on four PCs I tried, everything is fine. Any idea what could be the issue?

Xesdeeni

[Mug Funky]

interesting. what sort of player was it (if you don't mind my asking)?

[Xesdeeni]

One of the ones without the picture was a Terapin I got at Fry's. The other was my sister's, but I can't recall what type it was (sorry, but not the same--I'll e-mail her and find out). A GE (3-Disc) and a Samsung (VCR+DVD) worked fine.

Xesdeeni

[Xesdeeni]

My sister's is a Phillips Progressive Scan.

Xesdeeni

[video_magic]

WMV3 problem via Avisynth (version 2.56 from July 10th 2005) encoding in HC gui v0.15
What happens is that I create an avs file with this line:

DirectShowSource("c:\atmp\jrmoved\converted\JaMes_Randi__Homeopathy - The Test.wmv", fps=25)
Lanczosresize(352, 288)
ConvertToYV12()

it makes NO difference if I also include the , convertfps=true after the fps=25 or not.

The AVS will play absolutely fine using Media Player Classic and also in Virtualdub v1.6.9
However, when I try encoding the AVS through HC gui v0.15 there is a problem with the first 2 to 9 seconds being duplicated and then throughout the clip it gets even more out of synch between video and audio.

My solution is to put the avs into VirtualDub 1.6.9 and turn it into a HuffYuv avi. I check the Huffyuv and the AVS has encoded to it fine, and then make another AVS of this huffyuv clip to encode it through HC gui :)

This then produces my mpeg-2, but anyway, it looks like an HC with AviSynth issue I think, I have produced several clips using avs from different formats with exactly the same HC settings (it's to put on a DVD compilation) and this is the only one to have this problem, and the only WMV, it's not DRM'd.

Here is the mediaInfo report on the original video:

File size : 75.9 MiB
Format : Windows Media
Overal BitRate : 242 Kbps
PlayTime : 43mn 44s
Title : Horizon - Homeopathy - The Test
VBR Peak : 618725
Buffer Average : 144149

Video #0
Codec : WMV3
Width : 384
Height : 288
Aspect ratio : 4/3

Audio #0
Codec : WMA2
Bit rate : 48 Kbps
Channels : 2
Sampling rate : 44 KHz

[Delphin]

I have an idea for a unique feature that I think would set HC apart from ALL other MPEG2 encoders.

A fast capture feature using I Frames only, with a 'smart re-encode' feature in HC that would use this pool of I frames to create a standard high compression IPB structured MPEG2 video stream WITHOUT RE-ENCODING THE IFRAMES.

Ok, the "I-Frame only" thing has been done before (I have an old ATI 'all in wonder' card which does that).

Where they dropped the ball, was that there was no 'smart render' feature provided with the tools to do a minimum-loss re-encode of the resulting stream without re-encoding the I frames.

I found the "I frame only" MPEG2 captures to be very comparable to MJPEG (no surprise there), so this would allow analog captures without using the huge amounts of drive space required by the HUFFYUV codec.

I would approach this with a two part stratagy . . .

1. Write an " I-Frame AVI codec " which could be used for capture and editing.

2. Add 'smart render' support to HC for 'minimum-loss' re-encoding of these I-Frame only files.

The AVI file could also be edited more efficiently since it would contain all I frames (equivelent to AVI codec 'key frames'), and unlike MPEG or MPEG2, 'smart rendering' such a file (rendering only changed frames) would be trivial, since we would not have to mess with any complex GOP structures.

The idea here is not to speed up HC (though I would expect a tiny improvement since HC could just pick rather than encode the required I frames), but rather to eliminate the lossy MJPEG format as an intermediate format and facilitate high quality 'direct to MPEG' captures from analog sources.

This approach to analog capture would give the 'best of both worlds' in that we would get the speed of MJPEG (with an I-frame only capture codec) and then could do a truly optimal minimum-loss translation of the resulting file into a full IBP structured MPEG2 file by taking advantage of the better bit allocation and motion search capabilities of a non-realtime off line encoder like HC.

Sadly I know that 'analog capture' and 'editing' features may not be on the high priority list for a lot of forum members who are ONLY concerned with how they can, make more efficient copies of existing DVD material (though we all assume that this is for the nobel purpose of making 'fair-use' backups of their own legally owned DVD's :)

On the other hand I suspect that some members who are captureing from older analog sources or who are involved in the creation and editing of original content would find a "I-Frame AVI codec" and associated 'smart re-render' feature in HC to be INCREDIBLY usefull.

If Hank is not interested in this even for his 'blue sky' future features list, then maybe I should toss it over to NIC for inclusion in QuEnc (since he has worked with the Xvid binaries and should have some experence with AVI codec code).

In any case I would hope that regardless of who creates the I-Frame AVI codec, that HC would support a 'smart re-render' mode with that codec as the source (in addition to the current AVS source).

A good quality "I-Frame AVI codec" would actually fill TWO important needs, because most of the decent MJPEG codecs cost money, so we would not only get 'optimal re-encode' to mpeg, but some might users might want to use it as a jumping off point for XVID or DIVX encodes (as an alternative to MJPEG).

If the DCT and Quantization Coefficients are flexibly defined in the proposed “I-Frame AVI” container format, then the same files could be used for optimal 'minimum-loss' transcoding to MPEG4 as well as MPEG2 by simply selecting suitable I-Frame codec settings before capture.

Just a thought . . .

[Revgen]

I have an idea for a unique feature that I think would set HC apart from ALL other MPEG2 encoders...


Do you think that all of these "smart" features will turn out a DVD compliant MPEG2 stream?

If so, then I would be interested in seeing it done.

[Delphin]

Do you think that all of these "smart" features will turn out a DVD compliant MPEG2 stream?

If so, then I would be interested in seeing it done.

The idea is NOT to have an AVI codec which DIRECTLY encodes a MPEG compliant stream, just use this as a good INTERMEDIATE format (like the current AVS signpost file input) when doing ANALOG CAPTURE.

For any of a number of reasons, trying to encode a compliant MPEG directly into an AVI container would be a problem, but that’s not what I am talking about.

The idea it to have a AVI CODEC which captures nothing but I-Frames (in a DVD compliant format) right from the start, then later when the HC encoder does motion search and bit budgeting, it would decide which frames need to be I-Frames and which frames need to be dropped and replaced by B or P frames. Then the I-Frames at least can simply be taken from the already encoded stream.

The B and P frames in all MPEG streams (including DVD compliant ones) reference back to the I-frames ultimately, so avoiding a re-encode of these frames should improve quality for the whole MPEG stream by using I-frames which were themselves directly encoded from the ORIGINAL VIDEO SOURCE (during the AVI capture operation).

Of course the frame order gets juggled in assembling a GOP but that would all be taken care of by HC during it’s post processing compression phase (just as it is now).

So all of the really critical formatting would be taken care of in ‘non-real time’ as part of the MPEG2 encoding step (again, just as HC does it now), so the ‘DVD compliance’ of the stream would ONLY be dependant on the care with which HC assembles the final M2V elementary stream (not the nasty old Microsoft AVI format of the captured I-Frames:)

So the short answer to your question is that it should have NO IMPACT on the "DVD compliance" of the stream. The flexibility is still there to do whatever is needed to insure that full GOP structure is correct and that the right bits go in the right places in the final output M2V file.

[Revgen]

...So the short answer to your question is that it should have NO IMPACT on the "DVD compliance" of the stream. The flexibility is still there to do whatever is needed to insure that full GOP structure is correct and that the right bits go in the right places in the final output M2V file.

Sounds good to me. :)

As long as the whole complete process results in a playable DVD with great quality, then I'm all for it.

[LigH]

I remember another MPEG2 I-frame AVI codec - made by Etymonix.

And you might probably even get ffdshow's VfW interface to write MPEG frames into AVI output...

[Delphin]

I remember another MPEG2 I-frame AVI codec - made by Etymonix.

And you might probably even get ffdshow's VfW interface to write MPEG frames into AVI output...

Yes thanks for reminding me, I had stumbled upon that link before but lost it.

http://www.justdosoft.com/Etymonix-MPEG2-Video-Codec-15066.html

The reason I wasn't more enthusiastic about this particular "I-Frame" codec is that the performance they are quoting is no better than I get with the FREE HUFFYUV codec if I let it do color space conversion to YUV.

This is because they apparently are not Truncating the Quantitization of the I-Frames at all, so we only see a SMALL amount of compression due to the DCT, Runlength, and Huffmen coding (pretty much the same as Huffyuv which is free and also does Huffmen coding). This is like saving a JPEG at 100 percent quality (which gives GREAT quality, but eliminates most of the advantages of the compression).

Also it costs 50 dollars which is the same problem which afflicts most of the MJPEG codecs out there (too damn expensive for what it does).

Maybe I'm a little cheap, but paying 50 bucks for a MJPEG Codec (or this Codec) seems a little strange when HC, QeEnc, Xvid and some versions of DivX are Free.

Kind of like living in a world where a 12 course Banquite with Lobster, Filet Mignon (and Baked Alaska for desert) is FREE but a BIG MAC cost 50 bucks. :rolleyes:

The I-Frame codec I am talking about would apply the I-Frame COMPRESSION appropriate to the data rate and quantitization that is to be applied to the final IBP frame encoded file by HC in it's last pass, giving HC a source of already properly compressed I-Frames on the one hand, and saving a huge amount of disk space on the other hand.

This would be MUCH more disk space efficient while remaining essentially 'lossless' in a 'no additional degradation to the I-Frame' sense verses a true lossless codec like HUFFYUV or the Etymonix codec you pointed out.

Let's lay it out . . .

Current lossless capture:

1. YUV color space Capture 100% quality (minus minor color space conversion hit)

2. Huffyuv codec giving huge intermeadiate file

3. HC encodes compressed I-Frames and B,P frames (which point to these frames) based on the LOSSLESS Huffyuv AVI file.

Result: Very good quality with HUGE intermediate file.


Current LOSSY CAPTURE:

1. YUV color space Capture 100% quality (minus minor color space conversion hit)

2. MJPEG codec giving barely manageable file (still very large because quality must be set very high to avoid messing with later MPEG2 encode).

3. HC encodes compressed I-Frames from already compressed MJPEG frames, B and P frames also point to these doubly compressed frames.


Proposed 'Quasi-Lossless' I-Frame CODEC Capture:

1. YUV color space Capture 100% quality (minus minor color space conversion hit)

2. AVI "I-Frame CODEC" pre-encodes properly compressed I-Frames with compatible DCT quantitazition based upon the HC profile to be applied in the post processing MPEG2 encoding passs. This will give a smaller intermediate file even than MJPEG because the 'quality' level of the encoding does not need to be set to a very high 'overkill' setting like MJPEG to avoid degrading the final output, but is rather set to EXACTLY the value used in the final HC encode.

3. HC uses the I-Frame which were pre-encoded straight from the uncompressed YUV capture device to encode the MPEG2 file.

RESULT: Smaller files than practical MJPEG encoding, with about THE SAME QUALITY AS HUFFYUV (because all I-Frames used in the final MPEG2 encode were pre-encoded losslessly directly from the ORIGINAL capture source).

There are some implications to doing the motion serch on the compressed I-Frames vs. the uncompressed YUV converted sources but overall I think we are talking about SMALLER CAPTURE FILES THAN MJPEG, WITH QUALITY ROUGHLY EQUIVILENT TO HUFFYUV LOSSLESS.

[winny]

Has anyone seen an issue where HC encoder shows the "input statistics" line counting down from 10 to 0 and says "ERROR, can not process AVS file"?

Because the file is not processed it causes dvd rebuilder to report an expected m2v file is missing.

please forgive the double post as this was originally raised in the rebuilder forum, however the problem may be more relevant here.

rebuilder thread:-
http://forum.doom9.org/showthread.php?p=684630#post684630

i have only seen this issue on one disk out of many, the rest have worked flawlessly with HC.

Many thanks,
Winny

[vladislav67]

Hahk , in 3 pass will better encoding..
Will is added in new version 3 pass?
Otherwise your coder is very, very good .

Best regards ,
Vlad

[dragongodz]

Hahk , in 3 pass will better encoding..
please go to page 5 of this thread and read from there.

[vladislav67]

Thanks ,
Has read .

Waits 3 pass encoding .
Will or not will?

[LigH]

(here) (http://forum.doom9.org/showthread.php?p=650531#post650531)
ATM I'm not planning to do more than 2 pass encoding.
Think it's better to optimize the 2 pass encoding than to come up with a multipass encoding...


In short terms: "It is obviously not necessary."

[TheSeeker]

I am running RB v1.0 RC2, HCbatch v0.15, dgdecode.dll 1.10, avisynth 2.55. I have been getting oversized output from rb + hc combo lately. It comes out to be right around 4.5 GB almost every time for almost any dvd. I run it through with cce + RB, and the output is 4.32. I have never ever touched the target sectors hidden setting. I was using hc v0.14 and had perfect output, its only with v0.15 that Im getting this oversizing. Just wondering if there is something I should look at? Maybe I should tweak the target sectors setting to be lower if Im going to use HC?

If I do decide to try and play with the target sectors setting. How do I change sectors into MB so I can approximately reduced the target output by like 150 megs?

EDIT: This most recent oversizing was with Samurai Champloo vol. 3

[jdobbs]

Each sector is 2K, so 512 sectors is equal to one megabyte.

Don't try to fill the disc completely -- always leave a little space as a buffer.

[TheSeeker]

Thanks jdobbs. Curious, is there an HCTargetSectors hidden setting? What do you think may be some possiblities as to why hc 15 is oversizing for me and not for everyone else?

[jdobbs]

Yes there is. Not sure what may be causing the oversizing, but sometimes matrix selections can affect size.

[TheSeeker]

Yes there is. Not sure what may be causing the oversizing, but sometimes matrix selections can affect size.

But the strange this is that I use the exact same matrix settings for HC and CCE. And CCE output comes out just perfect.

I wonder, I heard something about the defualt vbr bias setting being different in HC v0.15 than it was in v0.14. Could that be the cause? I dont see how but...

[feedback]

I use Avisynth 2.56, build: Jan. 31, 2005 [21:37:08] with DVD-RB Pro.
HCTargetSectors=2261000. I don't usually have an oversize problem with HC_15 untill I use a different and sometimes quite different Matrix ie., one made for Xvid not mpeg2 (I like to experiment with Matrices). So, as jdobbs indicated the Matrix choice can have a profound effect on the size of output.
Curious, is there an HCTargetSectors hidden setting? :confused:
Look in the Help section of DVD-RB under the Hidden Options heading.

Regards,:)

P.S. I use the 64bit floating point in the AVS options. Also, maybe you should update to Avisynth 2.56 the version I indicated above. It works for me.

Edit: Added P.S.

[TheSeeker]

Maybe I will try all default matrice settings in DVD RB then. The only change I made was to use the Bach1 matrice for very low bitrate < 2MB, and for extras.

I also use the 64 bit floating point iDCT in avs settings. Is the version of avisynth 2.56 the release version or is it still beta?

[feedback]

It has been months since I installed it, but it probably is still beta.
However, it is stable for me.

Also, I think LigH indicated a stable beta version of avisynth 2.56 further up this thread for HC_15.

Regards,:)

[TheSeeker]

I used a different matrice on that Samurai Champloo vol 3 and now hc gives a perfect 4.32 gb output. The matrice I used was a customized (by me) version of the Y.A.C.Q.M. v2 (ANIME) matrice:

08 08 08 08 08 08 08 08
08 08 08 08 16 16 16 16
08 08 08 16 16 16 16 16
08 08 16 16 16 16 16 32
08 16 16 16 16 16 32 48
08 16 16 16 16 32 48 80
08 16 16 16 32 48 80 99
08 16 16 32 48 80 99 99
16 16 16 16 16 16 16 16
16 16 16 16 16 16 16 16
16 16 16 16 16 16 16 32
16 16 16 16 16 16 32 32
16 16 16 16 16 32 32 32
16 16 16 16 32 32 32 64
16 16 16 32 32 32 64 80
16 16 32 32 32 64 80 99

Worked rather nicely on the higher bitrate anime source (avg bitrate was around 5000 i think).

[LigH]

Dear hank,

please don't mind - but may I remind you?

Chapters (forced I-frames with closed GOPS) will be in the next version I think.
Tried to implement it but still have some problems to get it to work with the scene change detection.
It would be nice if you could report a little bit about your success towards this feature. Some girl is waiting eagerly... ;)

Also, katjarella would really appreciate a closing I-frame, most probably because this makes end-of-movie DVD navigation tricks easy, I'd guess.

Hope to hear from you again (and also, that you had recreating holidays, maybe). ;)

[hank315]

@LigH
Returned this weekend from a 3 week holiday...
About the implementation of forced I-frames, that's finished now and can be used with all other options.
Will have a look at a closing I-frame also.

But first have to read 3 weeks of forum posts :)

[Videostream]

Hello

I'm using HC with Cuttermaran (DVB-T).
I got the same error message:

Die Anweisung in "0x084c9294" verweist auf den Speicher in "0x084f3a10". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.

XVid is installed.
Installed yuvcodecs-1.2.exe like Rumbah mentioned.
Error is gone.



Have the same problem like Xesdeeni.

Pioneer DV-444 only AC3 audio. Picture is pink and green.
I was skipping chapters but no good picture any were.

Scott 837 picture and audio ok.

Keep in mind HC is used with Cuttermaran.
Not the hole movie is encoded with HC. Only some GOPs !

With Tmpgenc Picture is ok on both Pioneer and Scott.


Encoded a DVD from a avi with HC same problem.
Pioneer no picture Scott ok.
This time the hole video was encoded with HC.

How do I analyze / compare the video mpeg stream. Tools?
There is something different between those two mpeg streams.
But there is only a small different.
Maybe header information, time step...
I 'll compare a short mpeg video stream.
Same source (DVB-T).
One cut with HC and one with tmpegenc.

[Zeul]

@Hank315
Perhaps you could cast a look over this thread.
http://forum.doom9.org/showthread.php?p=693999#post693999

[Cabal2000]

Hey Hank

Just dropping a little note to thank you for HC encoder and keep up the good work. I myself use it on everything now with DVDRB and I think its the best thing out there!!
YOU THE MAN!!!!!!!!
:stupid:

[deets]

yep i also want to thanks you, ive just been playing around with it and i am alreayd a fan :)

[hacbao]

i'm a newbie,
just 2 questions:
1. Which encoder device gives the best quality "QuEnc" or "HcEnc"?

2. Which one is the fastest encoder?

[LigH]

"Depends on the settings." - In my opinion, HC might be able to produce better quality for comparable HQ-oriented options.

Expect to be striked for violating forum rule #12, probably...

[Mug Funky]

Also, katjarella would really appreciate a closing I-frame, most probably because this makes end-of-movie DVD navigation tricks easy, I'd guess.

hmm. i find it not too difficult to just put a GOP of blank frames at the end if you need a closing chapter point (so you can skip right to the end of a feature) and place a chapter point there.

DVD players might behave unexpectedly if there's a chapter with a length of 1 frame (not sure, but i think there's a minimum chapter length?)

[hacbao]

I just tried QcEnc" out with avi2dvd and the "image" size was only 1.34 GB instead of the expected 4.45 GB. The video was supposed to be 1h44ms long; however the .vob file was only 32ms long after the process finished.

What happenned?
Original file:
.avi file is 1.36 GB which is 1h44ms long
resolution 800x448
audio bit-rate 448,000 hz with AC3 5.1
.srt file 106kb

I got an error message of "can't locate .........memory"

Can some experts help me out?
Thank you.

[LigH]

:( Incompletely posted error messages will result in incomplete answers.

BTW:

- The AVI resolution is not DVD compatible.
- Bitrates are reported in "bits per second", not in Hertz.
- We don't even know if the video source could be read by the encoder successfully, input and output are unsure.

[hank315]

HC update: HC015A

This update has only one new feature: chapter support

An I-frame is inserted at these chapter frames and the GOP is closed so the video can easily be cut at these frames.

The GUI version can import a chapter list from a file which should look like this:

*CHAPTER 5
10000
12000
15000
18000
21000

These lines can also be used in the ini file for the batch version.
Max. nr of chapters is 1024.
NOTE: HC frame count start at 1

For Katjarella: also added a new command to end the encoding with an I-frame: *LASTIFRAME
This can also be set in the GUI version and is the same as setting a chapter point at the last frame.

Get it at http://hank315.dyndns.org/HC_015A.zip

[Zeul]

I think i speak for everybody in thanking hank315 for this new release. :D

[jdobbs]

Hear, hear!

[urvieh]

@hank: Motion vectors? :-)

[hank315]

@urvieh
Will PM you about it.

@Delphin
Please check your PM.

[katjarella]

Thank you, hank, for this new feature!
Unfortunately, I have to calculate a lot...
The parameter "*FRAMES start end" is based on 1 in HC, but on 0 in AviSynth. But for *CHAPTER, the I frame seems to be inserted one frame too early.
Example:

*CHAPTER 6
75
78
375
378
450
453

Resulting m2v:
Frame 74 (0:00:02.960) [I]
Frame 77 (0:00:03.080) [I]
Frame 374 (0:00:14.960) [I]
Frame 377 (0:00:15.080) [I]
Frame 449 (0:00:17.960) [I]
Frame 452 (0:00:18.080) [I]

But that's not too hard, as long as there are pocket calculators (or calc.exe) :)

Thank you so far. Katjarella

Edit: Furthermore, *LASTIFRAME seems not to work for me. :(

HC.ini*infile F:\Doom9\DVD_SlideShow\schmetterling04HC.avs
*outfile F:\Doom9\DVD_SlideShow\schmetterling04HC.m2v
*logfile F:\Doom9\DVD_SlideShow\schmetterling04HC.log
*bitrate 4000
*maxbitrate 9000
*matrix hvsbest
*profile best
*aspect 16:9
*bias 0
*SCANMETHOD ZIGZAG
*closedgops
*dc_prec 10
*NOSCD
*LASTIFRAME
*CHAPTER 18
75
78
375
378
450
453
750
753
825
828
1125
1128
1200
1203
1500
1503
1575
1578
*WAIT 30
HC.log:==================================================

---------------------------------------------
| HCbatch - MPEG2 encoder - rel. 0.15A beta |
---------------------------------------------

input: f:\doom9\dvd_slideshow\schmetterling04hc.avs
output: f:\doom9\dvd_slideshow\schmetterling04hc.m2v

--------------------
| encoder settings |
--------------------

profile: BEST
frames: 1 1875
framerate: 25.00
aspect ratio: 16:9
bitrate Kb/s: 4000
max. bitrate Kb/s: 9000
closed gops: yes
VBV check: yes
scene change det.: no
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 0
chapter frames: 19
time code: 0 0 0 0
CPU: SSE2
matrix: HVSBEST

--------------------
| source stats |
--------------------

nr. of frames in source: 1875
width*height: 720*576
fps: 25.00
nr. of frames to encode: 1875
frames to encode: 1 - 1875

---------------------
| encoding - pass 1 |
---------------------

pass 1 encoding time: 0:03:35 (215 s)
average fps: 8.7

--------------------------------
| encoding - intermediate pass |
--------------------------------

bitrate set to: 4000000 b/s
est. outfile length: 36621 kB
intermediate encoding time: 0.0 s

---------------------
| encoding - pass 2 |
---------------------

pass 2 encoding time: 0:03:10 (190 s)
average fps: 9.9

------------------
| encoding stats |
------------------

total encoding time: 0:06:47 (407 s)

intra matrix used
8 16 16 16 17 18 21 24
16 16 16 16 17 19 22 25
16 16 17 18 20 22 25 29
16 16 18 21 24 27 31 36
17 17 20 24 30 35 41 47
18 19 22 27 35 44 54 65
21 22 25 31 41 54 70 88
24 25 29 36 47 65 88 115

non-intra matrix used
18 18 18 18 19 21 23 27
18 18 18 18 19 21 24 29
18 18 19 20 22 24 28 32
18 18 20 24 27 30 35 40
19 19 22 27 33 39 46 53
21 21 24 30 39 50 61 73
23 24 28 35 46 61 79 98
27 29 32 40 53 73 98 129

nr. of gops: 135
nr. of frames: 1875
nr. of I-frames: 135
nr. of P-frames: 625
nr. of B-frames: 1115
average quant (non linear): 2.677
VBV underflows detected: 0
VBV underflows fixed: 0
minimum bitrate: 1940
maximum bitrate: 8986
average bitrate: 4000

Bild: http://katjarella.gleitz.info/advMenu/HC.png

[Zeul]

kartjarella

I'm not so sure. Frame 75 = frame 74 when based off frame 0.
The HC log shows 19 chapters, you scripted 18. Would that not be 18 + lastiframe?

[hank315]

Hm... did some tests and it seem to work OK.
The LASTIFRAME command just puts a chapter on the last frame so in your case it reports 18+1=19 chapters just as Zeul said.

Will have a look at it... tomorrow :)

[katjarella]

The Last Frame of schmetterling04HC.m2v is Frame 1874 (0:01:14.960) [P] :(

[hank315]

@Katjarella
You're right, LASTIFRAME doesn't (always) work.
Quick fix:
1) for your testcase, add *FRAMES 1 1875
2) or set a chapter at the last frame

Why it doesn't work, if the FRAMES command isn't present HC sets the endframe to 0
so it knows all frames have to be encoded, in your case a chapter point was set at frame 0...
Will fix it in the next release.
Seems to work OK in the GUI version.

[LigH]

One more problem - after katjarella reported it to me, I checked it as well, same behaviour for me:

Encode a script once completely. Then right afterwards, try to encode the same again (and have HC overwrite the output): HC_GUI 0.15A just disappears.

[LigH]

Dear hank,

katjarella discovered another problem. But this does not need to be the fault of HC, it may be related to AviSynth more probably.

katjarella likes to convert several different media files using DirectShowSource. The videos get resized and trimmed. Using the default syntax (omitting the implicit "last" clip variable), the problem here is that the Trim() function does not work well from the beginning, the first frames appear in the final movie although they should have been trimmed away.
DirectShowSource("movie.ext")
SomeResize(width,height)
Trim(start,-count)
But if she uses an explicit clip variable and repeatedly assigns the result of the functions to a clip variable, the video is correctly trimmed.
movie = DirectShowSource("movie.ext")
movie = SomeResize(movie,width,height)
movie = Trim(movie,start,-count)
return movie
In my opinion, the reason is more related to DirectShowSource and the decoding filters, being reliably able to seek in the file or not, and the clip variable probably introducing some cache. Therefore, this question might be useful to be discussed in the AviSynth forum instead - so I ask for opinions from AviSynth specialists and moderators, too...

She is using AviSynth 2.56 beta 4, but will re-check with 2.55 stable, I hope...
__

And additionally, a few enhancement wishes from katjarella:

HCbatch:
- process priorities
- supporting relative file paths (preferably starting at the current, or at least the INI dir)
- a CLI or(and) INI switch to disable the preview

HCGUI:
- save defaults
- import/export settings from/to INI (yes, I already wanted it, too)

[Wilbert]

Yo,

Check the new dss.dll too: http://forum.doom9.org/showthread.php?t=97976 :)

Btw what kind of extension is it?

[katjarella]

Yo,
Check the new dss.dll too: http://forum.doom9.org/showthread.php?t=97976 :)
Btw what kind of extension is it?
Source Quicktime.mov
Video: Sorenson Video 3; 16,7 Mill.
Audio: QDesign Music 2; 44100Hz; Mono

QuickTime(tm) Decoder Wrapper: NeQTDec.ax v3.2.0.7
NeroDigital / mp4 / avi / mov parser: NDParser.ax v3.2.0.7


I'll check the new DLL ASAP - means: in 5 minutes or 5 hours, depends...

[LigH]

As far as we discussed, the new DirectShowSource didn't help. Furthermore, there are occasional crashes, but not reliably reproducable.
__

One more point:

There are scripts which are "one-shot video sources", e.g. where the author used "DirectShowSource(sourcefile, seek=false)" to avoind desync for variable-fps sources. Several encoders close the video source after the first pass, and open it again for the 2nd pass. HC, unfortunately, tries to rewind - but DirectShowSource fails, and delivers only the last frame (for me), or :scared: the first 30 frames, and then only the last frame.

It should be useful that HC re-opens the video source between the passes, too, to avoid problems with such rare, but possible sources.

But katjarella is still testing, we even discovered "EnsureVBRMP3Sync" and hope that this function helps to avoid "seek=false". A few example movies can be found here:

http://katjarella.gleitz.info/hc/

Example script (uses AVSMonitor):DirectShowSource("F:\Doom9\doom_trailer_072505_qthighwide.mov",seek=false)
ConvertToYUY2()
LanczosResize(688,430,0,40,640,274)
# 24 to 25 fps with blended fields
Changefps(50).assumetff().separatefields().selectevery(4,0,3).weave()
AddBorders(16,73,16,73,color=$E8EBF4)
ShowFrameNumber(x=10,y=26,font="Arial",size=24)
ResampleAudio(48000)
Trim(1000,-500)
MonitorFilter()
ConvertToYV12(interlaced=true)

[Squeeto]

Hi guys,
Just tried HCenc and it looks like it gives good results. Thanks Hank for all the work. I would like to compare it to TMpgEnc but I am not sure which is the proper script for accurate color.
I am taking DV avi video and creating m2v files for dvd.

This one seems to look the best on my laptop:
LoadPlugin("TomsMoComp.dll")
AviSource("D:\hcenc/one.avi")
ConvertToYUY2()
TomsMoComp(-1,5,1)
ConvertToYV12()

This one is next:
LoadPlugin("ReInterpolate411")
LoadPlugin("TomsMoComp.dll")
AviSource("D:\hcenc/one.avi")
ConvertToYUY2()
ReInterpolate411()
TomsMoComp(-1,5,1)
ConvertToYV12()

And this is just slightly worse than the previous:
LoadPlugin("TomsMoComp.dll")
AviSource("D:\Java2Exe\dv2mdvd\hcenc/one.avi")
ConvertToYV12()
TomsMoComp(-1,5,1)

Which is the proper method (least conversion) for something that will eventually be viewed on a tv?

Thanks, Squeeto

[LigH]

(Welcome to the doom9 board.)

Why do you need to deinterlace? A TV set works interlaced, so keep your material interlaced, and encode it interlaced.

You just did not write if you have PAL or NTSC, this is very important for DV video; but because you mentioned Reinterlace411, you might have NTSC...

In fact, your question seems not to be really related to HC, IMHO - it looks more like a general video processing/encoding question, the choice of encoder is less important here.

[Wilbert]

But katjarella is still testing, we even discovered "EnsureVBRMP3Sync" and hope that this function helps to avoid "seek=false".
This only effects audio. Could you try to encode the same stuff to XviD/DivX and see whether there are also frames missing?

That may seem a strange request, but have a look at http://forum.doom9.org/showthread.php?p=681676#post681676 (ok, it seems a bit different).

[LigH]

Using avs2avi in 2-pass mode (had to manually set up 1st and 2nd pass): Result looks fine. I guess that avs2avi closes and re-opens the video sources, to be able to switch the codec parameters.

Using Ateme encavc beta2 in 2-pass mode: Result contains the last frame only. I guess that encavc tries to rewind the video source.

[Squeeto]

>Why do you need to deinterlace?
I am recording video of my kid. In 15 years I will probably move it to some other media where interlacing doesn't exist.

NTSC.

>In fact, your question seems not to be really related to HC.
HC doesn't behave like TMpgEnc (or my older version) and it may have corrections built in that I don't need to correct in the avs script. I don't want to over encode if I don't have to.
I am not sure why HC forces a ConvertToYV12(); I don't think I needed this before with TMpgEnc. I am not sure if I need to ReInterpolate411() as I did with T.
A "filter to correct the improper 4:1:1 => 4:2:2 conversion that seems to occur with some DV/4:1:1 codes".

HC is easier to automate than TMpgEnc with my frontend. If I switch over I want it correctly done. Just thought that this was the place to ask.

[LigH]

The main profile of MPEG-1/2/4 always uses YUV with chroma subsampling 4:2:0. Therefore, HC expects YV12 because it uses YUV 4:2:0 as well (YV12 is almost like "uncompressed MPEG", so to say...).

TMPGEnc is horrible in this case, it always expects RGB24 (as well as its VFAPI plugin system). If you previously had another MPEG material, or PAL DV, it would have to be converted from YV12 to RGB24 (which costs calculation time and quality), and will be converted back to YV12 (which costs again). So usually, Staying within YV12 shall gain speed and a bit of quality; it just makes handling interlaced material a bit tricky.

[Squeeto]

Hi Hank,
I successfully tried HCGUI_015A and HCbatch_014 but HCbatch_015A generates errors and is closed by Windows.

DrWatson:
Application exception occurred:
App: (pid=904)
When: 8/19/2005 @ 23:07:08.890
Exception number: c0000005 (access violation)

*----> System Information <----*
Computer Name:
User Name:
Number of Processors: 1
Processor Type: x86 Family 15 Model 4 Stepping 8
Windows 2000 Version: 5.0
Current Build: 2195
Service Pack: 4
Current Type: Uniprocessor Free
Registered Organization:
Registered Owner:

*----> Task List <----*
0 Idle.exe
8 System.exe
156 smss.exe
180 csrss.exe
200 winlogon.exe
228 services.exe
240 lsass.exe
412 svchost.exe
440 SPOOLSV.exe
472 svchost.exe
500 nvsvc32.exe
516 persfw.exe
556 regsvc.exe
580 mstask.exe
624 SMAgent.exe
664 winmgmt.exe
688 WLTRYSVC.exe
700 svchost.exe
768 explorer.exe
860 BCMWLTRY.exe
964 Apoint.exe
952 AGRSMMSG.exe
1024 ApntEx.exe
1192 wuauclt.exe
812 cmd.exe
904 HCbatch_015A.ex.exe
944 drwtsn32.exe
0 _Total.exe

(00400000 - 07BE4000)
(77F80000 - 77FFB000)
(7C4E0000 - 7C599000)
(77E10000 - 77E75000)
(77F40000 - 77F7C000)
(7C2D0000 - 7C332000)
(77D30000 - 77DA1000)
(71710000 - 71794000)
(77A50000 - 77B47000)
(779B0000 - 77A4B000)
(10000000 - 100E6000)
(74870000 - 74886000)
(78000000 - 78045000)
(77570000 - 775A0000)
(77410000 - 77423000)
(6A8F0000 - 6A910000)
(782F0000 - 78538000)
(70BD0000 - 70C35000)
(08520000 - 08687000)
(55900000 - 55961000)
(6BD00000 - 6BD0D000)

State Dump for Thread Id 0x2d0

eax=00000001 ebx=7ffdf000 ecx=ffffffa9 edx=00000000 esi=0055c338 edi=0012f45c
eip=77e12f5c esp=0012fedc ebp=0012fefc iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246


function: TranslateMessageEx
77e12f3a 0f8540d80200 jne UnregisterHotKey+0xe89 (77e40780)
77e12f40 33c0 xor eax,eax
77e12f42 c20800 ret 0x8
77e12f45 ff742408 push dword ptr [esp+0x8] ss:00ba9dc3=00000000
77e12f49 51 push ecx
77e12f4a e8ce1e0000 call GetKeyState+0x9b (77e14e1d)
77e12f4f ebf1 jmp DrawStateA+0x6e6 (77e1e842)
77e12f51 b89a110000 mov eax,0x119a
77e12f56 8d542404 lea edx,[esp+0x4] ss:00ba9dc3=00000000
77e12f5a cd2e int 2e
77e12f5c c21000 ret 0x10

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0012FEFC 00418EC1 0055C338 00000000 00000000 00000000 user32!TranslateMessageEx
0012FF34 0045D384 00400000 00000000 00132A75 0000000A !<nosymbols>
0012FFC0 7C4E87F5 0012F45C 77FCC35C 7FFDF000 0000021A !<nosymbols>
0012FFF0 00000000 0045D2B6 00000000 000000C8 00000100 kernel32!DosDateTimeToFileTime

*----> Raw Stack Dump <----*
0012fedc bc 57 e1 77 38 c3 55 00 - 00 00 00 00 00 00 00 00 .W.w8.U.........
0012feec 00 00 00 00 00 f0 fd 7f - 00 00 00 00 5c f4 12 00 ............\...
0012fefc 34 ff 12 00 c1 8e 41 00 - 38 c3 55 00 00 00 00 00 4.....A.8.U.....
0012ff0c 00 00 00 00 00 00 00 00 - 58 07 38 08 0c c0 47 00 ........X.8...G.
0012ff1c 06 cd 45 00 30 bd 42 00 - 2a bd 42 00 30 bd 42 00 ..E.0.B.*.B.0.B.
0012ff2c 92 77 46 00 c1 01 0c 00 - c0 ff 12 00 84 d3 45 00 .wF...........E.
0012ff3c 00 00 40 00 00 00 00 00 - 75 2a 13 00 0a 00 00 00 ..@.....u*......
0012ff4c 5c f4 12 00 5c c3 fc 77 - 00 f0 fd 7f 28 11 f4 77 \...\..w....(..w
0012ff5c 75 2a 13 00 00 00 00 00 - 44 00 00 00 18 41 13 00 u*......D....A..
0012ff6c 28 41 13 00 40 41 13 00 - 00 00 00 00 01 00 00 00 (A..@A..........
0012ff7c 64 00 00 00 64 00 00 00 - 00 00 00 00 00 00 00 00 d...d...........
0012ff8c 00 00 00 00 00 00 00 00 - 01 00 00 00 00 00 00 00 ................
0012ff9c ff ff ff ff ff ff ff ff - ff ff ff ff 4c ff 12 00 ............L...
0012ffac 00 00 00 00 e0 ff 12 00 - f0 f2 45 00 10 95 47 00 ..........E...G.
0012ffbc 00 00 00 00 f0 ff 12 00 - f5 87 4e 7c 5c f4 12 00 ..........N|\...
0012ffcc 5c c3 fc 77 00 f0 fd 7f - 1a 02 00 00 c8 ff 12 00 \..w............
0012ffdc 1a 02 00 00 ff ff ff ff - b4 f0 4f 7c c8 8e 4e 7c ..........O|..N|
0012ffec 00 00 00 00 00 00 00 00 - 00 00 00 00 b6 d2 45 00 ..............E.
0012fffc 00 00 00 00 c8 00 00 00 - 00 01 00 00 ff ee ff ee ................
0013000c 02 00 00 00 00 00 00 00 - 00 fe 00 00 00 00 10 00 ................

State Dump for Thread Id 0x2f0

eax=10000000 ebx=00000000 ecx=0851fed8 edx=00270001 esi=00000000 edi=0055cf48
eip=0045fd6d esp=0851fe90 ebp=0851fea4 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246


function: <nosymbols>
0045fd4f 83257441920000 and dword ptr [00924174],0x0 ds:00924174=00000003
0045fd56 c7057041920009000000 ds:00924170=00000002
mov dword ptr [00924170],0x9
0045fd60 83c8ff or eax,0xff
0045fd63 5f pop edi
0045fd64 5e pop esi
0045fd65 5b pop ebx
0045fd66 c9 leave
0045fd67 c3 ret
0045fd68 56 push esi
0045fd69 8b742408 mov esi,[esp+0x8] ss:08f99d77=????????
FAULT ->0045fd6d ff7610 push dword ptr [esi+0x10] ds:00a79ee6=00000000
0045fd70 e824660000 call 00466399
0045fd75 85c0 test eax,eax
0045fd77 59 pop ecx
0045fd78 7477 jz 00467ef1
0045fd7a 81fee0ac4800 cmp esi,0x48ace0
0045fd80 7504 jnz 00463086
0045fd82 33c0 xor eax,eax
0045fd84 eb0b jmp 00467e91
0045fd86 81fe00ad4800 cmp esi,0x48ad00
0045fd8c 7563 jnz 004667f1
0045fd8e 6a01 push 0x1

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0851FEA4 0042BDC0 00000000 004837D0 0055CF48 010D04E0 !<nosymbols>
0851FEE4 0041D897 010D04E0 00000200 07B217C0 07B217C4 !<nosymbols>
0851FF5C 0041875B 00000000 0A0105F9 0055C354 804316BC !<nosymbols>
0851FFB4 7C4E987C 0055C354 00000000 0A0105F9 0055C354 !<nosymbols>
0851FFEC 00000000 00418748 0055C354 00000000 00905A4D kernel32!SetThreadExecutionState

*----> Raw Stack Dump <----*
0851fe90 e0 04 0d 01 89 ce 45 00 - 00 00 00 00 48 cf 55 00 ......E.....H.U.
0851fea0 e0 04 0d 01 e4 fe 51 08 - c0 bd 42 00 00 00 00 00 ......Q...B.....
0851feb0 d0 37 48 00 48 cf 55 00 - e0 04 0d 01 54 c3 55 00 .7H.H.U.....T.U.
0851fec0 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20
0851fed0 20 20 20 20 b4 fe 51 08 - dc ff 51 08 a8 57 47 00 ..Q...Q..WG.
0851fee0 ff ff ff ff 5c ff 51 08 - 97 d8 41 00 e0 04 0d 01 ....\.Q...A.....
0851fef0 00 02 00 00 c0 17 b2 07 - c4 17 b2 07 28 cf 55 00 ............(.U.
0851ff00 48 cf 55 00 4c cf 55 00 - 44 cf 55 00 a4 cf 55 00 H.U.L.U.D.U...U.
0851ff10 80 00 00 00 00 00 00 00 - f9 05 01 0a 54 c3 55 00 ............T.U.
0851ff20 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20
0851ff30 20 20 20 20 20 20 20 20 - 20 20 20 20 30 68 a0 81 0h..
0851ff40 64 7c e5 b9 70 61 73 73 - 65 64 42 80 d4 4b 06 80 d|..passedB..K..
0851ff50 70 61 73 73 65 64 a0 81 - 06 00 f4 77 b4 ff 51 08 passed.....w..Q.
0851ff60 5b 87 41 00 00 00 00 00 - f9 05 01 0a 54 c3 55 00 [.A.........T.U.
0851ff70 bc 16 43 80 30 68 a0 81 - 05 00 00 00 00 00 00 00 ..C.0h..........
0851ff80 00 00 00 00 00 00 00 00 - d6 11 43 80 00 00 00 00 ..........C.....
0851ff90 00 00 00 00 0f 12 43 80 - 60 0d 94 81 a0 66 a0 81 ......C.`....f..
0851ffa0 ff ff ff ff 8f 13 43 80 - 00 00 00 00 00 00 00 00 ......C.........
0851ffb0 00 00 00 00 ec ff 51 08 - 7c 98 4e 7c 54 c3 55 00 ......Q.|.N|T.U.
0851ffc0 00 00 00 00 f9 05 01 0a - 54 c3 55 00 00 d0 fd 7f ........T.U.....

I hope that this is the section that relates to your app.
S.

[Squeeto]

Just found the older HCbatch_015 and it is fine.
It seems that 15a is the only hold up for me.

[DrShrinker]

I successfully tried HCGUI_015A and HCbatch_014 but HCbatch_015A generates errors and is closed by Windows.

Me, too. I have an AMD 64, and HCbatch_015A gives me problems with DVD Rebuilder. I didn't have problems with older versions of HCbatch with DVD Rebuilder. But I did have problems with HC and AVISource, which I brought up earlier in this thread.

[Zyphon]

@Hank315

I know this has been asked a million times and if it has i appologise in advance.

I wanted to test Prodater64's Pro_Calc Lite which uses HC in OPV prediction.

After every sample has finished encoding and the program tries to exit I get this error:

http://img385.imageshack.us/img385/6973/hcerr2zk.th.jpg (http://img385.imageshack.us/my.php?image=hcerr2zk.jpg)

Thanks to ImageShack for Free Image Hosting (http://imageshack.us)

The PC I was testing it on was a Pentium 3 @ 866Mhz with 512MB of memory.

Is this a common problem with others?

It's a shame as I have heard great things about the quality of HC and would love to test it without having to wait by the PC at the end of the encode to press the 'OK' button.

Thanks in advance for anyone who can shed some light on this problem. :confused:

:thanks:

[jdobbs]

I'd suggest you download and try v0.15 instead of v0.15A and see how it goes.

[Zyphon]

@jdobbs

Hi Jerry, I was using the v0.15 and this is the one giving me the trouble.:( I have downgraded to the 0.14 version as Prodater64 suggested and try that.

Thanks for the suggestion anyway. :D

[Zyphon]

Reverting to 0.14 doesn't help either, I get the same error. :(

Maybe HC Enc doesn't like P3's, or maybe I am just unlucky. Oh well. :(

[Rumbah]

For some people it helped to install the Helix YUV Codec (http://www.lillevold.com/files/yuvcodecs-1.2.exe).

[LigH]

Other people installed DivX 5, or XviD, or enabled YV12 conversion in ffdshow's "raw video" processing. No need for outdated simplest micro "codecs" ;)

[Rumbah]

Why is the Helix Codec outdated? It is old, but small and fast and can do everything you want and I never had a problem with it. For some people also deinstalling Xvid and installing another YV12 capable codec helped, but I think installing the Helix codec is the simplest solution. It works and does not interfere with other codecs.

[LigH]

Okay - not really "outdated"; but I presonally prefer a few multi-purpose codecs over many tiny specialized ones. The Helix codec may be one tiny helper codec, being able to convert YV12. The ATI YUV codecs are another alternative of tiny specialized codecs.

But indeed, I never needed them, because DivX 5 or XviD 1.x (correctly installed) already offered just the same functionality, and ffdshow is configurable to support it.

And: How could they "interfere"? With what?

[Rumbah]

Yes, of course you could use Xvid or Divx. But first, there were some versions that did not handle YV12 correctly for example if the dimensions were no multiple of 16. And second, they both do not support saving in YV12.
And for the interference, well, I had some problems having Divx, Xvid and ffdshow installed that sometimes lead to strange results.

[Asmodeus]

First of all I must admit that I didn't read whole thread.
I got one question to hank: is it possible to set fixed quantizer wor each frame type, egz. Q2 for I, Q3 for P, Q4 for B ? or is it possible to implement this in new build.
Thx

sorry for my english

[Pookie]

Wondering about HCenc and HDTV Resolutions. Is it a lot of work to modify HCenc to be able to do 1280x720 @ high high bit rates ?

Regardless, thanks again for this great encoder :)

[Pasqui]

@hank315
When do you expect to release HC016? I'm a bit worried about the non compliancy of MV restriction you talked about in this post (http://forum.doom9.org/showthread.php?p=702377#post702377). Is current version safe to use ?
Thanks for all your work !

Pasqui.

[hank315]

When do you expect to release HC016? I'm planning to release a HC016 batch test version in a week or so.
One of the things that have been changed is the way avs scripts are handled, hope this will solve the crashes some people report.
Also the MV range will be fully MPEG compliant again so the blocky playback on some HW players will be solved.

Wondering about HCenc and HDTV Resolutions. Is it a lot of work to modify HCenc to be able to do 1280x720 @ high high bit rates ?It's quite alot of work but yes, it's one of the things I want to implement but not restricted to 1280x720, max. resolution will be 1920x1152, some day :D

is it possible to set fixed quantizer wor each frame type, egz. Q2 for I, Q3 for P, Q4 for B ?This also will be in one of the future versions but not in the next version.

[Zeul]

I for one am looking forward to the next build. :D

[Marius-the-Mad]

You're not alone. :D

hank315 - thank you again for all your work. HC is amazing. :)


<edit>

P.S. May I have a feature request ? :) How about something like matrix.ini, where we could store additional matrices, which would then be selectable from within the programme ? ;)

[LigH]

In case of need, don't hesitate to ask for specific beta tests, hank. ;)

[Xeno86]

@hank315
And what about resource leak in mode preview in Win 9x? Did you fix it?
Thanks again for your great encoder :)

[john3voltas]

Also the MV range will be fully MPEG compliant again so the blocky playback on some HW players will be solved.

Hi Hank,
I've been using your encoder on a regular basis for quite some time already and may I let you know that I find it wonderful.
But now I see a few remarks that it might not be 100% MPEG compliant and that gave me the creeps.
Does that apply to all HCEnc versions or just the latest version?
Because you see, I'm still using 0.14 ;).
Other than that keep up with such a wonderful work :thanks: .

[Carpo]

i have done many encodes with hanks encoder and my rather picky standalone plays them all - so it should be ok :)

[john3voltas]

@Carpo
I see, but it obvious that HC has compliancy issues otherwise Hank wouldn't have posted such words.
And that scares me a bit.
So I just wanted to know if these issues have been there all the way from the early releases or if they were just introduced in the latest releases.
Cheers

[hank315]

New release, a test version of HCbatch016 only.
Just want to see if it runs more stable now and all options are working OK.
But also some improvement in quality and speed.

link: http://hank315.dyndns.org/HCbatch_016_testrelease_08-09-2005.zip

Changes:

- improved auto gop option
- fixed a bug in Motion Estimation which could cause blocky playback on some HW players
- for fixed GOP 15-1, GOP length sometimes was set to 16-1, fixed
- added bias and dc precision as parameters for HCbatch
- small GUI changes
- as usual some other bugs fixed

Recommended avisynth version: 2.5.6 RC1.
It should work OK with DVD-RB.

[Frameserver]

New release, a test version of HCbatch016 only.
Just want to see if it runs more stable now and all options are working OK.
But also some improvement in quality and speed.

link: http://hank315.dyndns.org/HCbatch_0..._08-09-2005.zip

Changes:

- improved auto gop option
- fixed a bug in Motion Estimation which could cause blocky playback on some HW players
- for fixed GOP 15-1, GOP length sometimes was set to 16-1, fixed
- added bias and dc precision as parameters for HCbatch
- small GUI changes
- as usual some other bugs fixed

Recommended avisynth version: 2.5.6 RC1.
It should work OK with DVD-RB.

Hi hank315,
can you check the link?
Got a http 404 error - file not found.

cu
frameserver

[hank315]

@Frameserver
You're right, didn't work, should be fixed now.

[Frameserver]

@Frameserver
You're right, didn't work, should be fixed now.

@hank315
sorry I don't think so.
But this time server not found or dns error.
Server busy/down? :confused:
I try it later again
cu
frameserver

[jeanl]

Same here, can't connect to hank315.dyndns.org, timing out...
jeanl

[LigH]

@ Frameserver:

hank315.dyndns.org

is usually a PC at home, which gets an IP address for at most 1 day by the Internet Service Provider. Each time a new IP arrives, this new IP must be published to the DNS servers worlswide, this may take some time. Although it may just take minutes... Try regularly each few hours until you got it.

[Zeul]

:)
All d/l and now to try

[hank315]

My connection is very unstable at the moment :(

@LigH
Yes it runs from my home server but I use a static IP, just checked it, it's still the same as in the dyndns database.

Just saw the download counter go up again :) seems I'm back online but the speed is low...

[katjarella]

Unfortunately, still same like under: http://forum.doom9.org/showpost.php?p=698348&postcount=387

I am surprised because it "almost" functioned in the last internal Beta.

see Result: http://katjarella.gleitz.info/hc/

[Darksoul71]

@frameserver:
FYI: Download worked fine 4 me.

-D$

[hank315]

@Katjarella
DirectShowSource is still a PITA :mad:
Sometimes it can not be rewinded to the first frame after the first pass, I tried to unload and load the clip again for the second pass but that didn't work if you use avisynth directly.
I tried a wmv clip with 2800 frames using DirectShowSource, if I let HC encode the whole clip it didn't work, with the command *FRAMES 1 2600 the first 2600 frames are encoded OK.
Seems if DirectShowSource reads until the end something is screwed up.

[jdobbs]

@frameserver:
FYI: Download worked fine 4 me.

-D$Not for me...

[hank315]

Not for me...Strange :confused:

link again: http://hank315.dyndns.org/HCbatch_016_testrelease_08-09-2005.zip

[katjarella]

@Katjarella
DirectShowSource is still a PITA
http://katjarella.gleitz.info/smilies/smilie20.gif YES YES YES.

1: load AVS -> 1st pass -> close avs
and then
2: load AVS -> 2nd pass -> close avs
does not work ?

[jdobbs]

Strange :confused:

link again: http://hank315.dyndns.org/HCbatch_016_testrelease_08-09-2005.zipWorks now...

[Frameserver]

Works now...

Jep - got it too

[jmvolfan]

In testing HC .16 beta with DVDRB Pro I am seeing a strange problem. During encoding HC pops up and encodes a segment but when it starts a new segment it will not start until I click on the program link in my start bar. Once I click on it HC opens on the screen and the encoding begins and runs normally. After is finishes it closes and a new segment is loaded but does not encode until I click on it again.

I am running Win XP Pro SP2 with an AMD 64. I have the latest DVDRB Pro release and using the 3 click method.

I ran the same data with CCE and everything ran fine.

Thanks for the great encoder Hank. Hope this info helps with testing.

[2COOL]

In testing HC .16 beta with DVDRB Pro I am seeing a strange problem. During encoding HC pops up and encodes a segment but when it starts a new segment it will not start until I click on the program link in my start bar. Once I click on it HC opens on the screen and the encoding begins and runs normally. After is finishes it closes and a new segment is loaded but does not encode until I click on it again.

I am running Win XP Pro SP2 with an AMD 64. I have the latest DVDRB Pro release and using the 3 click method.

Though I'm using 0.94, I can confirm that this is happening to me too. I just did King's Ransom R1 back to back. The first one with with v0.15A and the next was v.16 beta (test release). I had no "hanging" problems with 0.15A.

HC Encoder seems to hang alot during the encode process. On numerous occasions, I had to abort the encode and restart at last encode to get it going again. I'm using WinXP Pro SP2.

OS: Windows XP Professional Service Pack 2
BIOS: A M I - 11000306
Motherboard: ASUSTeK Computer Inc. P4P800
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz
RAM: 1024 MB SDRAM
Video: NVIDIA GeForce FX 5700 Ultra

[DK]

is *suppress warning prompts* UNchecked in your rb versions?

[DK]

i didnt test this latest 016 test release before and i do experience the same flaw:

hc stays minimized and does not keep going until i clicked on it


the 016 version you sent me a couple of days ago, hank315, did not show this behaviour and worked flawlessly

[DK]

for anyone interested in testing this latest release with dvd rebuilder, use this workaround:

go to setup and DISABLE *run encoders minimized*

this way hc will stay on top and keep encoding one segment after the other

at least this works for me this very minute

[zambelli]

A question about interlaced encoding:

Do the field order checkboxes in the GUI refer to the field order of the input source or the output MPEG?

I'm encoding DV video to DVD and I'm not sure what to set it to. I know DV is BFF, but I also know most (all?) DVDs are TFF. So should I reverse the field dominance manually in Avisynth, or should I just set this to checkbox to BFF and expect the DVD player to handle it correctly?

[Ebobtron]

@zambelli

BFF TFF settings in HC are used to set flags in the final .m2v.
HC will not change the field dominance.

[Boulder]

A question about interlaced encoding:

Do the field order checkboxes in the GUI refer to the field order of the input source or the output MPEG?

I'm encoding DV video to DVD and I'm not sure what to set it to. I know DV is BFF, but I also know most (all?) DVDs are TFF. So should I reverse the field dominance manually in Avisynth, or should I just set this to checkbox to BFF and expect the DVD player to handle it correctly?
Your standalone should play the video fine even if it's encoded and flagged as BFF, I don't think TFF is mandatory.

[Marius-the-Mad]

I tried the new beta out. There are some problems with the picture, however - some strange blocking artifacts appear. :(

I tried a few decoders and here are the results:


The source:
http://img253.imageshack.us/my.php?image=source341tl.png

ffdshow - libavcodec:
http://img253.imageshack.us/my.php?image=ffav348ts.png

ffdshow - libmpeg2:
http://img227.imageshack.us/my.php?image=ffl2341wc.png

MPC - libmpeg2, AFAIK (please ignore the colour differences):
http://img227.imageshack.us/my.php?image=mpc346lg.png

DGDecode 1.4.4 b3 (based on heavily patched reference decoder):
http://img227.imageshack.us/my.php?image=dg340gn.png


It seems only DGDecode can play the file correctly. I made a sample available here:

http://uploadhut.com/view.php/311163.m2v

And here's the log (hmm... should the number of underruns really be that high ?):
http://uploadhut.com/view.php/311228.log


I haven't watched the film from the start to the end and am not sure whether those black blocks appear in other parts of the frame. :(


I'm using Athlon XP 1700+. Hank, do you need any additional information ?

[Boulder]

What's your script?

[Marius-the-Mad]

The script is not necessarily very sane - I was experimenting both with some functions and new HC. As you can see from the screenshot however, there are no blocks in the source.

LoadPlugin("ColorMatrix.dll")
LoadPlugin("DGDecode.dll")
LoadPlugin("RemoveGrain.dll")
LoadPlugin("MaskTools.dll")
Import("soothe.avs")
Import("pctv_smooth.avs")


AVISource("sw.avi")
s1=last.PC2TV_Smooth()
s2=s1.ColorMatrix(mode="rec.601->rec.709", mmx=false)
s1=s2.BlindPP()
Soothe(s2, s1, 50)
Lanczos4Resize(704,416)
ColorYUV(opt="coring")
Crop(0,0,0,0,true).RemoveGrain(mode=1)
AddBorders(8,80,8,80)

# making the screenshot
#
#Lanczos4Resize(1024,576)
#ConvertToRGB32(matrix="rec709")

[Boulder]

Did you try just feeding the clip to HC without any additional filters? That would doublecheck if it's really an HC issue. I'm not even sure if I can tell what black blocks you mean (wouldn't be the first time though :D )

[Marius-the-Mad]

Hmm... No, not yet. :) And as for the blocks... Look at the right side of the source image, and then try the one decoded with libavcodec. ;)

[Boulder]

The encoded clip shows fine here, I tried PowerDVD, VDubMod and Media Player Classic (Elecard MPEG2 decoder decoded the clip).

[Marius-the-Mad]

So, it seems only libavcodec and libmpeg2 have problems with it, after all. Which is a bit scary nevertheless, because these are probably two the most popular libraries out there. :(

I guess we have to wait for Hank to verify whether the problem lies on the encoding or the decoding side.

<edit> Thank you very much for additional test, Boulder. :)

<edit #2> WinDVD decodes it fine, too.

[hank315]

Well, I played it with:
- PowerDVD --> no problem
- BSplayer (libavcodec) --> wrong
- BSplayer (libmpeg2) --> wrong but not in the same way as libavcodec
- BSplayer (Elecard) --> no problem

MPEG Stream Eye (Elecard) also OK
MPEGAnalyser (don't know what decoder) also OK

This is a strange encode, average non-linear quant = 1.9, so very low.
Seems the source has very little information so the quants must be low to keep up with the required average bitrate.
This also explains why there are so many underflows, with quants between 1 and 2 it's very hard to predict the bitrate...
The MacroBlocks with display errors all have quant=1.

Maybe you should try to encode it again (or only that part) with a lower average bitrate or even better a fixed quant (4 should be a good value for testing).

[Marius-the-Mad]

This is a strange encode, average non-linear quant = 1.9, so very low.
Seems the source has very little information so the quants must be low to keep up with the required average bitrate.
This also explains why there are so many underflows, with quants between 1 and 2 it's very hard to predict the bitrate...The source is not particularly detail-rich, indeed. Thank you for checking the sample, Hank. :)

However, I need a statement from you. :) Could you, please, tell me, whether I should file a bug report to libavcodec developers or wait until you check HC further ? It seems HC outputs fully correct MPEG 2 elementary stream, but I need to be sure - so no one will flame me on ffmpeg-devel. I already found them one problem yesterday. ;)


One session with VirtualDubMod later...

Hank, am I right the maximal GOP length in my sample equals 18 ? HC displayed 18, too, but I wasn't sure it was the correct value, since it's beta after all. If I'm not mistaken, HC beta makes GOPs one frame longer than specified. :(

Sorry for finding a different problem to bug you! :devil: :) And terribly sorry if I managed to set something wrong.

[DK]

@ hank315

the latest016 TR version you sent me, works fne with dvd-rb and option *run encoder minimized* set

[hank315]

Hank, am I right the maximal GOP length in my sample equals 18 ? HC displayed 18, too, but I wasn't sure it was the correct value, since it's beta after all. If I'm not mistaken, HC beta makes GOPs one frame longer than specified.You're absolutely right, it was also the first thing I noticed, and I just fixed it.

Sorry for finding a different problem to bug you!No, thank you for reporting it :)

However, I need a statement from you. Could you, please, tell me, whether I should file a bug report to libavcodec developers or wait until you check HC further ?Uh, a statement from me?
I can only repeat what I saw using different decoders, some decoded it OK, some didn't.
The error can be in HC or in one of the decoders, I just don't know ATM.
Better just encode that part again with a higher quant to be sure.

[Marius-the-Mad]

Hah, OK. :) I'll try to make CQ 4 encode and see what happens. Thanks for the reply! :)

[hank315]

I just removed the HC016 test release from my server.
The issue Marius-the-Mad reported, it is a HC error :mad:
Will report back when it is solved.

[DK]

the latest016 TR version you sent me, works fne with dvd-rb and option *run encoder minimized* set

i must correct myself

after ~65% HC did hang again and again with the rebuilder options active *run encoder minimized*

amazing though that numerous segments worked fine

[jdobbs]

I don't think the hang is coming from the DVD-RB end... it just starts the process and then waits for the end status to be something other than STILL_ACTIVE.

[DK]

agreed; it is not resulting from rb

disabling the option *run encoder minimized*, however solves this "bug" for the time being

[2COOL]

@hank315

Seeing how this official thread used for all versions of HC, perhaps a annoucement post list is suggested? Your thread is up to 455 posts now. :eek: It's better for people who want to peruse the whole thread for posts on a certain version. ;)

Here are some examples of threads I've suggested this.

BeLight (http://forum.doom9.org/showthread.php?p=571527#post571527)
VobBlanker (http://forum.doom9.org/showthread.php?t=92481)
PgcEdit (http://forum.doom9.org/showthread.php?p=683483#post683483)

[Boulder]

I have a small feature request:

Would it be possible to add a prediction engine to the CQ mode? It would make using CQ much easier as one wouldn't need to encode the sample, check the log for the avg bitrate, adjust CQ, encode sample etc.

A simple workflow could be
1) take the desired avg bitrate from the ini file
2) encode a 1-3% sample clip
3) using a simple binary method, calculate the new CQ value
4) encode the sample with a new CQ until the avg bitrate is close enough to the target
5) encode the whole clip
6) if the final result was off the target (a user specified percentage), redo the prediction using the predicted and final avg bitrate for calculating a correction factor (since it's constant quantizer, it should work)

I understand you want to concentrate on the quality and speed for the time being, but it would be nice if you could add the possibility to your to-do list ;)

[Darksoul71]

@Boulder:
Why should OPV Encoding à la D2SBoBa be integrated in the encoder itself ?
IMO thats something frontends such as CCEFront, AutoQ2, etc are for.

I haven´t played around with HC but my AutoIt Implementation for CCE doing Q-Search is only 5 lines of code. This should not be to hard to modify for HC.

-D$

[Boulder]

@Boulder:
Why should OPV Encoding à la D2SBoBa be integrated in the encoder itself ?
IMO thats something frontends such as CCEFront, AutoQ2, etc are for.

I haven´t played around with HC but my AutoIt Implementation for CCE doing Q-Search is only 5 lines of code. This should not be to hard to modify for HC.

-D$
CCEFront does the job correctly, unfortunately for CCE only. CCE doesn't like Didée's LTSMC function at all but usually ends up crashing Avisynth during the prediction phase and also during a 2-pass encode. So far HC hasn't done the same so I figured that LTSMC being a very slow function, it would be useful to have a working CQ prediction, preferably inside the encoder itself as Hank knows the program best.

If you could modify the code and get it working, I'd be more than happy to test it as I encode my captures weekly. The thing I'm missing most is the automated process of correcting the CQ value if the final filesize hasn't hit close enough to the target. I'd be glad to code it myself if I just had the time to start brushing up my old C++ skills again..unfortunately it'll be next year till I get to that :(

[john3voltas]

I haven´t played around with HC but my AutoIt Implementation for CCE doing Q-Search is only 5 lines of code. This should not be to hard to modify for HC.

-D$
Hi Darksoul71,
I am just trying to grasp the basics on AutoIT v3 and I am a big fan of HCEnc.
And I would really like to have an OPV prediction FrontEnd for HC.
So if you could post the source code from your tool maybe I could adapt it to HC.
That is, if you're willing to show the sources ;).
Oh, of course that you might also be interested in doing the HC frontend yourself which would save us all a lot of headaches LOL.
Thanks

[Darksoul71]

@john3voltas:
If you are willing to code, this would "save" me from coding some HCEfront in Delphi.
Here is the code snippet from my tool Komprezz2MPEG which does the prediction.
$CQ = 40

; Do Q-Estimation if OPV encoding selected
if ($EncMode = "opv") Then
$compAVS = $TempPath & "\comp_movie.avs"
$compMPV = StringTrimRight($CompAVS,3) & "m2v"
FileCopy ($FinalAVS, $compAVS)
AddLine ($compAVS, "SelectRangeEvery(1500,15)")

$cWidth = 0
$cHeight = 0
$cFrames = 0

AVI_Info($compAVS, $cWidth, $cHeight, $cFrames)

$CQ = 40
$CQ_Alt = $CQ + 2

While (Abs ($CQ-$CQ_Alt) > 1)
$CQ_Alt = $CQ
GenerateECL ($CompAVS, $CompMPV, $TempECL, $cFrames, $EncBitrate, $CQ, $EncMode, $SourceWidth, $SourceHeight)
RunEclCCE ($TempECL)
Sleep (1000)

$EstSize = (FileGetSize ($CompMPV) * 100) / 1024
$TSize = ($EncBitrate / 8) * $Duration
$CQ = Round ($CQ*($EstSize / $TSize))
WEnd
Endif

Ok, agreed ! I´ve lied. It´s a bit more than five lines <ggg>

But the "core" ist the the while loop. If the quality values for HC Enc are different from CCE, you´ll have to modify the start value. Also CCE´s Q-Value is different from e.g. the Qualitylevel of TMPEGEnc.

Reason:
For CCE a low Q-value means higher quality versus a high Q-value means lower quality. For TMPEGEnc it´s vice versa: A high percent value (e.g. 70%) means higher quality compared to a lower percent value (e.g. 30%).

So if the Q-value of HC Enc would be proportional to the quality (as with TMPEGEnc), you would have to modify the formula:
$CQ = Round ($CQ*($EstSize / $TSize))
needs to be modified to
$CQ = Round ($CQ*($TSize / $EstSize))

The approach of the formula is really simple (Note: I didn´t invent the formula. I´ve just used it. IIRC it was posted over at the DVD-Rebuilder forum when they discussed how to incorporate the D2SBoBa OPV encoding approach into DVD-Rebuilder). The ratio between the estimated filesize (as we only encode a small snippet of the final movie) and the targeted filesize is used as factor for the new q-value. The closer the filesize for the encoding with the calculated q-value gets to your target filesize, the smaller the changes to the q-value will be. Normally this formula converges within 3-4 passes with CCE. Of course not as fast as Newton Raphson, but the sources of D2SRoBa are available. So feel free <ggg>

Oh, there´s one thing I have forgotten: If you do OPV encoding based on your target bitrate rather than your target filesize, you´ll also need to obtain the duration of the movie in second (see my calculation for $T_Size). I use a small Delphi app which I call from my AutoIt script for extracting the relevant informations of the AVISynth files. Not shure how tylo solved this within CCEFront but as Newton-Raphson requires two values to calculate the gradient, my first guess would be that he reads the frame number from the ECL file which CCE generates. If you can live with specifying targetsize only, you don´t need to do this.

Have fun,
D$
Below is the function I use to generate a CCE2.5 compatible ECL-file for encoding.

;++++++++++++++++++++++++++++++++++++++++++++++++++
Func GenerateECL ($Source, $Target, $ECLFile, $Frames, $Bitrate, $QValue, $Mode, $Width, $Height)

$Target = StringTrimRight($Target,4)

If ($Mode = "opv") Then $VMode = 0
If ($Mode = "cbr") Then $VMode = 1
If ($Mode = "mpcbr") Then $VMode = 3

$file = FileOpen($ECLFile, 2)

FileWriteLine($file, "; Cinema Craft Encoder SP -- Encoder Control List")
FileWriteLine($file, "")
FileWriteLine($file, "[item]")
FileWriteLine($file, "title=Generated by Komprezz2MPEG")
FileWriteLine($file, "vid_out=1")
FileWriteLine($file, "vaf_out=1")
FileWriteLine($file, "aud_out=0")
FileWriteLine($file, "vid_file0=" & $Target & ".m2v")
FileWriteLine($file, "vid_file1=" & $Target & ".m2v")
FileWriteLine($file, "vaf_file=" & $Target & ".vaf")
FileWriteLine($file, "aud_file=" & $Target & ".mpa")
FileWriteLine($file, "file_focused=0")
FileWriteLine($file, "encode_mode=0")
FileWriteLine($file, "packet_size=4096")
FileWriteLine($file, "timecode=0x1000000")
FileWriteLine($file, "width=" & $Width)
FileWriteLine($file, "height=" & $Height)
FileWriteLine($file, "vmode=" & $VMode)
FileWriteLine($file, "frame_rate_idx=3")
FileWriteLine($file, "cbr_brate=" & $Bitrate)
FileWriteLine($file, "opv_q_factor=" & $QValue)
FileWriteLine($file, "opv_brate_min=300")
FileWriteLine($file, "opv_brate_max=9000")
FileWriteLine($file, "vbr_brate_avg="& $Bitrate)
FileWriteLine($file, "vbr_brate_min=1200")
FileWriteLine($file, "vbr_brate_max=9000")
FileWriteLine($file, "vbr_bias=30")
FileWriteLine($file, "vbr_pass=2")
FileWriteLine($file, "quality_prec=30")
FileWriteLine($file, "use_filter=0")
FileWriteLine($file, "filter_val=6")
FileWriteLine($file, "seq_endcode=1")
FileWriteLine($file, "dvd=0")
FileWriteLine($file, "half_width=0")
FileWriteLine($file, "half_height=0")
FileWriteLine($file, "fast_mode=0")
FileWriteLine($file, "progressive=1")
FileWriteLine($file, "alternate_scan=0")
FileWriteLine($file, "non_linear=1")
FileWriteLine($file, "top_first=1")
FileWriteLine($file, "lum_level=0")
FileWriteLine($file, "intra_dc_prec=2")
FileWriteLine($file, "aspect_ratio=2")
FileWriteLine($file, "gop_m=3")
FileWriteLine($file, "gop_nm=5")
FileWriteLine($file, "gop_hdr=15")
FileWriteLine($file, "seq_hdr=1")
FileWriteLine($file, "all_closed_gop=0")
FileWriteLine($file, "fix_gop_length=0")
FileWriteLine($file, "mpeg1=0")
FileWriteLine($file, "mpeg1_cps=0")
FileWriteLine($file, "samples_per_sec=48000")
FileWriteLine($file, "stereo=2")
FileWriteLine($file, "brate_idx=7")
FileWriteLine($file, "crc=1")
FileWriteLine($file, "[file]")
FileWriteLine($file, "name=" & $Source)
FileWriteLine($file, "type=0")
FileWriteLine($file, "frame_first=0")
FileWriteLine($file, "frame_last=" & $Frames)
FileWriteLine($file, "encode_first=0")
FileWriteLine($file, "encode_last=" & $Frames)
FileClose($file)
EndFunc
;++++++++++++++++++++++++++++++++++++++++++++++++++

[john3voltas]

Gee, thanks for the sources Darksoul71 ;).
That was a very nice gesture from you :).
I will look into these sources in more detail during the WE.
Nevertheless, I'm affraid it will take me one week or so to have something ready for testing.
I will post it afterwards.
C u.

[Darksoul71]

@john3voltas:
You´re welcome ! I´m always pleased to help und normally always release my sources. I could do some modifications to my AVIInfo Tool, so it can be controlled solely via commandline interface and be run hidden. Currently my AVIInfo is completely GUI-driven and I use the following code to obtain resolution and frame count of the opened window.

;++++++++++++++++++++++++++++++++++++++++++++++++++
Func AVI_Info($AVIFile, ByRef $W, ByRef $H, ByRef $Dur)
BlockInput(1)

Run($aviinfo, "", @SW_SHOW)
WinActivate ("AVI Info")
WinWaitActive("AVI Info")

Sleep (500)
Send("{TAB}")
Sleep (500)
Send("{ENTER}")
Sleep (500)
Send($AVIFile)
Send("{ENTER}")

WinWaitActive("AVI Info")

Sleep (500)

$W = ControlGetText("AVI Info", "", "TEdit3")
$H = ControlGetText("AVI Info", "", "TEdit2")
$Dur = ControlGetText("AVI Info", "", "TEdit1")

Send("!{F4}")

BlockInput(0)
EndFunc
;++++++++++++++++++++++++++++++++++++++++++++++++++


I could store the informations either inside an ini-file (which is easy to read from within AutoIt) or some environmental variables which could be read via "EnvGet". Let me know via PM if you have interest in this. May be we should ask over at the DVDRebuilder forum for the source code which is used within DVDRebuilder for the OPV encoding with HC Enc ?

Just an idea...

-D$

[jdobbs]

Just as a suggestion, you may be interested to know that in HC you can use fractional CQ value for more accuracy. So you could use CQ=2.65, for example, as opposed to having to select between 2 and 3.

Also, the sizing result and the Q are not linear, so you can reduce the number of prediction passes required by not making linear decisions.

So the calculation:

($CQ*($EstSize / $TSize))

could be:

($CQ*($F * ($EstSize / $TSize)))

Based on suggestions I got from tylo, I've found the $F=1.35 works well. But you may want to play with it.

I usually loop through until the predicted size is within 1% of the target size or the value doesn't significantly change.

[Boulder]

Just as a suggestion, you may be interested to know that in HC you can use fractional CQ value for more accuracy. So you could use CQ=2.65, for example, as opposed to having to select between 2 and 3.

Also, the sizing result and the Q are not linear, so you can reduce the number of prediction passes required by not making linear decisions.

So the calculation:

($CQ*($EstSize / $TSize))

could be:

($CQ*($F * ($EstSize / $TSize)))

Based on suggestions I got from tylo, I've found the $F=1.35 works well. But you may want to play with it.

I usually loop through until the predicted size is within 1% of the target size or the value doesn't significantly change.
And then the "sizing pass" which should be done if the final filesize of the encoded video is not within specified percentage of the target filesize, the correction factor ($CorFac=$target/$final) should be used in the formula: ($CQ*($F * $CorFac *($EstSize / $TSize))). That should ensure that the second CQ encode will be close enough to the target. Or am I totally wrong? :D

[jdobbs]

With CCE is would be better just to a normal multi-pass encode using an average bitrate, etc... that way it would use the .VAF from the OPV pass and you will get exactly the size you requested. The purpose of the prediction passes is to save time -- if it failed to be accurate enough, you might as well make sure it won't happen again.

[Boulder]

With CCE is would be better just to a normal multi-pass encode using an average bitrate, etc... that way it would use the .VAF from the OPV pass and you will get exactly the size you requested. The purpose of the prediction passes is to save time -- if it failed to be accurate enough, you might as well make sure it won't happen again.
That's what D2SRoBa/CCEFront does, and that's what would be nice to have in HC - it would create the dbs file in CQ mode which could be used for a sizing pass if necessary but I'm afraid it would slow the CQ encoding down a bit.

[jdobbs]

Hmmm... that's a coincidence. I recently asked Hank315 to look at that possibility. Not sure if it's feasible. He'd have to save all his collected data from the CQ pass into a file -- and that's assuming a CQ pass is equivalent to the first of a two pass encode in his algorithm...

[Darksoul71]

Hi jdobbs,

thanks for your infos / suggestions. You´re absolutely right. As HC_Enc uses a floating point format with three decimal places the (modified) formula needs to be changed to somewhat like this: $CQ = Round ($CQ*$F*($EstSize / $TSize),3)
Not quite shure if you really need all three decimal places to hit the exact target. That is something I would have to evaluate. I can somewhat remember the "f" value from the discussion over at the DVDRebuilder thread on RoBa encoding.

Most of my OPV-encoding tend out to be smaller than my targeted size and oversized file are very rare. To avoid oversizing a simple approach for CCE is to increase the estimated Q-value by 1. You will mostly not notice any drop in quality and definitely not get oversized files (unless your 1% samples were not very representative for your movie). The other approach is to aim for a smaller size than your media has storage capacity, e.g. using 4300 MB as target size for a DVD-R.

Using rejig if the file is oversized might also be an option as you will mostly not notice a decrease in quality if you shrink the file for let´s say 2%.

-D$


BTW: This was the posting of tylo over there (hopefully no-one "smashes" me for posting such a long text :)

Oh, my. This thread was really about RoBa, wasn't it?

jdobbs, I don't know much about how you implemented your Q-estimation routine. I know you use 0.5% sample, which in my experience gives a too high error variance. I use 1% sample which is barely OK. (0-2% estimation error most of the time, but sometimes up to 3%).

If you want, I could give you a simple condensed algorithm how to search for Q. It's not very complicated.

The way D2SRoBa does it is somewhat more advanced because it must deal with the max-bitrate limitation for SVCD. The Q-function normally follows an exponential (almost straight) slope, but near max-bitrate it suddenly bends a lot. In that case I switch from newton-raphson to binary search for Q.

For DVD bitrates, that shouldn't be an issue, and it should be fast and easy to find the closest Q that match the target bitrate. Btw. you have to subtract about 1.2% from the estimated size, when determining the Q. Also check 'Restrict auto I-frame insertion' in CCE (fix_gop_length=1) - it improves the estimation accuracy a little (tips from jonny).

/More technical talk: Another note about the accuracy of the final mpv bitrate (from an OPV encode) versus the original target bitrate:

In D2SRoBa, I compute the current estimated Q-step size in percentage, i.e. 100*(estBR(Q) - estBR(Q+1))/targetBR. This varies from 0.8% to 4%. Example: if this number is 3%, it means that it is 3% between each Q (in that Q-area), which again means that, in worst case you cannot hit better than 1.5% on target, even if your estimates are absolutely correct. What I'm saying is that this error comes on top of the possible estimation error (e.g. if test samples are not representable).

Anyway, normally this all equals out, and D2SRoBa has proven that the method works excellent.

when I use undot and deen on a source it yields about 12Q lower than without them. At least with about Q40-50, cause I dont really remember how much improvement the lower ones yielded, but it was definately an improvement.

The material below covers two areas.

1> How the complexity, and the resulting compressibility of a video source, can be quantified via the numerical bitrate derived from the physical filesize of a 1% sample where the sample has been created at a known Q value with CCE OnePassVbr (note 3).

Q values normally in the range of 10-40 would be considered the working range to provide excellent to acceptable quality. The goal is for the user to develop a personal quality constant that is always appropriate for the users display methods, and to be able to know in advance of encoding if that level of quality can be achieved. My personal 'quality constant' is Q28

2> How to provide a simple logic so that a program or user can know in advance the approximate quality that will be delivered from a CCE multipass encode.

These goals, and the suggested method to achieve it, is based upon certain educated guesses Bach made since he did not having access to CCE source code (note 2 below). From a practical standpoint, and at the very least, it should provide the user with a very good quality indication before the full encoding process.

Explanation -

This average bitrate number derived from the filesize of the 1% OPV sample is the minimum needed to contain the complexity of the sampled video source and closely deliver the same quality of the OPV sample. This may seem obvious, yet the important fact is that the complexity, and thus the resulting compressibility of the sampled video source has been quantified within a number, the size. This size can then be translated to an average bitrate in Kbps which is compatible with CCE VBR.

This number, the derived average bitrate, can be used as a bridge between the two different encoding methods (OPV and VBR), each of which has distinct strengths and weaknesses when standing alone. By bridging these methods we can combine many of the strengths of both.

As a proof exercise, CCE Multipass VBR when using this derived Kbps number and the same MIN/MAX very closely mirrors the encode that is produced by OPV using a Q number. This is shown in the attached spreadsheet, linked here and attached at the bottom of this post. The accuracy of the translation between Q and KBPS seems clear.

With a working method of translation, we can combine the strengths of both processes for certain situations.

One situation is where multipass is specified as the encoder tool because of its ease of use, and/or the need for its main strength of creating a final file size exactly on target. While multipass VBR is brilliant in achieving a size target by the nature of its size based process, it has an inherent weakness. It does not possess any internal process that allows it to understand when the ABR, specified by the user, will not be sufficiently high enough to yield a acceptable encode quality.Thus, the final quality of the encode is unknown until after the encode is finished (many hours later).

OPV has opposite characteristics in that quality, via a controlled quantizer approach, is achieved at the cost of non existent size control. OPV is one of the kings of quality and also the fastest software Mpeg2 encoding method available, but without accurate filesize prediction, OPV was only useful for encodes to be held on hard drive as the source complexity solely dictated the bitrate. The final encode size could fluctuate radically, depending on the unique compression characteristics of the individual source, between two sources of the same time length. Thus, the final size of the encode is unknown until after the encode is finished.

Predictive sampling, sometimes called 1-PassBach or its iteration, 2-PassBach and best exampled in the D2SRoBa plugin used in combination with Dvd2Svcd/Dvd, was introduced to deal with this weakness in OPV. It uses multiple small samples and solves for the Q which will achieve a target size. Because it solves for Q, which indirectly manipulates bitrate, it effectively provided size control as well as the ability to predict the final quality before the actual encoding process. It does this brilliantly and yields a HQ encode in the shortest time possible.

However, Conditional 2Pass Bach as implemented by D2SRoBa took a long time to develop and quietly does many complex actions not readily apparent to the user. The series of prediction samples, and the Newton-Raphson Method calculus (adapted by R6D2) as used by D2SRoBa, are complicated to implement. This can be beyond the scope of many casual hobby programmers, or manual encoding techniques.

In this situation, the derived average bitrate of a known Q sample as described above, can be used to translate between the two processes. Because the OPV sampling process has actually encoded 1% of the video source as small equally spaced sections, the derived bitrate generated from the sample size inherently contains an awareness of the compressibility of the source. Thus, the D-ABR of the known Q sample is the minimum required bitrate that will be needed to achieve a similar quality in the bitrate based multipass VBR encode. In effect, the process matches the distinct compression characteristics, which are unique to the source complexity, to the appropriate Average Bitrate needed to hold and contain our desired quality. In addition, the identified Derived-ABR (as Kbps) will also provide the framework for creating branching program logic.

The derived Kbps value is used to establish a quality 'GO/NO-GO' conditional.

To do this, an extra step is added when using conventional multipass.

Normally an average bitrate would have been calculated to fill the space available and the encode started, whether the bitrate was adequate, or inadequate, to achieve an acceptable quality level for the particular compression needs of the source. There is not much difference in this method, except before starting the encode, a comparison is made between the Kbps calculated to fill the size available and the derived bitrate from the known quality sample.

GO - When the size calculated bitrate is equal or larger than the derived bitrate from the sample -

The encode is started as normal. This will yield a minimum guaranteed level of known quality within a known filesize. Note: if more space is available for the encode than the minimum requirement predicted by the sample D-ABR, the size calculated ABR will of course be larger than that of the sample's D-ABR. The quality will therefore also increase over that of the known quality sample.

NO-GO - When the size calculated bitrate is less that the derived bitrate from the sample -

Allows the programmer or manual user to detect, in advance of the encode, when a known quality
cannot be achieved within a known filesize. Additional logic can then be triggered to deal with
this situation such as resolution adjustment, compression filtering, downsizing of audio, etc., to
make more space available for the encode.
---------------------------------------------------

Note 1: This is a work in progress as a self learning exercise and is based upon the original propositions posted by Bach and many subsequent revisions by the members of this community, especially those that relate to what we now call 1-Pass and 2-Pass Bach as used in D2SRoBa. This post targets how to apply some of these OPV techniques to CCE Multipass VBR. I highly doubt any of the information here is original, but I do hope this compilation may provide a useful method for those who wish to use CCE multipass and would like to know general quality information in advance of the actual encoding process. Also, I may have not been precise in the use of some of the technical terms, but they are accurate enough for now.

Note 2: This line from the original post is an important part of the assumptions here. However, it was never independently verified as correct, hence the word assumption [all emphasis is mine] - : Originally posted by Bach - "Attention that the Q.factor is an exclusive concept of CCE, directly related with the quantisation, but it does not mean QM nor S, and it is not very clear the way that it is calculated. Based in the results of my tests, I believe that Q.factor is in some way proportional to the average value of the product QM(i, j)*S. Anyway, the Q.factor is the direct measure of the quality to be gotten so that, if two different films are recompressed using the same settings and the same Q.factor, can be guaranteed that they have the same quality."

Note 3: The sampling method is only available when using AviSynth to frameserve video to CCE OnePassVbr (OPV). It assumes the reader understands the use of avisynth and is capable of editing an AVS script, loading the script into CCE, choosing OPV mode and a Q value. To produce an AVS for creating the sample, simple add this line at the bottom of your working script: SelectRangeEvery(1200,12). Obviously, this line must be removed after the sample has been created.

You will need the derived bitrate spreadsheet calculator, linked here, or attached to the NEXT post below, OR use this formula - (((Sample_Size_In_Bytes*(100/Sample_Size_Percentage))*8)/1000)/(Total_Frames/Frame_Rate)

[jdobbs]

Not quite shure if you really need all three decimal places to hit the exact target. That is something I would have to evaluate. I can somewhat remember the "f" value from the discussion over at the DVDRebuilder thread on RoBa encoding. I use two decimal places myself. In fact I use the same prediction routine for CCE and for HC by just multiplying HC's CQ value by 10 before entering the analysis routine, and dividing by 10 on exit.

Also, the formula below works better if you want to calculate F within the passes. It will reduce by half the number of prediction passes needed on larger Q (or CQ) values.

F = 1.35 + (Q * (Q / 20) / 1000)

[Darksoul71]

@jdobbs:
Thnx for your explanations.

@john3voltas:
I´ve been playing around a bit with autoit but I´m too tired to find out why this thingie doesn´t converge :)

Feel free to use my sources but please also share your sources with other peoples to let them know how you did this. If you require my AVIInfo proggie, drop me a PM and I´ll mail it to you.

Good night,
D$

; ----------------------------------------------------------------------------
;
; AutoIt Version: 3.1.0
; Script Title: HCpred V1.0
; Author: Dark$oul71
;
; Script Function:
; Provide OPV encoding similar to D2SRoBa for HC enc
;
; ----------------------------------------------------------------------------
$aviinfo = @ScriptDir & "\AVIInfo\AVIInfo.exe"
$hc_enc = @ScriptDir & "\HCbatch_016_testrelease_08-09-2005.exe"
;++++++++++++++++++++++++++++++++++++++++++++++++++
Func AVI_Info($AVIFile, ByRef $W, ByRef $H, ByRef $Dur)
BlockInput(1)

Run($aviinfo, "", @SW_SHOW)
WinActivate ("AVI Info")
WinWaitActive("AVI Info")

Sleep (500)
Send("{TAB}")
Sleep (500)
Send("{ENTER}")
Sleep (500)
Send($AVIFile)
Send("{ENTER}")

WinWaitActive("AVI Info")

Sleep (500)

$W = ControlGetText("AVI Info", "", "TEdit3")
$H = ControlGetText("AVI Info", "", "TEdit2")
$Dur = ControlGetText("AVI Info", "", "TEdit1")

Send("!{F4}")

BlockInput(0)
EndFunc
;++++++++++++++++++++++++++++++++++++++++++++++++++
Func GenerateHCL ($HCL, $Input, $Output, $Q)
$file = FileOpen($HCL, 2)
FileWriteLine($file, "*infile " & $Input)
FileWriteLine($file, "*outfile " & $Output)
FileWriteLine($file, "*bitrate 4000")
FileWriteLine($file, "*maxbitrate 9000")
FileWriteLine($file, "*cq " & $Q)

$myFile = FileOpen(@ScriptDir & "\myHC settings.txt",0)

While 1
$line = FileReadLine($myFile)
If @error = -1 Then ExitLoop
FileWriteLine($file,$line)
Wend

FileClose($file)
FileClose($myFile)
EndFunc
;++++++++++++++++++++++++++++++++++++++++++++++++++
Func AddLine ($TextFile, $Line)
$file = FileOpen($TextFile, 1)

; Check if file opened for reading OK
If $file = -1 Then
MsgBox(0, "Error", "Unable to open file.")
Exit
EndIf

FileWriteLine($file, $Line)

FileClose($file)

EndFunc
;++++++++++++++++++++++++++++++++++++++++++++++++++
Func GetPAR ($Width, $Height, ByRef $FPS)
; Determin FPS by vertical resolution
If (Mod($Height, 240) = 0) Then $FPS = 29.97
If (Mod($Height, 288) = 0) Then $FPS = 25

; Note: Anamorphic material is not supported
; PAL AR´s
If ($Width <= 352) And ($Height = 576) Then Return (2.188)
If ($Width <= 480) And ($Height = 576) Then Return (1.641)
If ($Width <= 352) And ($Height = 288) Then Return (1.094)
If ($Width <= 704) And ($Height = 576) Then Return (1.094)
If ($Width <= 720) And ($Height = 576) Then Return (1.094)

; NTSC AR´s
If ($Width <= 352) And ($Height = 480) Then Return (1.818)
If ($Width <= 480) And ($Height = 480) Then Return (1.364)
If ($Width <= 352) And ($Height = 240) Then Return (0.909)
If ($Width <= 704) And ($Height = 480) Then Return (0.909)
If ($Width <= 720) And ($Height = 480) Then Return (0.909)

Return(1)
EndFunc
;++++++++++++++++++++++++++++++++++++++++++++++++++
; Processing of CLI. Open file dialog if no parameter (= source file) was given.
If ($CmdLine[0] >= 1) Then
$SourceFile = $CmdLine[1]
Else
$SourceFile = FileOpenDialog("Choose Videofile to process" , "C:\", "Videofiles (*.AVS)", 2)
EndIf

If ($CmdLine[0] = 2) Then
$BitRate = $CmdLine[2]
Else
$BitRate = InputBox("Bitrate", "Enter your bitrate in kBit/s:")
EndIf

; Initialize values for video cropping
$Left = 0
$Right = 0
$Top = 0
$Bottom = 0

$HasCropInfo = 0

; Quellauflösung auslesen
$SourceWidth = 0
$SourceHeight = 0
$Frames = 0
$FPS = 0

AVI_Info($SourceFile, $SourceWidth, $SourceHeight, $Frames)

; Determine Pixel Aspect Ratio of Source Material
; Note: Anamorphic material is not supported -> 4:3 max
; Supported resolutions are
; PAL: 352x288, 352x576, 480x576, 704x576, 720x576
; NTSC: 352x240, 352x480, 480x480, 704x480, 720x480
$SourcePAR = GetPAR ($SourceWidth, $SourceHeight, $FPS)

$Duration = Round ($Frames / $FPS)

; Do Q-Estimation if OPV encoding selected
$compAVS = @ScriptDir & "\comp_movie.avs"
$compMPV = StringTrimRight($CompAVS,3) & "mpv"
$HCFile = @ScriptDir & "\hc_temp.ini"

FileCopy ($SourceFile, $compAVS)
AddLine ($compAVS, "SelectRangeEvery(1500,15)")

$cWidth = 0
$cHeight = 0
$cFrames = 0

AVI_Info($compAVS, $cWidth, $cHeight, $cFrames)

; HC Q-Faktor: 1 to 31
$CQ = 5
$CQ_Alt = $CQ + 2

$F = 1.35

$EstSize = 1
$TSize = 3

While (Abs ($EstSize - $TSize) > 0.01)
;While (Abs ($Es-$CQ_Alt) > 0.1)
$CQ_Alt = $CQ

GenerateHCL ($HCFile, $compAVS, $compMPV, $CQ)
RunWait ($hc_enc & " -ini " & Chr(34) & $HCFile & Chr(34), @ScriptDir, @SW_SHOW)
$EstSize = (FileGetSize ($CompMPV) * 100) / 1024
$TSize = ($Bitrate / 8) * $Duration
MsgBox(0,"Q-Wert", $CQ & " " & $EstSize)
;$CQ = Round ($CQ*$F*($TSize / $EstSize ),3)
$CQ = Round ($CQ*$F*($EstSize / $TSize),3)
;$F = 1.35 + ($CQ * ($CQ / 20) / 1000)
WEnd


$FinalMPV = StringTrimRight($SourceFile,3) & "mpv"

GenerateHCL ($HCFile, $SourceFile, $FinalMPV, $CQ)
RunWait ($hc_enc & " -ini " & Chr(34) & $HCFile & Chr(34), @ScriptDir, @SW_SHOW)

; Clean up temporary files
FileDelete ( $compAVS )
FileDelete ( $compMPV )
;FileDelete ( $HCFile )

[john3voltas]

@Darksoul71,
Thanks again for posting all your goodies on AutoIT and OPV prediction.
And be sure that when I finish the tool (if I ever do finish it :rolleyes: ) I will certainly release my sources too ;).
I guess you will all have to be patient with me because last time I coded anything, Turbo Pascal still ruled.
That is, roughly 12 years ago :D.
Cheers

[Boulder]

I guess you will all have to be patient with me because last time I coded anything, Turbo Pascal still ruled.

Uh oh, I guess I opened a can of worms :D I can do some testing for you if my time just allows any extensive tests, I'm about to become a father of two so time might be heavily restricted ;) That's one reason why I asked for the automatic CQ mode.

Thank you goes to both you and Darksoul71, take your time:)

[EpheMeroN]

I use MuxMan to do simple authoring for many projects I do. I just encoded a video with the new HC Encoder v0.15A and when I tried to author it in MuxMan I received this error:

Largest GOP of 38 fields exceeds DVD specification of 36. Resulting DVD is non-standard.

Is there ANY way to correct this without re-encoding? I know there probably isn't, but I spent 64 hours encoding this thing (heavy filtering).

A copy of the log from the encode can be found here (http://users.adelphia.net/~l337/movie.log).

[Marius-the-Mad]

You used DGPulldown afterwards, am I right ? Performing a pulldown from 23.976 to 29.97 (or any other higher than source framerate) means using flags to duplicate fields on playback. And from the decoder's point of view, the GOPs get longer. I'm afraid you will have to reencode. :(

I did some similar encodings and from my experience: maximum GOP length for 23.976 -> 29.97 = (23.976 / 29.97) * 18 - 1.

Or 2 instead of 1 - I don't remember whether I had to do it the former or the latter way. :(

It may look weird, but setting GOP length to 14 didn't help me and I had to reencode.

[EpheMeroN]

Correct. I did use DGPulldown. So when I re-encode in HC, what do I do differently? I uncheck "autogop" and what settings will I use? I have no knowledge of GOP length or anything GOP-related whatsoever.

[Marius-the-Mad]

Uncheck autogop, set GOP length to 13. I hope this will be low enough and you won't have to reencode once again. I'm sorry, but my memory fails me in this case. :( Leave the number of B-frames at 2. And this should do it.

Regards
MTM


<edit> Try to encode 2000 frames, pulldown the file, feed it to muxman and see what happens. If it's OK, try the same with autogop. If it fails, I think there is a reasonable chance everything will be all right with GOP legth at 13.

Please, may someone with a higher amount of knowledge than mine correct me if I'm wrong. :)

[Sir Didymus]

Largest GOP of 38 fields exceeds DVD specification of 36. Resulting DVD is non-standard.

Is there ANY way to correct this without re-encoding? I know there probably isn't, but I spent 64 hours encoding this thing (heavy filtering).

A copy of the log from the encode can be found here (http://users.adelphia.net/~l337/movie.log).

There is...
Or better, there are some...
I know a couple:

One is Womble MPEG Video Wizard
http://www.womble.com/products/

A second possibility is based on Cuttermaran.
Settings --> Encoding --> Create DVD Compliant Stream

Both are extremely fast, since just the out-of-dvd-spec segments are re-encoded...

At the present Cuttermaran is supporting whatever encoder (but needs to write a little xml configuration file in order to make the encoder available to the application). The default encoder is TmpgEnc. Don't ask me more since I've never been in a situation like the yours...


Edit: but please report your experience, if you intend to try with one of the above applications...

Edit2; OOPS!!! SORRY!!! IT SEEMS I WROTE SOMETHING TOTALLY WRONG, due to the quick reading of the last posts in the thread... Hem... Well, after some reconsideration, and especially after reading:

http://forum.doom9.org/showthread.php?t=98569&highlight=dgpulldown

and

http://forum.doom9.org/showthread.php?t=93842

It seems it is highly possible that the out of specs GOP size problem you face is present in the whole encoded stream you have...

So please discard all of the suggestions based on Womble and Cuttermaran: they may work efficiently just if the size of out-of-spec Gop is little compared to the whole stream size... And this seems is not your case... So re-encoding the whole stream, with a proper GOP structure is necessary if you know you will need DGPulldown in your process...

Cheers,
SD

[hank315]

Would it be possible to add a prediction engine to the CQ mode?Yes, will try to implement some kind of 1-pass VBR with prediction in the next release.

@Boulder
Looking at all the posts after yours it seems more people are interested in it :D

@2COOL
You're right, this thread is getting pretty large.
Will open a new one for HC016 (very soon)

[EpheMeroN]

@Sir Didymus: I will need DGPulldown because the source is 23.976fps. I will do what Marius-the-Mad recommended by using a lower GOP. But I have a question. If HC's default GOP is "automax", is there a way, from viewing the log, to see what the actual max of the GOP was? The error said that it was over the GOP limit by 2. Now correct me if I am wrong (which I probably am) but wouldn't I just have to limit that number by 2? I heard the NTSC MAX was 18 and that GOP size affects quality. Switching it to 13 seems like a drastic measure. Last time I used DGPulldown, it was on a 25fps source that I did a 25 > 29.97 on so I could view it on my NTSC TV and it never reported that error.

[Trahald]

gop sizes are usually 12 15 and 18.. (for a regular mpeg2, bframes = 2, gop)
23.976 fps -> 29.97fps pulldown is generally best done at gop size of 12. (12x2.5frames = 30 fields).. since 15x2.5frames = 37.5 which is higher than spec... you can do oddly configurated gops to get to 13 or 14 but they would tend to hurt things more than having a traditional gop format (2 bframes) at a size of 12.

25->29.97 conversion works at 15 GOP because it brings you to right around 36 so your ok.

[Sir Didymus]

@EpheMeroN

The reasons of your troubles are perfectly described by the last post of Trahald.

Just want to add that the "traditional" GOP sizes of 15 and 18 (limits for PAL and NTSC) comes from some timing limits in the DVD specs (from 0,4 to 1.2 second max per VOBU, except the last VOBU in the cells, where it is allowed to go up to 1.4, allowing the authoring package the possibility of mapping up to two full GOPs per VOBU). For other reasons, as already indicated, it is almost necessary to have GOP sizes multiple of three, so the indicated mac GOP of 12 should by the right chioce in your situation.

From the compressibility/quality point of view, the situation is as follow: reducing the GOP size means increasing the I frame density in the mpeg2 stream, which improves the overall stream quality but decreases its compressibility...

Reading the log of your encoding I see your average video bitrate is beyond 4500 Kbit/s, so you have a lot of margin...

I am pretty sure with this bitrate you are going to obtain an encoded stream, imposing a GOP size of 12, almost undistinguishable from the original...

Cheers,
SD

[john3voltas]

Yes, will try to implement some kind of 1-pass VBR with prediction in the next release.
Not to get you off your track or anything Hank315, but I fully agree on what DarkSoul71 said about prediction being the job for a frontend tool.
Looking at other free or commercial encoders I can't find any with 1-pass prediction.
Just hope that Boulder won't try to kill me for this :D.
If I were in your shoes I would add that to my to-do list, but I would make sure that bugs would come in 1st place ;).
Even because with the sources that DarkSoul71 posted here, I am right now predicting with very good results.
See you

[Amnon82]

btw. Hank released his new Version 0.16 (http://forum.doom9.org/showthread.php?t=100133)

[Darksoul71]

@john3voltas:
Even because with the sources that DarkSoul71 posted here, I am right now predicting with very good results.
Good to hear ! Please keep me "posted" on your progress. May be I can integrate "our" code for CQ encoding with HC Enc into my MPEG2DVD tool.

Cheers,
D$

[Boulder]

Looking at other free or commercial encoders I can't find any with 1-pass prediction.
Just hope that Boulder won't try to kill me for this :D.

Hey, no problem :) I just thought it might be easiest if it was in the encoder itself. That way it would work for any other program that uses HC without the need of any extra programs.

[Darksoul71]

@Boulder: I agree that OPV encoding integrated into HC would be less of a PITA for other pograms calling HC enc. On the other hand doing OPV encoding "outside" the encoder gives you increased flexibiliy for things such as:
* Conditional filtering (à la KISS for D2SRoBa)
* Using different approaches for Q-Value calculation
etc.

[Marius-the-Mad]

you can do oddly configurated gops to get to 13 or 14 but they would tend to hurt things more than having a traditional gop format (2 bframes) at a size of 12.Thank you for this explanation, Trahald. I didn't know that.

I have a question, if I may. Do you know why using a GOP length of 14 resulted in a too long GOPs after using DGPulldown to go from 23.976 to 29.97 ? I tried it once and that was the result. I'm curious why - theoretically it should work I think, as 18 * 23.976 / 29.97 = 14.4...


Regards,
MTM

[LigH]

btw. Hank released his new Version 0.16 (http://forum.doom9.org/showthread.php?t=100133)
:angry:

If he did, I'd know before you...

This is a "test release" for hunting down specific bugs. Not a production release. Learn to tell those apart.

[Sir Didymus]

@Marius

I am not sure about the HC behaviour, but other encoders simply disobey the input GOP sizes that are not acceptable. If M (parameter defining the b frame rate into the GOP structure) is set to 3, the smallest acceptable GOP size below 15 is 12...

Here is what the CCE manual say on the matter:

http://img51.imageshack.us/img51/5088/image13tm.th.gif (http://img51.imageshack.us/my.php?image=image13tm.gif)

[john3voltas]

Good to hear ! Please keep me "posted" on your progress.
Sorry Darksoul71 but unfortunately last night my Seagate 80Gb SATA HDD died.
It just won't spin or be recognized by the BIOS.
It's dead alright! :devil:
I spent the whole morning reinstalling everything on an old Seagate 30GB IDE HDD that I had around.
But I lost the changes I had done to your script :(.
I am planning on getting back at this project but I'm going away for training in Hungary today and I'll only get back within two weeks...
Also, I am thinking about dropping AutoIt and move on to Delphi or VB because AutoIt is just very bad to build GUIs.
I'll let you know when I get back home.
Thanks for the support you've given me ;)

[john3voltas]

If he did, I'd know before you...
This is a "test release" for hunting down specific bugs.
Not a production release. Learn to tell those apart.
Always the good old Avalon! :D

[Amnon82]

This is a "test release" for hunting down specific bugs. Not a production release. Learn to tell those apart.

@LigH: Sorry, I only wanted to mention it, that a "new" version is out. ... and I know what a test release is.

Always the good old Avalon!

@john3voltas: Ah, You still now my old nicname ;)

Will open a new one for HC016 (very soon)

@all: It is realy a large thread. Lets see what the endcount will be :D

[hank315]

I am not sure about the HC behaviour, but other encoders simply disobey the input GOP sizes that are not acceptable. If M (parameter defining the b frame rate into the GOP structure) is set to 3, the smallest acceptable GOP size below 15 is 12...All GOP sizes are acceptable but some are better than others.
With 2 B-frames the optimal GOP lengths are 3, 6, 9, 12, 15 etc. for open GOPs.
With 1 B-frame the optimal lengths are 2, 4, 6, 8, 10, 12, 14 etc. for open GOPs but if the GOP is closed it's better to use 3, 5, 7, 9, 11, 13, 15...
The autogop option in HC016 tries to optimize these GOP sizes and will also use 3 consecutive B-frames if there's very little motion.
You can also encode with only I-frames using *GOP 1 0

[Darksoul71]

@hank:
would it be possible that you switch away from your
current "ini"-File format to a true ini-Format ?

Example:

*infile d:\....\test.avs
*outfile d:\....\test.m2v
*bitrate 4000
*maxbitrate 9000


This could look in "true" ini-format something
like this:

[HC Enc]
infile=d:\....\test.avs
outfile=d:\....\test.m2v
bitrate=4000
maxbitrate=9000


It would make it much easier to read / write
the config files for HC Enc as most of the
languages provide pre-built functions for
reading ini-files. Commenting out a setting
is still easy since your can add a simple _
or blank in front of the setting you want to
disable, e.g. "maxbitrate=9000" will not be
found anymore if you make it look like this
"_maxbitrate=9000"

Just an idea rather than a feature request.

Keep up the good work !

-D$

[Sir Didymus]

@hank315.

Sorry for the little digression in the thread... If I understand correctly you mean that even knowing it is sub-optimal, it is possible to set 2 b frames and GOP sizes of 13 and 14.

That's nice to know. But is the encoder (and more specifically, is your excellent encoder), under these conditions, capable of strictly obeying the GOP limits of 13 and 14 ?

In case it is, it becomes less clear why, as reported by Marius, by applying a 23.976 --> 29.97 pulldown process, that should present less than 36 fields to the decoder, is not actually working...

Thanks, and keep up your work !!! It's really appreciated by the whole community...

[jdobbs]

I use two decimal places myself. In fact I use the same prediction routine for CCE and for HC by just multiplying HC's CQ value by 10 before entering the analysis routine, and dividing by 10 on exit.

Also, the formula below works better if you want to calculate F within the passes. It will reduce by half the number of prediction passes needed on larger Q (or CQ) values.

F = 1.35 + (Q * (Q / 20) / 1000)Hmmm... just for everyone's sake -- while this formula works very well with CCE, it seems to be off on HC. I'm working on a new formula for HC now.

[Boulder]

Can the scaling between linear and non-linear quantization be calculated somehow, maybe that would be useful as HC's CQ mode means encoding at constant quantizer.

[EpheMeroN]

I am unaware if this issue I'm having now is HC-specific or just in general when changing GOP size. From my posts above, you can see that I had to lower the GOP # for my encode. Now that I am using a GOP or 12, the encode is going at least 2x slower. Is this normal? Before when I had HC on autogop, the 2-pass encode with my script took appx. 65 hours. Right now it's been 43 hours just for 74% of pass #1.

[hank315]

But is the encoder under these conditions, capable of strictly obeying the GOP limits of 13 and 14 ?The first test release didn't strictly handle the limits so a setting of 14 could generate some GOPs with a length of 15, this might explain the pulldown error.
The last test release will follow the given GOP sizes exactly, it can ofcourse be smaller in case of a scene change but it will never be larger.
BTW, an open GOP 13 in HC looks like: IBBPBBPBBPBPB, closed: IPBBPBBPBBPBB
open GOP 14: IBBPBBPBBPBBPB, closed: IPBPBPBBPBBPBB

[jdobbs]

I am unaware if this issue I'm having now is HC-specific or just in general when changing GOP size. From my posts above, you can see that I had to lower the GOP # for my encode. Now that I am using a GOP or 12, the encode is going at least 2x slower. Is this normal? Before when I had HC on autogop, the 2-pass encode with my script took appx. 65 hours. Right now it's been 43 hours just for 74% of pass #1.65 hours? :eek:

You don't have to shovel coal into the back of your computer to make it run do you? ;)

[EpheMeroN]

lol no i don't... the pc isn't that old either. it's a p4m 1.7ghz dell laptop with 256mb ddr ram. it's the script that bogs it down so much. i call funkydeblock, limitedsharpen, and hqdering in it. good times i know!

any ideas why it's even slower this time around now that i lowered the gop to 12?i actually thought it would be faster as i removed undot() from the script.

[jdobbs]

Hmmm... just for everyone's sake -- while this formula works very well with CCE, it seems to be off on HC. I'm working on a new formula for HC now.Well I have to stand corrected... it appears that at least with HC a linear computation works much better. I've just changed the predictive code for HC in DVD-RB...

[Marius-the-Mad]

@ all: Thank you for the answers. :)

@ jdobbs: Sometimes, all it takes to slow down the processing to 0.02x RT, is using iip() with an analog capture. ;) Even though my Athlon XP is probably two times slower than EpheMeroN's Pentium M, we'd still be near 0.05x RT for him.

Sometimes I really wish hardware grew on trees... :(

</offtopic> ;)

[Darksoul71]

@jdobbs:
Well I have to stand corrected... it appears that at least with HC a linear computation works much better. I've just changed the predictive code for HC in DVD-RB...

I´m just as curious as usual :D

Would you mind sharing your prediction code for HC with us ?
What start value do you use for the Q-Value ?

TIA,
D$

[jdobbs]

Here is the formula I use to get a start value:

Q = Int((EncFrames / TargetSectors) * Q_ROM_Constant)

My default value for Q_ROM_Constant (rough order of magnitude constant) is 256 and is used for both HC and CCE -- but if you are using it exclusively for HC you may want to play with it a little to get closer. The resulting value is divided by 10 for HC. EncFrames is the number of frames to be encoded, TargetSectors is the number of 2048 byte sectors that would represent a perfect sizing.

By the way, somewhere earlier in this thread I mentioned dividing by 100 -- actually I meant 10. I'll go back and change it to avoid confusion.

[Xeno86]

And regarding pulldown... maybe this will help:

The GOP size is a count of physical frames in the bitstream and is independent of the display duration of the frames in the GOP. DVD limits the GOP sizes to 18 for NTSC and 15 for PAL, but the count is actual encoded frames, not the display duration of those frames.

There is a case however, with 23.976 pulldown and 15 frame GOP's, where a set of GOP's may be encoded such that they cannot be made DVD compliant. Use 12 frame GOP's to avoid the problem.

DVD specifies that the stream be broken into VOBU's, a VOBU starts with a GOP and may contain more than 1 GOP but the display duration of the VOBU must be >= 0.4 seconds and <= 1.0 seconds (except for the last VOBU which may be <= 1.2 seconds).

If a 15 frame GOP is created followed by a 9 frame GOP (say because of a chapter point) and then followed by another 15 frame GOP, the 9 frame GOP cannot be combined into a VOBU and would be considered to have an illegal length.

The 9 frame GOP display period is 367.0333... or 383.71666... ms (4 or 5 frames will have repeat first field = 1), too short to be in a VOBU by itself so it has to be combined with the previous or next GOP to form a VOBU.

The 15 frame GOP's display period is 617.28333... or 633.9666... ms (7 or 8 frames will have repeat first field = 1).
http://forum.mainconcept.com/viewtopic.php?p=5891#5920

[Xeno86]

Everything is fine but I don't understand this:

This example is for 23.976 -> 29.97 pulldowned GOP
Normally you would have either:

15 frame GOP: 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 (8 extra fields)
9 frame GOP: 2 3 2 3 2 3 2 3 2 (4 extra fields)
15 frame GOP: 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 (8 extra fields)

633.9666 + 367.0333 = 1000.999... too large!

BUT!
If we make similar calculations for 23.976 not pulldowned, progressive GOP we have:

15 frame GOP: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 (0 extra fields)
9 frame GOP: 2 2 2 2 2 2 2 2 2 (0 extra fields)
15 frame GOP: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 (0 extra fields)

9 frame display period = 9/23.976 = 375.375... ms
15 frame display period = 15/23.976 = 625.625... ms
375.375 + 625.625 = 1000.999... which is also too large :eek:

Can anyone confirm that my assumptions and calculations are ok?
Because for me it seems that regardless the stream is pulldowned or not we have identical display times which would suggest that it is ok to apply pulldown to 18 frame GOP stream :devil: .

[Marius-the-Mad]

Great find, Xeno86! Thank you!

As for your second post, however, I'm not sure I know the right answer. :(

[Sir Didymus]

Hey Xeno86, you are not considering that just PAL and NTSC standards are allowed for DVD, even though mpeg2 admits other frame rates, so for sources at 24 fps, the pulldown process is simply unavoidable (in other words no VOBUs based on plain 24fps streams are admitted)...

Said this, your calculations are correct, but this is simply due to the fact that the pulldown process does not change the speed of the stream (so the whole duration of the pulldowned and not pulldowned GOPs are clearily the same...)... Just the framerate is changed...

Cheers,
SD

[Xeno86]

Thank you for your reply Sir Didymus I simply forgot about that :)

But while using GOP 15 we can still make a dvd compilant stream with 23.976 -> 29.97 pulldown. The only thing that is required is NOT to use 9 frame GOP before/after 15 frame GOP so that VOBU will never be longer than 1.0 s.
I should be also possible to use GOP 18 but we there can't be a 6,7,8 or 9 frame GOP after 18f GOP, no 7,8,9 after 17f... and so on.
The encoder should avoid such GOP combinations and everything should be DVD compilant then.

Again, correct me if I'm wrong ;)

[Sir Didymus]

?????

Hei Xeno86, it seems you miss again some very basic constraints about encoding and authoring...

You can not impose such strong limitation to an encoder, otherwise it would be impossible to properly handle scene changes and, for example, while feeding it with an n frames stream, you would simply be unable to obtain n frames as output...

Also, for the precision of the chapter points placemen, it is a fundamental feature of many high level encoders to be able to position I frames (in a single given video stream, and based on some definition or list of chapter points), wherever the user needs...

Cheers,
SD

By the way, sorry again for the little digression, since it's going definitely off topic...

[Xeno86]

@sir didymus
Why do you think it would be a limitation? At the moment you HAVE TO use GOP length 12 setting in HC to produce dvd compilant stream after pulldown. What I am suggesting is to add ADDITIONAL CAPABILITY to use longer GOPs in pulldowned stream it doesn't limit anything - regular streams would be totally unafected! It just adds functionality!
I don't think it would arise problems when it comes to scene changes, chapters, etc.
Most encodes are done in 2 passes so in the first pass encoder checks where to put I frames and in the intermediate state it can calculate GOP lenghts so that they do fit exactly where we want them.
What I am trying to tell is to try to avoid such GOP lenght combinations that would cause problems and use other. And again I say that is should be totally optional so that the user can decide wheather to enable it or not.

For example instead of using problematic GOP set:
18 18 18 18 18 18 18 7 18 (last VOBU too long)
the encoder could use this:
18 18 18 18 16 16 16 13 18 (everything fine)

So please tell me wheather it is possible or not... It would help gain quality and use less bits. So i think it's worthy.
BTW. I don't think that it's off topic :)

[jdobbs]

I'm having a little trouble following this... why would the GOP length have an effect on pulldown anyway? The pulldown flagging sequence isn't done against a single GOP but against the temporal frame positions of the entire stream. What am I missing here?

[Xeno86]

@jdobbs
see post #508 (http://forum.doom9.org/showthread.php?p=714018#post714018) and link (http://forum.mainconcept.com/viewtopic.php?p=5891#5920) under that post.
why would the GOP length have an effect on pulldown anyway?
It is described in the link above - using GOP combination eg. 15-9-15 violates the rule that VOBU's display time >= 0,4s & <= 1,0s. I'm trying learn if it would be possible to bypass this limitation using gop-length combinations (as in my previous posts) and not to be 'glued' to max gop length = 12 when using pulldowns (while dvd standards allow to use max. gop lenght=18 for NTSC) or am I mad and trying to do something what is impossible? ;)

BTW. I'm basing whole this teory on what BB said in his post (http://forum.mainconcept.com/viewtopic.php?p=5891#5920) so blame him :p

Thx for all your answers

[jdobbs]

Wow. Brent Beyeler himself was speaking in that link. That guy's a legend. In fact, if I recall properly, the PULLDOWN.EXE utility was based upon his sources.

[hank315]

You can not impose such strong limitation to an encoder, otherwise it would be impossible to properly handle scene changes and, for example, while feeding it with an n frames stream, you would simply be unable to obtain n frames as output...Properly handling scene changes is still possible, HC already knows where to put a scene change at least 2 GOPs ahead because it caches and analyses 80 frames before encoding.
It will need some extra checking and inserting some shorter GOPs but it's not impossible.

[Sir Didymus]

@sir didymus
...
For example instead of using problematic GOP set:
18 18 18 18 18 18 18 7 18 (last VOBU too long)
the encoder could use this:
18 18 18 18 16 16 16 13 18 (everything fine)
...


Ok. I see what you mean... it seems it is necessary to look at least three or four gops in advance, but Hank315 saying it is possible means it's ok...

So, let me apologise for the wrong assumptions I made, and lets' add this "15 GOP size for 24 --> 29 pulldown streams" mode in the requests for the HC encoder !!!!

All the best,
SD

[Xeno86]

and lets' add this "15 GOP size for 24 --> 29 pulldown streams" mode in the requests for the HC encoder !!!!
Nice to hear that but please let me also add "18 GOP size mode" to this request ;)

Cheers

[johnhamler1]

why HC is so slow???

[jdobbs]

Slow? Compared to what? It isn't as fast as CCE -- but it is considerably faster than most encoders.

[video_magic]

"why HC is so slow???"

It depends a lot on the settings that you use for an encode, as to how long an encoding might take.

Plus what pre-processing you do like in Avisynth (got many filters, resizing?)

There are other factors too: like what other tasks are happening on the PC at the same time as you are encoding, what class of hardware is in your PC, whether your Windows is set up well & tidy, got enough free memory is it paging a lot, etc etc

[Fishman0919]

why HC is so slow???

?!?!?!?, HC is pretty fast for encoders, at best settings it's faster then Procoder, TMPGEnc, Mainconcept and Sony Vegas... and is as good if not better in most cases. If you are comparing to CCE, then most encoders will fall short when comparing speed but quality of HC to CCE is real close... sometimes better.

[Sounddude]

This is becoming my favorite encoder. Speed, quality, it doen't get much better than this. Big thank you to Hank!!

[Amnon82]

but quality of HC to CCE is real close... sometimes better.

... thats right. Hank did/do a good job here. Can't wait for the next release ...

[Prodater64]

Related to the CQ encoding.
CQ mode is not a good solution as hank315 answered me some time ago, btr spikes can't be avoided. I don't know if he fixed it in any way.
cq_maxbitrate will be a solution when hank315 manage to bring back "cutted bits" (to keep dvd compliant). At the present state most CQ_maxbitrate encodings undersizes.
Im worked on, but not tested yet, a prediction model based in Cuadratic Lagrange Interpolation polynomials. I have a test model wrote in Windows cmd scripting language (old dos batch). If anybody is interested in this, I can post it or PM it where you want.
This method could compensate the present CQ_maxbitrate limitation (I don't know Newton implemented method in ROBA but related we are talking with Danpos, it is a lineal method, opossite with the Lagrange that is not, so maybe this last one would be better when CQ curve is not lineal).

Edited: Sorry, I find out that Newton Raphson method is not Newton interpolation I talked with Danpos.

[hank315]

The undersizing using CQ_MAXBITRATE is probably caused because of the "lost bits" which aren't given back to the bitstream.
Keeping track of these lost bits and putting them back into the bitstream is still not implemented :(

Im worked on, but not tested yet, a prediction model based in Cuadratic Lagrange Interpolation polynomials. I have a test model wrote in Windows cmd scripting language (old dos batch). If anybody is interested in this, I can post it or PM it where you want.Yes, I'm interested.

BTW. Newton-Raphson is a very fast solution method, the convergence rate is quadratic.
One of the drawbacks is you have to know the derivative of the function but that can also be solved with some simple math tricks.

[Prodater64]

The undersizing using CQ_MAXBITRATE is probably caused because of the "lost bits" which aren't given back to the bitstream.
Keeping track of these lost bits and putting them back into the bitstream is still not implemented :(


I think it would be worh to work on that feature as CQ encoding mode would be much more accurate and predictable.


Yes, I'm interested.


http://rapidshare.de/files/5497745/Lagrange.zip.html

You will see in the batch file some equations that represents 3 sample encodings (3% each one).
Using that formulas you can find out the CQ_maxbitrate for a given sample length.
These equations have an error that can be calculated also.
Your target must to be between the extremes (and better near it). Opposite is extrapolation and it is not on this batch sight.
You can read something and view equations in http://mathworld.wolfram.com/LagrangeInterpolatingPolynomial.html
A brief search also will give you many results about Lagrange interpolation.

I hope you get success with OPV encoding soon.
See You.

[dragongodz]

The undersizing using CQ_MAXBITRATE is probably caused because of the "lost bits" which aren't given back to the bitstream.
I think it would be worh to work on that feature as CQ encoding mode would be much more accurate and predictable.
just a few small commens on this if i may. ;)

the maxbitrate limiting is already taking this slightly away from being CQ but is of course done with the purpose of dvd compatability.
now if you add the bits lost from this back in you are taking it away even more to the point it could really be considered a CQ/VBR hybrid. this does not mean hank315 shouldnt do it if he chooses but simply that maybe he would want to think about changing what its called.

as for predictability, well thats not really the encoders fault at all. it is not being given a bitrate or size to target only the quant to use and in this case the ability to adjust when they go ever the max bitrate. as such you will of course never get 100% predictability from a tiny sampling ,that includes with the bits put back in, but i guess it would make it more easy to be close for others doing the prediction. ;)

as for accurate though, sorry but HC is accurate because it is doing exactly what it is meant to, again it has no average bitrate or size to try and target only a quant. it is the prediction by other means that is not accurate. this of course goes back to the predictability by other means.

[Prodater64]

@dragongodz: My sentence was not in any way a negative one, sorry. English is not my native language so maybe my sentences couldnt be understood.
Sorry for that.
I hope hank and others now can understand what I meant.
I just want to contribute with this encoder wich in vbr mode gives almost perfect streams in all senses.
CQ_maxbitrate at the moment don't permit you a good prediction related to the final size.

[dragongodz]

My sentence was not in any way a negative one, sorry.
i didnt really take it as so either, sorry if it appears i did. ;)

CQ_maxbitrate at the moment don't permit you a good prediction related to the final size.
yes i was just trying to point out where these changes are taking the CQ mode and the fact that CQ is never 100% predictable and thats not really the encoders fault. to do that you need to give it either a target bitrate or size.

[hank315]

I hope you get success with OPV encoding soon.Well, I have a very premature version which I'm testing now.
Last night I did LOTR-Fellowship at bitrate 3200, it came out 0.6% oversized (bitrate 3221).
Prediction took about 8 minutes, one pass encoding was done in 1:55 hour (37 fps on a P4 3.2).
So far it looks promising...

[Prodater64]

Well, I have a very premature version which I'm testing now.
Last night I did LOTR-Fellowship at bitrate 3200, it came out 0.6% oversized (bitrate 3221).
Prediction took about 8 minutes, one pass encoding was done in 1:55 hour (37 fps on a P4 3.2).
So far it looks promising...


Wow!!
Thanks and keep the good work!!

[Darksoul71]

@Hank:
Sounds promising ! :D
BTW: Even the worst "Q-Factor" search (e.g. bi-section) will take something like 8-10 prediction-runs to hit your target size. This still would mean 90% time saving compared to a normal 2 pass encoding.

To me anything below 2% tolerance would be acceptable (something around 80 MB for a standard full DVD movie). I don´t need to fill a DVD to the limit. Those few kBit/s lost want hurt my eyes. I often experience undersized movies when using D2SRoBa. In case a movie is really oversized you still have the option to shrink the movie with rejig and please noone tells me that he´ll notice a decrease in quality when requantizing his mpeg by 2-5%.

I can´t wait to get my hands on the "OPV" version of HC enc :)

Take your time, Hank

-D$

[hank315]

As you can imagine it is not a real CQ mode, the prediction run (3 iterations) is done to get a nice starting Q.
While encoding the Q can vary if the target seems not to get hit exactly.
If only the prediction was used results were mostly done with a +/- 10% size error.
I think if anyone can do a real CQ run with an error always < 5% the prediction algorithm used is already *very* good.

[Darksoul71]

@hank:
As you can imagine it is not a real CQ mode, the prediction run (3 iterations) is done to get a nice starting Q.
While encoding the Q can vary if the target seems not to get hit exactly.

/me stupid ! This is something I don´t understand. Speaking as a complete layman for me CQ means constant quality = the encoder "does not care" about the bitrate spent (unless it´s above a defined bitrate level) and tries to keep the quality at a defined level. Having this in mind, I encode few (more or less reprensentative) pieces of my movie (e.g. SelectRangeEvery via AVISynth). For each CQ value I´ll get a certain final size depending on filters, compressibility of the movie, encoder settings, etc. Depending on your search approach you´ll find sooner or later at Q-value matching your target size. Unless your movie samples are not very representative for the complete movie or the encoder doesn´t keep the quality very well, you´ll mostly hit your target size within 2-3%. At least that was always my impression. Even with my scaled down formula I use for FitDVD and Komprezz2MPEG I´ve never really experienced oversized movies with CCE. Same goes for D2SRoBa / DVD2SVCD.

If I understand you correctly you are talking about a little different approach:
1) Doing CQ prediction similar to CQ search of e.g. AutoQ or D2SRoBa
2) Using this CQ value as base and adjusting the CQ value on the fly

Is this correct ? If yes, then I still don´t understand why this is really neccessary. I didn´thave the time to continue my work on the prediction code for HC enc but wouldn´t be supprised to get the same precision. May be HC enc is a bit different as it provides a finer scale for the Q-value compared to CCE´s integer values.

If only the prediction was used results were mostly done with a +/- 10% size error.
Hm, this keeps me thinking........
10% would mean something like 400 MB over/-undersize for a DVD media.

Well, I´ll keep my mouth closed and wait for your implementation <ggg>

-D$

[Xeno86]

While encoding the Q can vary if the target seems not to get hit exactly.
This sounds like 1-pass VBR :)

@Darksoul71
In HC CQ=Constant Quantizer not quality (as in TMpeg)

@hank315
You should change "Constant Q" to "Const. Quant." as many people confuse this "Q" with "Quality".

[Darksoul71]

@Xeno86:
uh oh, I guess I´m really a dumba$$ in regard to MPEG2 stuff :rolleyes:

CQ = Constant Quantizer <> Constant Quality ! Correct ?

I always thought that constant quantizer is somewhat identical to constant quality because the video is compressed with a constant "factor".

Well, I never told I´m an MPEG2 expert <ggg>

I guess I´m beginning to understand what hank talks about: He describes an encoding method which is similiar to the way realtime MPEG2 cards work in VBR mode: You specify a VBR average bitrate and a max bitrate. The hardware encoder tries to keep the average bitrate but will adjust the bitrate based on the action / complexity level of the movie -> a lot details / movements = more bits spent. Hank describes a similar approach where the quantizer is adjustet if the average bitrate of the movie get´s too high or too low.

-D$

[dragongodz]

This sounds like 1-pass VBR
yes it is in effect a type of 1 pass VBR. well not really, more a short predictive first pass to base second pass on. to the user it will be close enough to a 1 pass VBR ,or a VBR/CQ hybrid with pre-prediction if you want to get picky. ;)

In HC CQ=Constant Quantizer not quality (as in TMpeg)
You should change "Constant Q" to "Const. Quant." as many people confuse this "Q" with "Quality".
2 points.
1. HC is not tmpgenc so people should learn what HC is and not base things on ONE other encoder.
2. in the docs(pdf) that comes with HC it quite clearly states CQ is constant quant. people should read the docs before trying to guess.

He describes an encoding method which is similiar to the way realtime MPEG2 cards work in VBR mode: You specify a VBR average bitrate and a max bitrate. The hardware encoder tries to keep the average bitrate but will adjust the bitrate based on the action / complexity level of the movie -> a lot details / movements = more bits spent.
yes this is basic VBR.

[ernstblaauw]

Is it possible to queue some files in the GUI, so I can encode some movies over night?

I now only see a batch command in the command line version. Because I make always some mistakes if I have to make my own batch file, those encodings will (almost always) fail.

[Prodater64]

Is it possible to queue some files in the GUI, so I can encode some movies over night?

I now only see a batch command in the command line version. Because I make always some mistakes if I have to make my own batch file, those encodings will (almost always) fail.

For that exist the command line version.

Read this:

http://forum.doom9.org/showthread.php?p=692791#post692791

[ernstblaauw]

I encoded a home made movie (DV AVI) using HC 15a and later, when the problem still existed, with HC 16tr2. The movie just acts as normal if I watch the avi or the .avs (which only contains DirectShowSource() ).
The encoded movie has the correct length, but it does not contain the encoded movie, but only the last frame of the encoded movie, in a row (so I can watch the last frame for the correct length of the movie).
Anyone familiar with this problem?

edit: I just discoverd that during the first-pass, the preview window shows the correct movie. But in the second pass, already only the last frame is shown.

The command I used to start the encoding:
start "HC-Batch" /wait HCbatch_016_testrelease2_16-09-2005.exe "-ini" "D:\film progs\HC_016_tr2\hc - progressive.ini" "-i" "D:\Jox\Sodom.avs" "-o" "D:\Jox\MPEG2\Sodom.m2v" "-log" "D:\Jox\log\Sodom.log"

The ini:
+-------------------------------
HC.ini template
These commands are required
Use full pathnames and just use the bitrate you want
-------------------------------
*infile d:\Jox\
*outfile
*bitrate 8000
*maxbitrate 9000
-------------------------------
Next commands are optional
putting a space for it disables a command
Not all commands are shown here,
see the manual for a complete list and default values
-------------------------------
*aspect 4:3
*bias 30
*dc_prec 10
*logfile D:\film progs\HC_016_tr2\hc.log
*profile best
*wait 5
-------------------------------
Next commands you can specify interlaced
tff => top field first
bff => bottom field first
Don't know? Check with AviSynth command:
AsummeTFF() or AssumeBFF()
SeparateFields()
-------------------------------
*bff
*tff
*interlaced

The log:

--------------------------------------------
| HCbatch - MPEG2 encoder - rel. 0.16 beta |
--------------------------------------------

input: d:\jox\sodom.avs
output: d:\jox\mpeg2\sodom.m2v

--------------------
| encoder settings |
--------------------

profile: BEST
frames: 1 4950
framerate: 25.00
aspect ratio: 4:3
bitrate Kb/s: 8000
max. bitrate Kb/s: 9000
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 30
chapter frames: 0
time code: 0 0 0 0
CPU: SSE2
matrix: MPEG

--------------------
| source stats |
--------------------

nr. of frames in source: 4950
width*height: 720*576
fps: 25.00
nr. of frames to encode: 4950
frames to encode: 1 - 4950

---------------------
| encoding - pass 1 |
---------------------

pass 1 encoding time: 0:02:42 (162 s)
average fps: 30.7

--------------------------------
| encoding - intermediate pass |
--------------------------------

bitrate set to: 8000000 b/s
est. outfile length: 193359 kB
intermediate encoding time: 0.0 s

---------------------
| encoding - pass 2 |
---------------------

pass 2 encoding time: 0:06:26 (386 s)
average fps: 12.8

------------------
| encoding stats |
------------------

total encoding time: 0:09:09 (549 s)

intra matrix used
8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 37
19 22 26 27 29 34 34 38
22 22 26 27 29 34 37 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 58
26 27 29 34 38 46 56 69
27 29 35 38 46 56 69 83

non-intra matrix used
16 17 18 19 20 21 22 23
17 18 19 20 21 22 23 24
18 19 20 21 22 23 24 25
19 20 21 22 23 24 26 27
20 21 22 23 25 26 27 28
21 22 23 24 26 27 28 30
22 23 24 26 27 28 30 31
23 24 25 27 28 30 31 33

nr. of gops: 331
nr. of frames: 4950
nr. of I-frames: 331
nr. of P-frames: 1053
nr. of B-frames: 3566
average quant (non linear): 1.027
VBV underflows detected: 501
VBV underflows fixed: 501
minimum bitrate: 4030
maximum bitrate: 8958
average bitrate: 7610

[Centurione]

I got some similar problem (but not related to HC encoder), when using the "DirectShowSource(..) statment in the AVS script.
Sometimes, perhaps when the film has to be "rewinded", at the beginning of the second pass, not always this happens correctly.
Is this the case ?

regards, Centurione

[ernstblaauw]

I got some similar problem (but not related to HC encoder), when using the "DirectShowSource(..) statment in the AVS script.
Sometimes, perhaps when the film has to be "rewinded", at the beginning of the second pass, not always this happens correctly.
Is this the case ?

regards, Centurione
How can I avoid to use DirectShowSource? I don't see another possibility than using DirectShowSource to open the file. But it happens every time with this particular movie, and I didn't happened before with any other video.

[midnightsun]

avisource if it's an avi or mpeg2source if it's an mpeg1/2

[Prodater64]

I encoded a home made movie (DV AVI) using HC 15a and later, when the problem still existed, with HC 16tr2. The movie just acts as normal if I watch the avi or the .avs (which only contains DirectShowSource() ).


Im wondering why you download the last version without read what hank315 wrote about it:

http://forum.doom9.org/showthread.php?p=712482#post712482

A new test release: http://hank315.dyndns.org/HCbatch_016_testrelease2_16-09-2005.zip

Thanks for the feedback, most issues are solved now:
- hangs while running minimized
- wrong GOP size for some fixed GOPs
- artifacts at the right side of some frames

The artifacts were caused because motion vectors could point out of the frame by half a pixel, some decoders don't like that...

Still one issue left, using Avisynth DirectShowSource with the WMV decoder sometimes won't read the stream correct during the second pass, it can skip frames or even jump back.

As your file is an avi try Avisource() (I don't know if it can manage digital video)

[ernstblaauw]

Im wondering why you download the last version without read what hank315 wrote about it:

http://forum.doom9.org/showthread.php?p=712482#post712482



As your file is an avi try Avisource() (I don't know if it can manage digital video)
I read the comment, but the video is not a WMV, but a DV AVI (it is not the same, is it?). So I assumed I could use DirectShowSource. I will now try it using AVISource.

[Boulder]

DirectShowSource can be problemous at times so that might well be the cause.

[ernstblaauw]

DirectShowSource can be problemous at times so that might well be the cause.
I just changed all 'DirectShowSource()' to 'AVISource()' in my AVS-files. No I'm reencoding using a batchfile. Luckily it are not that big files.
Again a lot of thanks to Hank315 for delivering such a high quality encoder!

[Prodater64]

I just changed all 'DirectShowSource()' to 'AVISource()' in my AVS-files. No I'm reencoding using a batchfile. Luckily it are not that big files. ...

Just for test you can append to your avisource() command a selectrangeevery(1200,12) and it will give you a 1% sample. (or 1500,15, or 2500,25)

avisource("c:\...", false).SelectRangeEvery(1500,15)

[colinb]

I'm thinking of giving HC a try to convert letterboxed 4:3 to anamorphic 16:9 using crop and LanczosResize in avisynth.

The input will be an mpv file which was previously demultiplexed from a VOB. Can I open an mpv file directly in avisynth or do I need to pre-process it first?

How does HC know the frame rate to use in the encoding - there doesn't seem to be a setting for that? Yes it just has to encode each input frame so it shouldn't matter but presumably it needs to store the frame rate in an MPEG header?

I'd also be interested if anyone can suggest any avisynth filters that I could run on the decoded mpv which might help HC produce a better encode.

[jdobbs]

You could use DGINDEX/DGDECODE to read the mpv files through AVISYNTH. The framerate, etc., is available through the simulated AVI.

[colinb]

Thanks. Sorry for being thick but what do you mean by the simulated AVI ?

Does this mean that the frame rate value is preserved from the AVIsynth input (mpv) through to the AVIsynth output to HC (so you don't have to worry about it) ?

[Prodater64]

Thanks. Sorry for being thick but what do you mean by the simulated AVI ?

Does this mean that the frame rate value is preserved from the AVIsynth input (mpv) through to the AVIsynth output to HC (so you don't have to worry about it) ?

If you create an avs script without any fps filter resulting video will have same fps as original one.
Also you could want to change fps, then you should to use something like convertfps() in the script and the resulting video will have fps enclosed by parenthesis.

[colinb]

Thanks. I just tried it out and the results are very impressive even without using any Avisynth filters.

The source video was encoded as interlaced top-field-first, but on stepping through the fields it was clear that the material itself was progressive. So I decided that it would be better to do the re-encoding as progressive. It seemed to make sense to let the encoder encode whole frames at once rather than split it into fields and encode those separately when they really were not true fields with temporal separation. And giving Avisynth a whole frame on which to perform the resampling/resizing seemed better than it having to resize the fields separately.

Also if I had encoded as interlaced and it was played back on a player which needed to re-letterbox it (for a 4:3 TV) then it would have to deinterlace, scale, then interlace again - it seemed to make more sense to just encode it as progressive then the player would just have to scale and interlace. I hope that makes sense.

This is my simple script (there may be some mistakes as this is from memory, not a cut & paste):

# Convert PAL letterbox to anamorphic
LoadPlugin("dgdecode.dll")
mpeg2source("myvideo.d2v")
AssumeFrameBased()
Crop(0,72,0,-72)
LanczosResize(720,576)

Unfortunately some letterboxed source material is encoded slightly zoomed-in (square-er than 16:9) so I'll have to decide whether to clip some of the top and bottom of of the image, or zoom out a little in the resize so that there are narrow black columns on either side. I didn't like the idea of zooming out much as this would introduce resampling in the horizontal direction aswell whereas the above only resamples in the vertical direction - although in practice it may make no visible difference!

Alternatively crop and stretch the image a little LESS vertically and hope that it isn't really noticeable. e.g.

Crop(0,60,0,-60)
LanczosResize(720,576)

Incidentally, is there likely to be a problem with resizing material sourced from a DVD in this way as regards the color sampling? i.e. is any correction to the color sampling needed before rescaling?

[bucho]

I was reading awhile ago about a problem with blocking. All the blocking occurs during high action scenes. I have yet to encode a clip using HCEnc that doesn't produce some blocking on my DVD Player (have confirmed this on at least one other DVD Player). All encoded clips play fine on a PC.

I use FitCD to create very simple scripts (aside from a crop and resize, no filters). I have tried various settings (using the standard 4000-8000 bitrates or using CQ values of 2-5), various clips and use the standard MPEG matrix. Passing the same script to QuEnc produces clips that play flawlessly on stand alone players.

Is there anything that I could be doing that would cause this?

[urvieh]

The current version seems to have problems with certain hardware players, a Pioneer 520 DVD-R in my case. This will be fixed in the next version.

From what I have understood, QuEnc uses the same motion vector length but does not produce blocking. Maybe the powers that be have a weird sense of humour ... :-).

Switch back to v0.14 until 0.16 is out.

[Xeno86]

On my Panasonic S35 QuEnc, FreeEnc, Mencoder and other libavcodec based encoders produce heavy blocking at motion scenes, but guess what... HC doesn't !!

Isn't that strange? :)

[Boulder]

Switch back to v0.14 until 0.16 is out.
Have you tried the v0.16 test release 2?

[urvieh]

No, I haven't. If it works fine with my stand-alone, I'll have enough time to wait. If it doesn't, it doesn't mean anything.

[LigH]

Just a remark:

Hank's MPEG-2 encoder was tested in version 0.15A in the german "PC-Magazin 11/05" in an article over four pages. Result: "Surprisingly good, almost equal to CCE, surpassing TMPGEnc in high motion scenes easily". Hmm... well, the "PC-Magazin" is not really one of the most respected magazines by professionals; but at least, good to see that HC is considered a serious competitor already!
__

Oops - there is already an own thread (http://forum.doom9.org/showthread.php?t=101033) about it ... sorry.

[urvieh]

LigH, don't get me wrong, HC is excellent, and so is DVD Rebuilder. I just wanted to say that there must be a problem if either DVD-RB or HC or both produce about 7 % too many data. Please understand it as an attempt to help, not a complaint. :)

[FredThompson]

I don't have that problem with HC and DVD-RB Pro 1.01 nor does it happen here with 0.94/5/whatever...the freeware version.

[Prodater64]

@hank315:

As you know (i think so) i was working a lot with HC, specially in cq_maxbitrate mode. Im waiting for HC with OPV and prediction routines and i hope the program could soon to bring back to the stream those bits tha ATM it merely cut.
Meanwhile i want to point you that the GOPs in multi pass vbr, cq and cq_maxbitrate modes are not all of same fixed length.
This behaviour in CQ mode is not desirable as it make prediction imprecise.
Maybe you already has thought this point, so my appointment is just in case.
Thanks.
See you.

[asia_minor]

Apologies if I should've looked deeper into the documentation or something, but I was wondering if there is a "restart pass 2" option (or something similar) in the GUI somewhere (like 0.15 had).

Anyway, this is a really nice MPEG2 app, and the price is perfect :)

Thanks hank315 for the work you put into this app!

[hank315]

No, the restart option is dumped...
It was just too complicated to support it with the new GUI.

[LigH]

After you had a session with katjarella (as far as she told me) - did you succeed in hunting the last bug of the 0.16 test version, towards a Release (Candidate)?

[acki]

Is there a known bug list somewhere ?

I've been having a problem with HC 0.16 since beta. Release is not
working either.

Scenario:

Two huffyuv (via ffdshow) encoded AVI files. ONE is EVEN fields and TWO is
ODD fields from interlaced source.

AVS script (mixfields.avs):
-----------------------------------------------------------------
ODD = avisource("two.avi").AssumeFieldBased()
EVEN = avisource("one.avi").AssumeFieldBased()
Interleave(EVEN,ODD)
Weave()
# No need to converttoyv12(), it is YV12 already.
-----------------------------------------------------------------

INI file feeded into (last) HCBATCH. Created with HCGUI 016
---------------------------------------------------------
*INFILE z:\mixfields.avs
*OUTFILE z:\mixedvideo.m2v
*LOGFILE z:\mixedvideo.log
*BITRATE 4000
*MAXBITRATE 8000
*FRAMES 1 18871
*PROFILE best
*ASPECT 4:3
*DC_PREC 10
*INTERLACED
*BFF
*CLOSEDGOPS
*PREVIEW
*MATRIX avamat7
-------------------------------------------------------------------


Another INI created with HIG
------------------------------------------------------------------
______________________________________________
HIG 0.16.1.0 INI.template
______________________________________________
*infile z:\mixfields.avs
*outfile z:\mixedvideo.m2v
*logfile z:\mixedvideo.log
*bitrate 4000
*maxbitrate 8000
*profile best
______________________________________________
*matrix AVAMAT7
*frames 0 0
*autogop
______________________________________________
*dc_prec 10
*cpu AUTO
*scanmethod ALT
*aspect 4:3
*bias 30
*timecode 0 0 0 0
*TFF
*interlaced
______________________________________________


Ther result is NOTHING. HCBATCH (0.16) opens and immediately closes. HCGUI 016 beta yields the same results. Nevertheless, HCBATCH 015 and HCGUI 015 work flawlessly.

Any hints anyone ? Is it just me or could it be a bug ?

Thanks.

[Boulder]

Use DirectShowSource to open the files. I've noticed that AVISource+ffdshow is not a working combination with HC.

[acki]

@Boulder: :thanks::thanks::thanks::thanks:

I was getting really nuts about this issue... er... is this be considered
a bug or just a feature ? I mean... is it intended or just faulty ?

Anyhow, thanks a lot again. And very many thanks to Hank315 for a _GREAT_
tool.

Regards.

[vlada]

@acki: I think it is a bug and it should be fixed. I can reproduce it too. I wanted to covert a DivX 3 movie to DVD and used FFDShow as VfW codec. I got the same behaviour as you, although the AVS script works fine in VD and HC015. Then I disabled DIV3 in FFDShow, so DivX 5 decoder is used, and everything works fine.

I noticed also another strange thing, if I select XviD decoder in FFDShow VfW configuration, it works without problems in HC. What is causing this issue? Can you fix it hank315, please? It is the only problem I have with your great encoder.

Btw. I have one feature requests: I'd like HC to automatically fill-in output LOG and M2V paths/files according to input AVS file. Thank you.

[gilligan2]

Hello Hank,and Happy Holidays to you. Just wanted to drop you a line to let you know how much i appreciate all your efforts on your encoder. I use it for any movies over 2 hours and 20 minutes because it does a very nice job with them. But i use CCE with the shorter ones because of the time difference in encoding.
Have you still got plans to enable multi processor/thread ability on HC Enc ? and if so,any ETA on when it would become available.

Thanks again for all your work !!

g:) :cool:

[Schnoodledorfer]

Sorry if this is posted elsewhere (or is common knowledge), but a forum search turned up only two mentions of "HCO17", and neither of them were on a thread specifically about HC Encoder. (One was about tools for HC, but some people might not be using them.)



Click here to download the latest HC Encoder.
Currently hosting version v0.17 (05-Feb-2006).

Change log:

* more options for CQ encoding
* added gop, frames and chapter command as parameters for HCenc
* create a chapter list based on scene changes
* frame count starts at 0
* GUI bug fixes
* frame serving bug fixed
* memory error bug fixed

Last Updated ( Sunday, 05 February 2006 )


I also noticed another quote (on other pages for both HC016 (http://www.bitburners.com/Software/Download/Video_Codecs_and_Encoders/HC_Encoder/HC_Encoder_v0.16/) and HC017 (http://www.bitburners.com/Software/Download/Video_Codecs_and_Encoders/HC_Encoder/HC_Encoder_v0.17/)):
HC Encoder is high quality freeware MPEG-2 encoder by Hank315. HCEnc is supported by DVD-RB and is considered to be the best freeware encoder for DVD backups and is able to challenge all commercial encoders as well.
Is that hyperbole? I haven't tried it yet, so I don't know.

I also noticed that only the HC016 page has this:
License: Freeware
OTOH, I didn't see anything in the download that says anything about backing away from being freeware, so I assume that doesn't mean anything.

@Hank315: I hope you intended this to be public knowledge. :D Also, it might help people figure out the latest version and download location if you include that in your signature. I think (not certain) the forum software always displays the current sig, even when people are reading older posts. Just a suggestion.

[smok3]

Is that hyperbole? I haven't tried it yet, so I don't know.
is not (at least on the progressive DV & MJPEG source material i tested it on, didn't test interlaced stuff yet.)

also on blind comparision between mjpeg source and hc016 q5.maxbitrate a small group of ppl was not able to tell the difference on the 19" CRT monitor (iam sure lcd could show more thought).

[Boulder]

Sorry if this is posted elsewhere (or is common knowledge), but a forum search turned up only two mentions of "HCO17", and neither of them were on a thread specifically about HC Encoder. (One was about tools for HC, but some people might not be using them.)

Didn't you notice the thread "HC encoder, release 017" ? If you searched for O17, no wonder you didn't find what you wanted to ;)

[Schnoodledorfer]

Didn't you notice the thread "HC encoder, release 017" ? If you searched for O17, no wonder you didn't find what you wanted to ;)
No, I didn't see the HC encoder, release 017 thread, but I sure did see HC encoder, release 016. That figures! :rolleyes: Another thing that threw me is that the starter post on this thread still says:
HC016 latest release at: http://hcencoder.bitburners.com/
At least I didn't search for HCO17 - that was just a typo that fortunately I didn't make on the search page. But it wouldn't have done any good to search for '017' either; the forum doesn't index 3-letter words, apparently. I might have found it using Google (017+site:forum.doom9.org), though.

I assumed hank315 was busy and didn't think to post/edit anything here. Oh, well...

[Sounddude]

@Hank315,

Would it be too much to ask to have the 017 gui work like the 015 version in respect to when you select your AVS file it automatically fills in the .m2v and .log file in the same location or is the way it is now from an earlier request?

Your encoder is about the only one i use now, keep up the great work

[Boulder]

I also have one small request : could you make the fps show as floating point values, for example 5.4fps etc.

[Firesurfer]

@hank315

First:
Please keep up the great work! :)

A bug:[edited]
Just a small glitch in the GUI, before loading a script or d2v, when you click the 'file length' radiobuttion, then put in 2000000 (thats what I did), click on the 'max bitrate' field and then back into 'file length' the GUI just crashes.

And a small request:
could the 'shutdown' option be made switchable while the encoder is running? Sometimes I just what to change that without restarting the whole process.

Firesurfer

[Heini011]

Hi,

i want to use HCenc 0.17 for dvd backup without colorspace-conversion like in cce. the movie is well denoised and sharp. i tried it serveral times, but the hc result is a not dvd-compliance stream, according to dvd-lab 1.4b2: "A serious error occured during compiling the files. the compile process can't continue... make sure..", no further hints of the problem...

i have no problems with cce generated streams...

hc.ini:

*INFILE d:\foo\foo-dvd.avs
*OUTFILE d:\foo\foo-hc.m2v
*LOGFILE d:\foo\foo.log
*BITRATE 5390
*MAXBITRATE 9000
*FRAMES 0 154283
*PROFILE best
*DC_PREC 10
*CUSTOMMATRIX
8 11 11 12 13 14 17 20
11 11 12 13 15 17 20 22
11 12 13 15 18 20 22 25
12 13 15 18 21 23 25 28
13 15 18 21 23 26 28 32
14 17 20 23 26 29 33 38
17 20 22 25 28 33 40 48
20 22 25 28 32 38 48 60

12 13 14 14 15 16 17 20
13 14 14 15 16 17 20 22
14 14 15 16 18 21 22 26
14 15 16 18 21 23 26 28
15 16 18 21 23 27 29 31
16 17 21 23 27 29 32 35
17 20 22 26 29 32 36 41
20 22 26 28 31 35 41 48


foo.log

-----------------------------------------
| HCenc - MPEG2 encoder - rel. 0.17.0.0 |
-----------------------------------------

input: d:\foo\foo-dvd.av
output: d:\foo\foo-hc.m2v

--------------------
| encoder settings |
--------------------

profile: BEST
frames: 0 154283
framerate: 25.00
aspect ratio: 16:9
bitrate Kb/s: 5390
max. bitrate Kb/s: 9000
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 0
chapter frames: 26
time code: 0 0 0 0
CPU: MMX/ISSE
matrix: CUSTOM

--------------------
| source stats |
--------------------

nr. of frames in source: 154284
width*height: 720*576
fps: 25.00
nr. of frames to encode: 154284
frames to encode: 0 - 154283

---------------------
| encoding - pass 1 |
---------------------

pass 1 encoding time: 1:49:24 (6564 s)
average fps: 23.5

--------------------------------
| encoding - intermediate pass |
--------------------------------

bitrate set to: 5390000 b/s
est. outfile length: 4060502 kB
intermediate encoding time: 0.5 s

---------------------
| encoding - pass 2 |
---------------------

pass 2 encoding time: 1:48:35 (6515 s)
average fps: 23.7

------------------
| encoding stats |
------------------

total encoding time: 3:38:00 (13080 s)

intra matrix used
8 11 11 12 13 14 17 20
11 11 12 13 15 17 20 22
11 12 13 15 18 20 22 25
12 13 15 18 21 23 25 28
13 15 18 21 23 26 28 32
14 17 20 23 26 29 33 38
17 20 22 25 28 33 40 48
20 22 25 28 32 38 48 60

non-intra matrix used
12 13 14 14 15 16 17 20
13 14 14 15 16 17 20 22
14 14 15 16 18 21 22 26
14 15 16 18 21 23 26 28
15 16 18 21 23 27 29 31
16 17 21 23 27 29 32 35
17 20 22 26 29 32 36 41
20 22 26 28 31 35 41 48

nr. of gops: 10559
nr. of frames: 154284
nr. of I-frames: 10559
nr. of P-frames: 42112
nr. of B-frames: 101613
average quant (non linear): 3.332
VBV underflows detected: 81
VBV underflows fixed: 81
minimum bitrate: 183
maximum bitrate: 8967
average bitrate: 5381

[Boulder]

Try muxing with MuxMan and see what it reports. It could be that you've run into the same problem I had some time ago, and it's caused by the HC rate control.

[Heini011]

dvd-lab pro 1.53 trial can compile my hc encoded project!

but dvd-lab 1.4b2 can only compile my cce encoded stream ?!

btw: same problem with HCenc 0.16

[Heini011]

ahh...

i worked on my pc while hcenc gui was running in the background. i wrote a text as hcenc suddenly finished the job and popped up. i was just hitting 'enter' and hcenc starts again and overwrites the already encoded file. :-(

please change that behaviour of the gui! it is really annoying!

[Rockas]

I just noticed (during my SynthEditor tests) that when the avrg bitrate is set to 8000kbps (or more... I didn't test inferior values yet) and the max is set to 9000... the second pass is slower than the first... anyone has noticed this?

[Mug Funky]

the closer avg is to max, the more underflows need fixing, the slower it goes.

HC's super-safe underflow prevention means GOPs get re-encoded, and the more the encode rides the max bitrate, the more this is going to happen :)

[PlazzTT]

I'm encoding from an AVS file (which loads an Arithyuv AVI using AviSource) and I find that the preview only works for first pass?

Not a critical problem, I'm just wondering if the problem is at my end?

[Riuyin]

:confused: I want to encode some videos (10 total), i try to use the batch mode and have some problems all my videos are loaded from an avs (dvd1.avs,dvd2.avs......dvd#.avs):

In the pdf of hc encoder it says "Parameters passed have a higher priority than the values supplied in the ini file.", but thats not true, let me explain what happen, these are my files:

HC.ini

*INFILE g:\dvd\dvd1.avs
*OUTFILE g:\dvd\ep.m2v
*BITRATE 4015
*MAXBITRATE 9000
*FRAMES 1 33566
*PROFILE best
*ASPECT 4:3
*CLOSEDGOPS
*MATRIX mpeg

I crated a bat file i will put only the first 2 lines.

encode.bat

HCbatch_016.exe –i G:\dvd\dvd1.avs –o G:\dvd\ep1.m2v –b 4015 –maxbitrate 9000 –ini G:\dvd\HC016\HC.ini
HCbatch_016.exe –i G:\dvd\dvd2.avs –o G:\dvd\ep2.m2v –b 4015 –maxbitrate 9000 –ini G:\dvd\HC016\HC.ini

The result of the first line HC crates a file name ep.m2v instead of ep1.m2v, after that HC overwrite the file, so HC takes the Parameters for input and output from the ini thats is not a problem.

I tried to create another hc.ini file (HC2.ini) and edit the first hc.ini i had:

HC.ini

*INFILE g:\dvd\dvd1.avs
*OUTFILE g:\dvd\ep1.m2v
*BITRATE 4015
*MAXBITRATE 9000
*FRAMES 1 33566
*PROFILE best
*ASPECT 4:3
*CLOSEDGOPS
*MATRIX mpeg

HC2.ini

*INFILE g:\dvd\dvd2.avs
*OUTFILE g:\dvd\ep2.m2v
*BITRATE 4015
*MAXBITRATE 9000
*FRAMES 1 33566
*PROFILE best
*ASPECT 4:3
*CLOSEDGOPS
*MATRIX mpeg

I chance the bat too.

encode.bat

HCbatch_016.exe –i G:\dvd\dvd1.avs –o G:\dvd\ep1.m2v –b 4015 –maxbitrate 9000 –ini G:\dvd\HC016\HC.ini
HCbatch_016.exe –i G:\dvd\dvd2.avs –o G:\dvd\ep2.m2v –b 4015 –maxbitrate 9000 –ini G:\dvd\HC016\HC2.ini

Now the problem is: First line create a ep1.m2v cuz thats the output in the HC.ini, but in the second line hc does the same that in the first line (overwrites the ep1.m2v) so HC doesn't change the ini too.

If i delete *INFILE and *OUTFILE in the ini i get an error "input not complete" as you can see the batching mode is not passing any of the parameters.

[Ebobtron]

@Riuyin
What are we going to do with you. :)

Take the ini file out of your batch file and use it for the things common to all files and pass only those things that are dif.

If you pass the ini file in the command line, HC will do as told.

Try that. I think you'll find that it will work.

Shameless plug
http://members.aol.com/avsfilmcutter

[Riuyin]

@Riuyin
What are we going to do with you. :)

Take the ini file out of your batch file and use it for the things common to all files and pass only those things that are dif.

If you pass the ini file in the command line, HC will do as told.

Try that. I think you'll find that it will work.

Shameless plug
http://members.aol.com/avsfilmcutter

I did as you told (Take the ini file out of your batch file) but i can't delete *INFILE and *OUTFILE in the ini so it is doing the same.

[Ebobtron]

you do
HCbatch_016.exe –i G:\dvd\dvd1.avs –o G:\dvd\ep1.m2v –b 4015 –maxbitrate 9000 –ini G:\dvd\HC016\HC.ini
do this instead
HCbatch_016.exe –i G:\dvd\dvd1.avs –o G:\dvd\ep1.m2v –b 4015 –maxbitrate 9000
or this if the above does not work
HCbatch_016.exe –i "G:\dvd\dvd1.avs" –o "G:\dvd\ep1.m2v" –b 4015 –maxbitrate 9000

the last line works for me in filmcutter (http://members.aol.com/avsfilmcutter) with a fixed INI file than looks like this

*INFILE e:\christmas.avs
*OUTFILE e:\pop2.m2v
*BITRATE 4000
*MAXBITRATE 8000
*FRAMES 0 7572
*INTERLACED
*TFF
*NOSEQ_ENDCODE
*MATRIX mpeg

note that inserting a space in front of a line disables it.

oops my bad try HC 17 if your are indeed using 16

[Riuyin]

:rolleyes: I'm missing something look.

HC:ini

*INFILE g:\dvd\dvd1.avs
*OUTFILE g:\dvd\ep1.m2v
*BITRATE 4015
*MAXBITRATE 9000
*FRAMES 0 33565
*PROFILE best
*ASPECT 4:3
*CLOSEDGOPS
*MATRIX mpeg

I'm this case using 017 ver, i will put some imgs

http://www.geocities.com/riuyin_vahn/error1.JPG

http://www.geocities.com/riuyin_vahn/error2.JPG

As you can see the input and output is the same and look that in both cases arguments are not passed

[Ebobtron]

and your hc.ini is in the same folder as HCenc_017.exe ??

I am missing something too.

[Riuyin]

Yes the hc.ini is in the same folder

A solution just came to my mind and it is just that after the fisrt line in the bat file, we can prevent the .m2v file to be overwrite like this:

.bat

HCenc_017.exe –i "G:\dvd\dvd1.avs" –o "G:\dvd\ep1.m2v" –b 4015 –maxbitrate 9000
del G:\dvd\dvd1.avs
ren G:\dvd\dvd2.avs dvd1.avs
ren G:\dvd\ep.m2v ep1.m2v
HCenc_017.exe –i "G:\dvd\dvd1.avs" –o "G:\dvd\ep1.m2v" –b 4015 –maxbitrate 9000
del G:\dvd\dvd1.avs
ren G:\dvd\dvd3.avs dvd1.avs
ren G:\dvd\ep.m2v ep2.m2v

:rolleyes:I should have think that before

[Ebobtron]

that is a solution, but not much of one. I have tried to duplicate your trouble and can not, sorry I am no help. :o

The only time I have trouble passing arguments from cli to HC is when I introduce an error.

[Boulder]

Did you try feeding only the ini file in HCenc_017? I always create an ini file for each video clip I need to encode and create a bat file which only loads the ini file in HC.

Your two ini files are the same except for the input and output file so there's no need to add any other cli parameters.

[JasonFly]

Hi!

I 've tried to use HCenc0.17 to encode some VHS capture in MPEG2 but I've been faced with some problems. I know it's not related to HCenc but I want to know if there is a possible workaround.

The problem is that I have 39 2Gb (lossless lagarith) files which I load into Hcenc with avisynth's AVISource(). I've seen in the avisynth forum that AVISource isn't able to load a high number of files at the same time.(VirtualDub doesn't want to open an avs file with more than 70 files for example)

Hcenc is able to open the avs with 39 files(the preview also works) but when I start the encode, it doesn't want and close(ERROR, invoke, pass1). I've tried to encode without using the GUI with a .bat but again, HVEnc doesn't want and show the same error message.

Is there a work around or should I'l try an other way to load my files to HCenc?

[Boulder]

What is your script?

[JasonFly]

Her is my script:
Clip=AviSource("I:\1993\1993.00.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.01.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.02.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.03.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.04.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.05.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.06.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.07.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.08.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.09.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.10.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.11.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.12.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.13.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.14.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.15.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.16.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.17.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.18.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.19.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.20.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.21.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.22.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.23.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.24.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.25.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.26.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.27.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.28.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.29.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.30.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.31.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.32.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.33.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.34.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.35.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.36.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.37.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.38.avi").ChangeFPS(25000, 1000)++AviSource("I:\1993\1993.39.avi").ChangeFPS(25000, 1000)

Deinterlace=Clip.Telecide(order=1,guide=2,post=2,gthresh=15,vthresh=20,dthresh=4,blend=false,nt=20,show=false).ChromaShift(C=6).cnr2("xxx", 4, 5, 255).ColorYUV(gamma_y=16,cont_y=16,cont_u=24,cont_v=24).Fluxsmooth(7,7).crop(20,2,698,570).BicubicResize(720,576,0.33,0.33).Blockbuster(method="noise",block_size=4,detail_min=1,detail_max=10,luma_threshold=1,luma_offset=0,mean=0,variance=0.5,cache=2048,seed=0)

Return Deinterlace

[Boulder]

Try adding ConverttoYV12() at the end of the script.

[JasonFly]

Thank you for your response Boulder but that didn't helped. Same message. I 've found some method in the avisynth forum. It uses batch and Vdub frameserving to append all the files and to use AviSource only once, but it's complicated and I don't know if I can adpt this method to my capture files which haven't exactly the same framerate.

Other ideas are welcome

[jdobbs]

Have you tried SegmentedAVISource? Your files look like they were meant for it...

Maybe like this:

Clip=SegmentedAVISource(("I:\1993\1993.avi").ChangeFPS(25000, 1000)

[JasonFly]

Yes, I have tried but I don't know why, that only load the first clip. Maybe because of the fps which isn't quite the same.(In capture, fps isn't always perfectly 25)

Besides, SegmentedAVI uses UnalignedSplice whereas I need Alignedsplice(for audio synchronisation)

[Boulder]

You could open the script in VDub and save as AVI using HuffYUV for example (ffdshow has a YV12-capable HuffYUV) and then loading that clip in HC with another script.

[JasonFly]

I think I'll do that for these files. Thanks

Besides, I didn't remember AVI filesize wasn't limited in NTFS, so I'll capture to one big file for the next capture I'll do.

Sorry for this discussion which wasn't really related to HCEenc.

[boombastic]

I use DVD-RB PRO to backup my DVDs using HC as the encoder;i've got a question:suppose i do an OPV encode and get a final size of 4,37 GB(in a real case matbe the final size is not so exact...) and let's say i do a 2-pass encode with the same final size:is it always true that the 2pass encode results in a superior quality?Or does it depend on the bitrate range used or on some other factor?Apart from using every singòe byte of the dvd,is always better in terms of quality to use a 2pass encoding?

[Boulder]

A 2-pass VBR may or may not look better than OPV. Depends on the situation.. I'd say usually the difference cannot be seen if the average bitrates are close enough to each other. That is, if we are talking about constant quality type OPV.

I use CQ mode (@q2 and a hi-bitrate matrix) with max bitrate check in HC if I don't have to worry about the filesize.

[boombastic]

I do care about filesize because the movie must fit into a dvd,but with the prediction function of DVD-RB,this is not a problem,so when i want backup a dvd with a final bitrate around 3000 Kbps i need to choose between a 1pass opv and a 2 pass encoding and if you consider that i always use the best profile in HC it means that choosing a 2pass means 4 hours more in the encoding.That's why i'm asking that.

[Boulder]

I'd say the only way to know what your eyes think is to try.

I've often usen CCE's OPV and been happy with the results. Then again, I've been happy with a 2-pass encode by CCE as well;) You'll have to remember that OPV is never dead accurate so you might end up with serious over/undersizing which then requires a re-encode. The same goes for HC's CQ mode.

[dragongodz]

please note that HC's CQ is constant quant and should not really be called OPV. it is not OPV in the sense of variable bitrate with variable quants. the only time quants will vary is with the check vbv/max bitrate constraint.

CQ mode (@q2 and a hi-bitrate matrix)
of course at a very low quant such as that it would be hard to tell any difference. however if you are encoding something much larger where the average quant was more like 10(just as an example) then it would be much easier to see where varying the quants, such as the ability to use lower quants, has clear advantages.

You'll have to remember that OPV is never dead accurate
real One Pass VBR can actually be accurate. the RC does need to keep it fairly well under control of course which some do not. the problem is so many think of Constant Quant as being One Pass VBR because of course the bitrate itself does vary with CQ because of the variance of the footage. however it is better to keep clear that these are not the same thing. real OPV you can set a target bitrate for while CQ you can not.

[Boulder]

Yep, actually the term OPV points to CCE.. although lately it seems they have changed it to 1-pass VBR ;)

Since HC doesn't offer CBR, I've used CQ mode for all encodes that are not size dependant. One option would be to use the same value for max and avg bitrate, but I thought I'd give the standalone some breathing space by using CQ with a very low quant.

[Boulder]

I just noticed that with Avisynth 2.5.7alpha, you need to add the line SetPlanarLegacyAlignment(true) to the avs script.

[IanB]

@Hank315,

I thought you were going to fix the pitch assumptions, slipped thru the crack? ;) PM me if you need any help or hints. In 2.6 the pitch and alignment of each plane will be independant, possibly even in different buffers. Always use the GetPitch method.

Regards
IanB

[dragongodz]

hank315 has been busy with work among other things. however he has been working on things(you will have to wait to find out so dont ask). ;)

he is aware of the reported problem however.

amazing how i know all these things isnt it. :D

[IanB]

@dragongodz,

Has Hank released the source for HC to anyone?

[dragongodz]

not that i am aware of. though that doesnt mean he hasnt of course, just that i do not know. :)

i for example have only seen small sections/snippets of code when hank315 has asked my opinion on how to fix certain problems etc.

[techmule]

please note that HC's CQ is constant quant and should not really be called OPV. it is not OPV in the sense of variable bitrate with variable quants. the only time quants will vary is with the check vbv/max bitrate constraint.


of course at a very low quant such as that it would be hard to tell any difference. however if you are encoding something much larger where the average quant was more like 10(just as an example) then it would be much easier to see where varying the quants, such as the ability to use lower quants, has clear advantages.


real One Pass VBR can actually be accurate. the RC does need to keep it fairly well under control of course which some do not. the problem is so many think of Constant Quant as being One Pass VBR because of course the bitrate itself does vary with CQ because of the variance of the footage. however it is better to keep clear that these are not the same thing. real OPV you can set a target bitrate for while CQ you can not.

How to get CQ work to your expected final file size, is still a big questionmark. I used GetCQ tool also and the size is always way out. I just tried it again yesterday and it came out to be 4.87GB. If its few MB less, its acceptable, but over is a waste of time.

Unless someone can give some good recommendations on how to get the CQ feature of HC working to your expectations, I would stay clear of it.

Why was this feature developed in first place itself ???, if it cannot be tamed.

[Boulder]

The prediction can never be dead accurate as the sample may or may not represent the whole clip well. That is the problem with CQ (be it constant quant or quality) based methods. The only advice I can give is to increase the sample size.

[techmule]

The prediction can never be dead accurate as the sample may or may not represent the whole clip well. That is the problem with CQ (be it constant quant or quality) based methods. The only advice I can give is to increase the sample size.


I understand that and i am okay with few MB+/-, as long as they fit the DVD :)

How much sample % in your opinion should be good enough and reliable ???

[Boulder]

I've used 1-5% myself but that cannot ensure an accurate result.

[Inc]

The only advice I can give is to increase the sample size.Or use that ping pong technique using offsets on every turn so you end up in the same prediction time but with more samples in a whole used.

[techmule]

Or use that ping pong technique using offsets on every turn so you end up in the same prediction time but with more samples in a whole used.

I guess, GetCQ uses that script only for its predicted Q value.

[dragongodz]

Why was this feature developed in first place itself ???, if it cannot be tamed.
because it was basically meant to be a more or less consistant/quick 1 pass encode where file size, max bitrate etc were not really important. no it wasnt really designed for constrained formats such as svcd/dvd etc or when you are actually going for target size/bitrate accuracy. this doesnt mean you can not use it for such just that you should be aware of its limitations when doing so.

[DarkNite]

Just wanted to chime in and say thank you for the excellent work. I've finally gotten around to testing this release out, and was quite pleased with the overall results in comparison to the versions I have used previously.

Now if I just had more boxes with SSE2 support... :)

[hank315]

I thought you were going to fix the pitch assumptions, slipped thru the crack? It just didn't made it into HC017 but it will be in the next release.

Has Hank released the source for HC to anyone?No, but dragongodz and I mail a lot to discuss all kind of MPEG related stuff.

[techmule]

because it was basically meant to be a more or less consistant/quick 1 pass encode where file size, max bitrate etc were not really important. no it wasnt really designed for constrained formats such as svcd/dvd etc or when you are actually going for target size/bitrate accuracy.


What is the applicability of this feature then, in real life situations, can you quote some examples. Just trying to understand for what can I use CQ.


this doesnt mean you can not use it for such just that you should be aware of its limitations when doing so.

Yes, I am aware of the limitations, but was hoping that they might either go away or diminish with newer versions of HC.

Although its a great product, no doubt.

[dragongodz]

dragongodz and I mail a lot to discuss all kind of MPEG related stuff.
and some facinating discussions have been had. ;)

What is the applicability of this feature then, in real life situations, can you quote some examples.
fast archival purposes would be a good example. also there are business related possabilities, such as licensed footage being transfered to be re-encoded by the licensee, in such a case they would want high quality while not ridiculously big as a raw copy would be. so a constant quant encode at a low quant could provide such and be relativly fast to do.

was hoping that they might either go away or diminish with newer versions of HC.
the unpreictable file size is inherent in the method and not the program. there is no way to remove the limitations and still have it be constant quant. hank315 already made 1 change, possible to limit max bitrate/vbv, which already has changed it to no longer being fully constant. to set it to hit a specific target size ot bitrate would require much more and turn it in to more of a 1 pass vbr mode. if you start going that route then its best to do it fully and not just mess with constant quant to try and get it.

[LigH]

use that ping pong technique
You probably mean the Bisection method (http://en.wikipedia.org/wiki/Bisection_method) from the numerical analysis?

[Darksoul71]

Hi all,

I´m currently "developing" a size prediction frontend for HC Enc based on the same approach that the
most size-prediction tools for CCE or TMPEGEnc use. I do a "Q-based" encoding for a 2% sample
of the movie using AVISynth. Based on the estimated size for the encoded sample, I vary the Q-value
unless the estimated size is within a +/- 10% of the target size.

The Q-value for the next pass can be calculated on various algorithms:
* The simplest but not the fastest algorithm is bi-section
* Another approach is described by Amnon82
* A simplified version which can be used instead of Newton-Raphson (-> D2SRoBa) is this formula:
Q(n+1) = Q(n) * (Estimated_Size / Target_Size)

My manual tries (calculating the new Q-Value by using a pocket calculator) unfortunately confirmed what Hank already pointed out in his last PM: HC Enc has the tendency to be not very predictable for analogue captures. Pre-quantized material (e.g. DVB-T broadcast, Hardware MPEG2 encoded material, DVD) seems to be less vulnerable and provide a better prediction precision but my MJPEG captures (480x576 filtered and resized to 352x576 via AVISynth) were up to 40% oversized as well as 20% undersized.

To quote Hank:
A while ago I did an implementation for OPV, it did pretty well but it only worked OK for DVD backup's, for plain AVI input it was just bad.

Based on this and my personal
I would like to comment a few things dragongodz posted above:

the unpreictable file size is inherent in the method and not the program.

I would disagree on this one:
The final file size might not be exactly predictable there is a valid approach (using a 1-5% sample of a movie) to get a pretty good aproximation (mostly +/- 5% for CCE which I use currently). D2SRoBa (in combination with DVD2SVCD) has proven that the concept works very well at least for CCE. The variety of tools out there for TMPEGEnc show that the concept works also for other encoders. So IMHO the unpredictable size (for analogue captures) in contrary is inherent to the program (= HC Enc).

As my time is currently quite limited I can not do further experiments but there might be simple aproaches to "stabilize" the prediction for analogue material, e.g. limiting the upper CQ bitrate to 6 MBit, using good denoisers, etc.

All this worked quite fine during my low-bitrate encoding experiments with CCE.

Unfortunately I don´t know enough about how MPEG2 encoder(s) work internally. Thus I can and will not comment weather "CQ" encoding or 1 pass VBR mode would do the job better. All I can say is that two other MPEG2 encoders have "VBR"-modes (be it either named Q-Value or Quality) and both are able to hit the targeted size even with analogue material (-> lot´s of noise) whereas one encoder fails.

For me a "OPV"-frontend for HC Enc is a "no no" as long as the encoder has this "problem" with analogue material.
From a time perspective I guess even an implementation based on bi-section with something like 10 estimation runs max mean 90% time saving compared to a two pass mode. Judge yourself wether this is worth the implementation effort.

Just my two cents,
D$

[dragongodz]

I would disagree on this one:
hmm thats interesting considering your own words say a completely different thing. to quote
The final file size might not be exactly predictable
to get a pretty good aproximation (mostly +/- 5% for CCE which I use currently)
hmm looks to me like you are agreeing you can not predict the exact size.

an important point is
All this worked quite fine during my low-bitrate encoding experiments with CCE.
its nice that this has all been expeirimented on with CCE for so long and the best methods for getting close with CCE have been found. however to criticise another encoder because it doesnt work the same way as CCE is ridiculous.

also about this quote
A while ago I did an implementation for OPV, it did pretty well but it only worked OK for DVD backup's, for plain AVI input it was just bad.
sorry but you have no idea what hank315 was talking about with that. i do because i saw and tested it. it was a near real 1 pass VBR(near because of methodology to determine other facters etc i wont go in to here) and didnt need any size prediction by anything else, you set a target average bitrate. the problems hank315 was talking about are not related to CQ encoding and shouldnt try and be used as any proof of what you consider a problem with HC, because it isnt.

[Darksoul71]

No need to nitpick my posting to death !

I am not starting a flame war here (e.g. my encoder is "bigger than yours").

Everything posted by me is based on the observations I made.

Saying "not exactly predictable" versus your "the unpreictable file size", sounds quite different to me.

Getting a 95% - 105% of my final target size is pretty good to me if it only takes half the time and gives
me better quality compared to CBR encoding. Not matter which encoder is used.


hmm looks to me like you are agreeing you can not predict the exact size.

Good estimation <> exact size (but still "good enough")


its nice that this has all been expeirimented on with CCE for so long and the best methods for getting close with CCE have been found. however to criticise another encoder because it doesnt work the same way as CCE is ridiculous.

Claiming I am criticising HC is indeed ridiculous. The two examples I named (better filtering & limiting the upper bitrate) are not bound to any specific encoder:
1) Filtered / denoised / smoothed material puts less stress to any encoder (be it DivX, HC Enc, CCE or whatever) which results in "less risk to get macroblocks during complex scenes". The same goes for "pre-compressed" material which provides less details for the encoder to compress (-> DVD backup, DVB broadcast).

2) Limiting the upper bitrate limit (e.g. to 6 MBit) leaves the encoder less space to "waste" bitrate. No matter what encoder you use.

All in all it where just examples and I would be happy to proof them right by doing further testing (for which I don´t have time). As pointed out I don´t know the difference between a constant quantizer (HC Enc ?), a Q-Value (CCE) and quality-based encoding (TMPEG Enc) method is. All I know is the following:
Varying the corresponding Value "X" (be it named Q, Quality, whatever) as described above leads to successful results when using TMPEG Enc (try TOK or CQ Tester by Borad) and CCE (D2SRoBa / my implementation with Komprezz2MPEG). When I say successful results this translates to "the encoder was runing using value X and the final filesize was within the estimated range". It does not mean encoder "a" is better compared to encoder "b".

May be I should have written it that way:
TMPEG Enc and CCE have a less fluctuating bitrate graph when using "Q-based" encoding compared to HC Enc...

Better ?


sorry but you have no idea what hank315 was talking about with that. i do because i saw and tested it. it was a near real 1 pass VBR(near because of methodology to determine other facters etc i wont go in to here) and didnt need any size prediction by anything else, you set a target average bitrate. the problems hank315 was talking about are not related to CQ encoding and shouldnt try and be used as any proof of what you consider a problem with HC, because it isnt.

This posting was directly an answer of hank315 to me when I asked him why he didn´t implement OPV encoding in first place. If hank was talking about some sort of VBR encoding where you specify the ABR, well then sorry....but to me OPV refers to the approach used by D2SRoBa and all the other tools out there.

Nevertheless it covers the same experiences I had playing around with HC Enc and "OPV".....

Later,
D$

[dragongodz]

No need to nitpick my posting to death !
hmmm
Saying "not exactly predictable" versus your "the unpreictable file size", sounds quite different to me.
funny that sounds exactly like nitpicking to me as both statements mean basically the same thing in the end.
you cant expect to say you disagree with me and then not have me say where you contradict yourself.

Claiming I am criticising HC is indeed ridiculous.
your words
So IMHO the unpredictable size (for analogue captures) in contrary is inherent to the program (= HC Enc).
and you say this because you dont get the same results as you do using CCE or Tmpgenc, neither of which do CQ but other methods.

I asked him why he didn´t implement OPV encoding in first place. If hank was talking about some sort of VBR encoding where you specify the ABR, well then sorry....but to me OPV refers to the approach used by D2SRoBa and all the other tools out there.
go back to page 31 of this thread and read boulders and mine posts. real One Pass Variable is not CQ or some sort of quality setting(though this is closer) etc. it is what it says it is. the fact that CCE uses the term OPV has done more damage in some ways i think for people understanding what these terms really are meant to mean. CCE appears to do a type of OPV in that it does vary the quants etc but for whatever reason they chose not to have targeting average bitrate. so people seem to think that OPV means you MUST use these predictions to estimate the size because there is no other way. thats simply false.

I am not starting a flame war here (e.g. my encoder is "bigger than yours").
hmm did i say you were ? did i call you names ? did i say you were full of it ? no. i disagreed with what you said and explained why. so please dont get upset because you dont like the blunt way i say things.
oh and of course HC isnt "my encoder" at all. incase you missed it i actually work on a different encoder. :)

[techmule]

@darksoul,

I guess you should discuss this in detail with Hank or better wait for his comments on your post above, since he is the developer of HCEnc and can guide you better on your concerns.

After that its your decision (since its your time) whether to develop this tool for CQ value prediction or not.

IMO, it does save a considerable amount of time using (CQ vs 2-pass) and would help the the users of HCenc, moreso since apart from GetCQ, I dont think many tools are present to do the CQ prediction for HCenc.

And if you can come out with a better and more accurate prediction tool, it would be good effort spent.

Just my 10 cents.

[Darksoul71]

@techmule:
Agreed, I´m just a bit disappointed that my "manual" experiments with analogue material turned out to be a bit unprecise in terms of prediction.

@dragongodz:
Nothing more to add....

[techmule]

@techmule:
Agreed, I´m just a bit disappointed that my "manual" experiments with analogue material turned out to be a bit unprecise in terms of prediction.


But on the brighter side of it, atleast it gave you some perspective about the other sources (DVD etc). Without your "manual" experiments, it couldnt have been possible.

Even if you decide not to pursue this project, it will be a lead for others.

Well done !!! :)

[Darksoul71]

@techmule:
Well, I don´t know how well reproducible my experiments are. My analogue cable signal is quite stable and my Cinergy 400 captures nice quality. Someone else with a BT 8X8 based card and noisy signal might get different results ?!?

[hank315]

A while ago I also tried to implement OPV based on Constant Quantization, well not completely constant, it could vary a bit.
This sounds a lot like the method used by Darksoul and I couldn't get it to work properly either...
With properly I mean the prediction size was sometimes *very* wrong even if 5 - 10 % samples were taken.

Method used:
- start with first estimate: Q=8
- second estimate: Q(n+1) = Q(n) * (Estimated_Size / Target_Size)
- next estimate(s): secant or Ridders' method, converges faster than bisection if close to the root

Normally this converges in 3-4 steps.

The final file size might not be exactly predictable there is a valid approach (using a 1-5% sample of a movie) to get a pretty good aproximation (mostly +/- 5% for CCE which I use currently). D2SRoBa (in combination with DVD2SVCD) has proven that the concept works very well at least for CCE. The variety of tools out there for TMPEGEnc show that the concept works also for other encoders. So IMHO the unpredictable size (for analogue captures) in contrary is inherent to the program (= HC Enc).
I just can't see why HCenc does something really different than CCE or TMPEG.
If I look at bitrate curves and Q-curves in BRV produced by CCE or HCenc it shows they are almost identical.
CCE bitrate curves tend to be a bit more flat than HCenc curves.

Because it seems you need 10% or more sample size with 3-4 steps to converge the time gain was just too small so I skipped the whole thing (for now).

As pointed out I don´t know the difference between a constant quantizer (HC Enc ?), a Q-Value (CCE) and quality-based encoding (TMPEG Enc) method is.
I don't know the difference either :)
A Constant Quantizer as used by HCenc is decribed in the ISO document, Q-value and quality-based are "invented" by CCE and TMPEG, I think there's nobody who really knows how it works.

[Amnon82]

My self I didn't tried your latest version. I think, I should play a little with Darksouls simplified formula. Also I'll add it to AutoQ2 to see if it work with CCE.

[Darksoul71]

Hi hank,

thanks for taking the time to reply. Hopefully my postings didn´t sound like an offence against HC Enc.

Your observations are indeed interesting. Since my time to experiment was quite limited I didn´t play
around too much with sample size and I guess 5% were my maximum. For CCE even 0.5-2% are "good enough".

The simplified formula you´ve also used to calculate the second Q-value normally converges after 3-4 steps for CCE.
At least that´s my observation using CCE 2.5 SP for my analogue captures.

Here is a little more background on my experiments....

My source material was:
* DVB-T broadcast (-> MPEG2 already compressed with a very low bitrate)
* PIC MJPEG AVI captured in PAL SVCD Res from analogue cable using my Terratec Cinergy 400
* MPEG2 files captured in PAL D1 Res from analogue cable using my Haupauge WinTV PVR USB2

I´ve choosen not to use DVD material since it was already pointed out that HCenc is pretty much able to hit

The results were, errr, "mixed":
DVB-T broadcasts had the tendency to converge towards Q=1 since they were already highly compressed (~ 2.5 MBit/s mostly). For those with Q-Values above 1 the resulting files were mostly a bit undersized. The MPEG2 captures had mostly ~ 9MBit/s and the resulting encodings met the target size very well (~ 5-10%).
The MJPEG AVI´s showed the biggest deviations in terms of size. I encoded 8 movies and 5 of them met the target size quite ok ( max 15%) whereas 3 of them did go wild (up to 40% oversize and 60% undersize).

My conclusion:
I wasn´t suprised to see the biggest deviation on the source material with the highest details and I wouldn´t be suprised if HCenc shows even higher variantions when using Huffyuv captures or DV material captured with my Canopus ADVC100 as it provides even more details (also noise) compared to my Cinergy 400.

I just can't see why HCenc does something really different than CCE or TMPEG.
If I look at bitrate curves and Q-curves in BRV produced by CCE or HCenc it shows they are almost identical.
CCE bitrate curves tend to be a bit more flat than HCenc curves.
Hmmmm, this is really strange. May be the rate control (is this the right word ?) of CCE is a bit slower / less dynamic compared to HCenc ?
May be you could play a little bit with the rate control and add a little more "damping" to it (yes, I know. That´s the wrong term :D)

I can only guess.....

At least HCenc behaves different compared to CCE and TMPEG Enc since one is able to get a valid size estimation by using 2-5% of the movie, wouldn´t you agree ?

I have never seen deviations higher than 10% for the last 80 movies I encoded from my analogue captures over the last month. Mostly I don´t care about a few percent oversize since I normally do not fill the DVD to the max and are not afraid to run the finally mastered DVD (normally with 2 movies) through DVD Shrink or DVD-RB if it is oversized.

Because it seems you need 10% or more sample size with 3-4 steps to converge the time gain was just too small so I skipped the whole thing (for now).
Hm, this depends on. Even if it would take a 10% sample with 5 steps to converge you would still have a speed gain of 25% compared to 2 pass encoding.
At least I would be happy to get such a speed gain. Example: You would be able to encode 5 movies in "OPV" mode in the same time as 4 movies would take


A Constant Quantizer as used by HCenc is decribed in the ISO document, Q-value and quality-based are "invented" by CCE and TMPEG, I think there's nobody who really knows how it works.
So they are mainly marketing gags I guess ;)

@Amnon:
My self I didn't tried your latest version. I think, I should play a little with Darksouls simplified formula. Also I'll add it to AutoQ2 to see if it work with CCE
The formula is not "mine". I can´t remember exactly who provided it but IIRC it was tylo somewhere over in the DVD-RB forum when they talked about OPV support in DVD-RB. You´ll also find a modified version for CCE of this using a multiplicator ("f") with a start value of 1.35 and re-calculate f during the aproximation process. I used this formula also for FitDVD (I gave you the sources, didn´t I ?). Nevertheless the "f" factor stuff is pretty much CCE specific.

The prediction algorithm itself has no impact on the size problem. It just converges faster or slower.

I think I´ll concentrate on my "multi CPU" frontend for HCenc and come back to size prediction once I have new ideas...

Later,
D$

[Amnon82]

Everybody knows DVDShrink. When you open a VOB-file it anaylses it first. Why not adding such a feature to HCEnc. Now we know the compression rates of the source and we can tweak the CQ-value a little bit. I'm thinking of a factor. Where you can compress more you higher the CQ-Value, otherwise you lower it using the factor.

Exp.: Our CQ-Value is 8, our factor is 1.08, so in more compressable scenes we are using 8.64 and in less compressable scenes 7.40

I think this might be the "magic" behind CCE and TMPGEnc.

[Darksoul71]

Hm, the compression rates / complexity of our source is something we do not know. In order to find them out, the encoder has to analyze the complete video stream (which is done in the first pass of two-pass mode). Depending on the filters used on source (De-Interlacer, Denoise, Resize, etc) the video decoding & filtering will mostly be below real-time. This leads to two options:
1) Doing a complexity analyse based on destributed short samples (e.g. SelectRangeEvery)
or
2) Doing a 100% analyse of the movie (a.k.a. 2 pass mode :D)

Using samples for a movie is more or less representative depending on sample size and the variation of the "action level" / complexity of the movie. For CCE and TMPEG normally a maximum of 5% is "enough". HC Enc might need 10 to 20%.

I can only guess but I wouldn´t be suprised if the size aproximation is proportional to the sample size, e.g. you hit the target size more precisely using a 20% sample of the movie instead of using only 2%. When using 100% sample (= full movie) you will of course get perfect size but running 8 * 100% of a movie to get the right CQ value is not really a time saving compare to 2-pass mode (2* 100 % encoding :D).

I think it would need intensive testing with a critical source (something that showed 40% oversize), the usage of a bitrate viewer and playing around a lot with filters, upper bitrate limit, etc. to nail down the hot spot which is actually causing the deviation. As posted above I think the "rate control" of HCenc might be a good starting point as well as comparing the bitrate curve for a critical source encoded via CCE with OPV and HCenc with CQ.

[Amnon82]

There are two differnce of the 100% analyse DVDShrink does. There is the fast one which only scans the bitrate or stuff like that and the DeepSearch analyse which can be taken as the first pass of an 2pass encode.

RateControl might be the problem, but adding a tweak factor for the CQ-value might also help using the fast analyse as base.

[Darksoul71]

Short note:
I´ve just thought about it. Rate Control might not be the right word. If HCenc encodes at a constant quantizer the encoder "doesn´t care about the bits spend" (I don´t know to explain this better with my own words). So basically one approach that might help to "stabilize" HC enc in terms of the oversized files could be a "bitrate control", e.g. HCenc monitors the bitrate delta over a certain frame range and limits the "amount of bits spend" to a fixed value (Delta Bitrate Max = 3000 kBit / 300 Frames) -> modifying the quantizer value as suggested by Amnon ?

But I guess this would be more of the approach a one pass VBR with fixed average bitrate would work.

BTW: If I haven´t said this before: Thank you hank for this great free encoder :)

[techmule]

There are two differnce of the 100% analyse DVDShrink does. There is the fast one which only scans the bitrate or stuff like that and the DeepSearch analyse which can be taken as the first pass of an 2pass encode.


Thats what I was thinking, how does Deep analysis gives Shrink all the info it need to compress and reach a target size ???

Deep analysis gives you your desired target size without fail, anytime and all the time!!!! and does not take more than 10-15 min for a normal 2 hrs DVD.(depends on PC conf also)

[techmule]

Everybody knows DVDShrink. When you open a VOB-file it anaylses it first. Why not adding such a feature to HCEnc. Now we know the compression rates of the source and we can tweak the CQ-value a little bit. I'm thinking of a factor. Where you can compress more you higher the CQ-Value, otherwise you lower it using the factor.

Exp.: Our CQ-Value is 8, our factor is 1.08, so in more compressable scenes we are using 8.64 and in less compressable scenes 7.40


Good thinking Amnon, and different values can be applied to the different segments of the video too, based on the analysis.

[dragongodz]

But I guess this would be more of the approach a one pass VBR with fixed average bitrate would work.
yes.

DeepSearch analyse which can be taken as the first pass of an 2pass encode.
sorry but no it can not. compressed domain transcoders do not work the same as full encoders. yes some of the information such as original curve etc could be obtained and used from a similar analysis and hank315 already looked at that. to say it could be taken or used as a real first pass though is wrong. there is information that has to come from the encoder encoding frames which isnt got from analysing the source in such a way. if you tried to just use information from such an analysis you would get suboptimal results because the encoder would be having to adjust itself for inaccuracies and information it doesnt get until the second pass all the time.

Deep analysis gives you your desired target size without fail, anytime and all the time!!!! and does not take more than 10-15 min for a normal 2 hrs DVD.
dvdshrinks deep analysis is actually just seeing which frames have more coefficients etc so it can remove more from frames that have them instead of having to play catchup with later frames that may be hit harder doing so. the reason its fast is because nothing is being decompressed, simply analysed.

[manolito]

Just a few thoughts:

According to the CCE manual CCE's so called OPV method really is a Constant Quant method with the exception that max bitrate and min bitrate will be observed. The quantizer is only changed when the actual bitrate goes over the specified max bitrate or under the specified min bitrate.

So CEE's OPV method should indeed be very similar to HC's CQ_Maxbitrate method (with the exception that with HC you cannot set the min bitrate).

From all the stuff I learned from D2SRoBa it is necessary to introduce a "correction factor" to the prediction. The sample passes will have tons of scene changes which will lead to heavy undersizing without correction. It also makes sense to turn off scene change detection for the analyzing passes. D2SRoBa calles this "estimation accuracy tweak". I remember that this idea originally came from forum member "jonny".

I also remember hot discussions in the D2SRoBa thread whether a larger sample size really leads to a more accurate prediction. Experience tells me that it does, but this was heavily disputed by r6d2 (and this guy knows a lot more about math than I ever will...).

Anyways, with a 2% sample size D2SRoBa always gets within +/- 3% of the target size. And if the encode is just a few percentage points oversized, I found that using a transcoder does not visibly hurt quality. It would be really nice if the same accuracy could be achieved for HC.


Cheers
manolito

[jdobbs]

There are definitely a few differences between CCE/OPV and true constant quant... if you analyze the output you'll see that the quantizer values for I, P, and B frames vary considerably from frame to frame. In constant quant they would have to always be the same. Hank315 has given the ability to adjust the quantizer values on P and B frame frames using a constant modifier, but in CCE there is some other decision mechanism at work for distribution of quantizer values in OPV... and I, for one, don't know what it is.

[Amnon82]

Maybe a mix of my thougths and ABR will do the magic for HCEnc. Maybe a fast analysis will help for DVD-Sources, but what is if the source is an uncompressed avi-source? What do you guys think the fast analysis should analyse?

[dragongodz]

Maybe a fast analysis will help for DVD-Sources, but what is if the source is an uncompressed avi-source? What do you guys think the fast analysis should analyse?
well i am not going to paste all the conversations hank315 and i have had by email but let me just say we have already discussed all this some time ago. so hank315 already has a good idea of a way to do these things.

i mean go ahead and discuss it if you want, maybe you will even come up with something we didnt. just dont be surprised if we are not amazed or something while you are going over old ground for us. ;)

[Amnon82]

... maybe we will find a lost part :D by doing this ...

[techmule]

so hank315 already has a good idea of a way to do these things.


so hank what are the next steps you intend to take, going forward, in this context.

Are you planning to integrate CQ determination in HCenc next releases, if not, whats stopping you ???

and if not, why not share these ideas with authors of other tools like Amnon, darksoul and JDobbs, so that they can implement/improve on their CQ prediction methods with HCenc!!!.

[dragongodz]

Are you planning to integrate CQ determination in HCenc next releases, if not, whats stopping you ???
to quote hank315
A while ago I also tried to implement OPV based on Constant Quantization, well not completely constant, it could vary a bit.
This sounds a lot like the method used by Darksoul and I couldn't get it to work properly either...
so no a predictable by HC OPV mode based on CQ is not on the cards.

and if not, why not share these ideas with authors of other tools like Amnon, darksoul and JDobbs, so that they can implement/improve on their CQ prediction methods with HCenc!!!.
because they already know the different formulas etc.

so let me make this clear for everybody. hank315 and i have looked at and talked about an OPV where you can set target bitrate. the quants will vary etc as needed to hit the target and give extra where eeded etc. it does a short analysis to get some informaion about the source to base the full pass on. early tests however show it needs much more work because quality was not real great and tended to slightly undersize.
so hank315 has put this on hold for now because its something that will take more time than he currently has to make it worthwhile. so please do not ask for this, it will be done one day but at the moment. until then if you really want exact size prediction then use 2 pass, end of story.

[techmule]

so let me make this clear for everybody. hank315 and i have looked at and talked about an OPV where you can set target bitrate. the quants will vary etc as needed to hit the target and give extra where eeded etc. it does a short analysis to get some informaion about the source to base the full pass on. early tests however show it needs much more work because quality was not real great and tended to slightly undersize.
so hank315 has put this on hold for now because its something that will take more time than he currently has to make it worthwhile. so please do not ask for this, it will be done one day but at the moment. until then if you really want exact size prediction then use 2 pass, end of story.

Clear enough.

Why didnt you say so earlier!!!, we cant read your minds (or were you expecting us to do so :D )

[dragongodz]

Why didnt you say so earlier!!!, we cant read your minds (or were you expecting us to do so :D )
its not my job to list or talk about things hank315 has been or is working on. for example i know whats changed in HC 0.18 but i am not about to say what things they are here incase hank315 decides 1 or more is not ready and removes it. i think people should understand that.
these last few pages have also touched on several tangents and my responses have been to different things. however if you read all of what both hank315 and i have written the general idea of what i said is there. so no i dont expect people to be mind readers but they should expect me to give out information which should not be needed either.

[techmule]

its not my job to list or talk about things hank315 has been or is working on.

Thats funny cos thats what you have done here(and i am not saying thats its a bad thing to do) and you are definitely giving an impression that you are hanks messenger.:sly:

[dragongodz]

Thats funny cos thats what you have done here(and i am not saying thats its a bad thing to do)
i have only given as much information as needed for the relevant topic so as to try and dispel some assumptions and/or assertions. i could easily have gone in to much greater detail about everything. so yes i have mentiones a little of things hank315 has worked on but not really that much.

you are definitely giving an impression that you are hanks messenger. :sly:
not at all. with the extra knowledge i have about how HC works and what has been experimented with or worked on,especially from talks with hank315, i have chosen to try and help people in this thread. whether that means dispeling what or how they think HC does something ,or letting them know something has already been experimented with so they do not have to use a lot of their own time if they do not wish to. hank315 has had no say in it and certainly not encouraged or discouraged me from doing it.
if however people would rather i say nothing and let them discuss whatever making their own assumptions well i can do that just as easily. it really doesnt worry me either way.

[asia_minor]

if anyone sees the same thing I do...

Don't get me wrong, HC is a great encoder (and the price is pretty cool too :P), so thanks again hank315 for your hard work with this nice software.

So.. I had an idea to get better conversion quality out of my source XviD avi (350MB HDTV episode) and proceeded with a sample clip of it. Aside from my idea failing, I noticed for 1st time that the colours became a little darker (green became darker green, for example). Anyone else see something similar? I was intending on maintaining the quality of the source, since the resize wasn't very much and the original bitrate was roughly half the DVD bitrate.
Settings were ~2100 kbps (DVD bitrate), 16:9, HVSBest matrix (tried the other HVSs and AVAMATx matrices too, then again, I'm open to suggestions).

Could anyone point something out (is there a way to maintain colours with the higher bitrate)? And apologies if this is the wrong place to put this post.

Again, thanks hank315 for the very nice software :)


Now back to the current conversation at hand...


EDIT:
Just came across ColorMatrix. Might that do something?

EDIT2:
Bingo... ColorMatrix works like a charm. Have no idea what exactly is going on with those funky coefficients as parameters, and adapted an example from CCE, and it just works :) Now to get rid of those compression block artifacts....
OK... darn, looks like I need a higher bitrate to do what I want to do.

[Mug Funky]

xvid uses mpeg-1 coefficients... mpeg-2 uses (you guessed it) mpeg-2 coefficients :)

colormatrix was designed to fix this, so your search yielded good results :)

btw, try configure xvid, go to "decoder options" and turn on deblocking and deringing. you'll lose a bit of sharpness, but that's not a show stopper on an HD source... this should take care of the blocks in your source.

[asia_minor]

Thanks for reply. Apparently, from what I can tell by comparison, deblocking and deringing doesn't seem to do much (Enabled in XviD decoder, using another AVISynth script to do everything else in HC).
And now the settings are 3000 kbps, 16:9, "Ultimate" matrix. These seem to do the job pretty nicely.

[Boow]

I just tried the hc encoder out using avi2dvd but the last two encode have been blocky. the source are pretty good quality. So is there any way to get rid of the blocks. a list of settings for a good encode.

[Mug Funky]

@ Boow: show us yours and we'll show you ours :)

so long as your bitrate is over 3500 kbps or so, there shouldn't be any obvious blocking. you can probably go even lower.

[Boow]

Well I just viewed the source for one of my avi's at full screen and found out it was blocky to begin with. So i guess I shouldn't of been in a hurry. I redid the other movie with Quenc and it came out a lot better. I will give hc another chance with some dvds of mine I want to backup and see how that goes.

[alvarez]

Hello,

First, I'd like to repeat what's probably been told at least 1000 times already: Thanks for this great encoder!

Now, to the point: I'd like to ask whether building in a new option specifying the location of the intermediate database file would be possible. Right now it's placed in the directory of where .exe is, but (for me at least) it would be more convenient if it could be stored in the same directory as other intermediate files.

With best regards,

:alvarez:

[Mr_Odwin]

Hello,

First, I'd like to repeat what's probably been told at least 1000 times already: Thanks for this great encoder!

Now, to the point: I'd like to ask whether building in a new option specifying the location of the intermediate database file would be possible. Right now it's placed in the directory of where .exe is, but (for me at least) it would be more convenient if it could be stored in the same directory as other intermediate files.

With best regards,

:alvarez:

I'd like to second this request. (I think I've requested it previously, but it was a short reply in a large thread, and was probably overlooked.)

[Piper]

Hello all,

I'm wondering if I've come across a bug in HCEnc v0.21 as my resulting encodes appear to be ignoring the 16:9 flag.

My source fed to HCEnc is 704x480 anamorphic NTSC -> PAL conversion (25fps). In HCEnc, I set the 16:9 setting, but I used a GOP of 18 (I'm not sure why I did this). The m2v when played back in zoom player or windows media player plays back at 4:3 which I later discovered after running the m2v file through DGPulldown and burning to DVD via DVDAuthorGUI and Nero 7 in Vista.

Any ideas on why or how the 16:9 flag is either being ignored or is not being written to the file? It's been a while since I've encoded a source like this, so perhaps I'm only missing some small step. I'll encode again with GOP 15, but I doubt GOP has anything to do with setting the AR flag.

Thanks

[45tripp]

You can check/change the DAR flag with restream.

If it's indeed a problem, can you recreate it?
And provide as much info as you can?

gl

[Ebobtron]

Hello all,

I'm wondering if I've come across a bug in HCEnc v0.21 as my resulting encodes appear to be ignoring the 16:9 flag.

Thanks

Check your log file or do a short clip with the log file this time.

[hank315]

I'd like to ask whether building in a new option specifying the location of the intermediate database file would be possible.This will be in the next release.

[alvarez]

This will be in the next release.

Thanks a lot!

:alvarez:

[Piper]

You can check/change the DAR flag with restream.

If it's indeed a problem, can you recreate it?
And provide as much info as you can?

gl

Thanks for the suggesting restream, I'd forgotten about this handy little app. Indeed, the AR in the .m2v file was set correctly and I discovered the cause only minutes after reading your post. The real issue was my son had played with the dvd player and messed around with its AR settings. What threw me however was that Zoom Player wasn't picking up the AR flag (regardless of AR setting). Media Player Classic dealt with it correctly however.

A non issue..sorry for the bother. Thanks.

[Mole]

Hello all,

I'm wondering if I've come across a bug in HCEnc v0.21 as my resulting encodes appear to be ignoring the 16:9 flag.

My source fed to HCEnc is 704x480 anamorphic NTSC -> PAL conversion (25fps). In HCEnc, I set the 16:9 setting, but I used a GOP of 18 (I'm not sure why I did this). The m2v when played back in zoom player or windows media player plays back at 4:3 which I later discovered after running the m2v file through DGPulldown and burning to DVD via DVDAuthorGUI and Nero 7 in Vista.

Any ideas on why or how the 16:9 flag is either being ignored or is not being written to the file? It's been a while since I've encoded a source like this, so perhaps I'm only missing some small step. I'll encode again with GOP 15, but I doubt GOP has anything to do with setting the AR flag.

Thanks

According to the DVD specs, 16:9 Anamorphic is only supported on full D1 resolutions (720x576/480)

This may be the reason why the the AR flag is ignored on your encodes.

[MysticE]

I have been playing around with HCenc and have found the results to be very nice. I usually use it to convert 25 f/s music videos to NTSC. My knowledge is limited, but I always see that pulldown should be used to get to 29.97 NTSC. It appears that HCenc's pulldown will only work with a 23.976 source, 25 f/s is ignored.

Am I missing something here?

[jdobbs]

Encode it at 25fps, then use Neuron2's DGPulldown against the output. Up until he wrote that code, I'm not sure anyone else had given much thought to converting that way. It also makes sure your audio stays in sync.

[Sagittaire]

I have been playing around with HCenc and have found the results to be very nice. I usually use it to convert 25 f/s music videos to NTSC. My knowledge is limited, but I always see that pulldown should be used to get to 29.97 NTSC. It appears that HCenc's pulldown will only work with a 23.976 source, 25 f/s is ignored.

Am I missing something here?

You must use pulldown with 23.976 fps source. Use pulldown with 23.976 progressive source (at playback only, progressive internaly) make 29.970 interlaced NTSC output.

[jdobbs]

If I understood correctly, I think in this case he's talking about converting PAL to NTSC by applying pulldown to a 25fps source. The TFF/RFF pattern would be different than if it were a 23.976fps source. That's why you'd have to use DGPulldown to do it instead of HC.

[MysticE]

If I understood correctly, I think in this case he's talking about converting PAL to NTSC by applying pulldown to a 25fps source. The TFF/RFF pattern would be different than if it were a 23.976fps source. That's why you'd have to use DGPulldown to do it instead of HC.
That's exactly what I meant. I have quite a few XviD music videos that I'm converting to 16:9 NTSC for play on my Plasma. All of them are 25fps. Using ChangeFPS(29.97) in my scripts is an easy fix and is fine for my vids, but I'm trying to understand the process a bit more and was confused as to why DGPulldown will convert 25fps but HCenc chooses not to.

Thanks

[vlada]

almost all movies are recorded at 24fps. In order to get them into NTSC standard, you need to convert them to 30fps (29,97 respectively). This is called 3:2 pulldown. You get a movie with the same length as original, but some fields are duplicated. The video looks like if it was interlaced.

To convert film material to PAL the video (including sound) is simply sped up to 25 fps.

So to get a "real NTSC" from 25fps, you need to slow it down to 24 fps (use AssumeFPS function in Avisynth) a then apply 3:2 pulldown in HC. You also need to slow down your music. But I'm not sure this is something you really want to do with music. You need to make a decision: worse video quality - choppy or blurred (your old method) or slowed down music (as described above).

As suggested, DGPulldown might be able to make a pulldown from 25 to 30 fps. But I never tried it because I live in a PAL country.

[jdobbs]

If you do it the first suggested way you will have material that virtually impossible to sync.

Of course on the other hand, you could just use DGPulldown on the source to convert it directly and have a perfect match.

[totya]

Hi,

In HC encoder GUI, I see:

dc precision 8-10
8:recommended for low bitrate
9:recommended for normal bitrate
10:recommended for high bitrate

Exactly how many kb/s these settings (8-10) ?
Example : 8bit 0-3500kb/s 9bit 3500-6000kb/s

Thank you.

[Boulder]

It's impossible to say that some value is high bitrate, some not. It depends on the source material - 3000kbps might be a lot for some while for some it's not.

[totya]

It's impossible to say that some value is high bitrate, some not. It depends on the source material - 3000kbps might be a lot for some while for some it's not.

Ok, thanks...

[gizzin]

Ya, 3000kb should just be a guideline to achieve good quality. There's lot of movies that would need more than, Saving Private Ryan is a good example probably needs something more like 4000kb

[totya]

Hi, i don't understand this; if source is captured avi from TV (720x576 YV12 PAL progressive, with lagarith lossless video codec) the result speed is "normal".
pass 1 (fps) 29.7
pass 2 (fps) 12.4

But, if this avi noise filtered, speed is worst (?!)
pass 1 (fps) 31,5
pass 2 (fps) 4,5

HC Profile:
profile: BEST
frames: 0 717
framerate: 25.000
aspect ratio: 4:3
bitrate Kb/s: 9200
max. bitrate Kb/s: 9500
pulldown: no
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 0
chapter frames: 0
time code: 0 0 0 0
CPU: SSSE3
matrix: MPEG
luminance gain: no

input avs is equally:
AviSource("_temp_.avs",true)

HC is latest version.

With CCE, total converting time:
unfiltered avi: 68 sec
filtered avi: 64 sec (!)

Thank you.

[Boulder]

I have a feeling that there is VBV buffer underflows going on, and the encoder needs to re-encode those GOPs where it occurs. You can doublecheck that by disabling VBV check in HC (just to doublecheck, don't do that when doing something you are going to use later on).

[totya]

I have a feeling that there is VBV buffer underflows going on, and the encoder needs to re-encode those GOPs where it occurs. You can doublecheck that by disabling VBV check in HC (just to doublecheck, don't do that when doing something you are going to use later on).

Your answer is perfect, thank you!
(Set VBV check is off)

If source is noiseless, and bitrate is very high, this is cause extremly slow working -> default setting is bad.

Suggest in HC application develpoment : if underflow is frquent, try VBV underflow checking is OFF. Example, in settings 2 tab, put new checkbox : vbv underflow check auto off

Thank you!

[Boulder]

If you don't check for VBV underflows, you will run into playback problems if they occur. There is a good reason for the VBV check to be there.

[totya]

If you don't check for VBV underflows, you will run into playback problems if they occur. There is a good reason for the VBV check to be there.

Then HC encoder extremly slow, if source video is noiseless, and bitrate is high... :(

[MrC]

Is there a command line argument for closing all GOPs? I have tried

-CLOSEDGOPS

but it does not work.

:confused::)

Bye
________
buy volcano vaporizer (http://vaporizers.net/volcano-vaporizer)

[Sir Didymus]

The parameter:
*CLOSEDGOPS
is fully supported by HC, but not as a c/l argument. You should place the line above in a suitable initialisation file (HC.ini).

This is fully described in the first pages of the encoder manual...

Cheers
SD

[MrC]

...but not as a c/l argument....

That was my fear... :rolleyes:

:)

Tnx
________
DR400 (http://www.cyclechaos.com/wiki/Suzuki_DR400)

[hank315]

I will add it as a c/l command in the next release.

[MrC]

I will add it as a c/l command in the next release.

:thanks:

Bye
________
YZ250F (http://www.cyclechaos.com/wiki/Yamaha_YZ250F)

[Boulder]

Post your script, also save and post the ini file for the HC encode.

[MrC]

@hank315

Is there the possibility to set HCenc priority level (I mean: idle, low, normal, etc.)? If not may you add this option to next release? As a c/l command too?

Thanks for your great job

:)

Bye
________
herbal store (http://herbalhealthshop.com)

[Boulder]

I think the actual encoder thread is running at idle priority already.

EDIT: yes, it's confirmed here: http://forum.doom9.org/showthread.php?p=992826#post992826

[FredThompson]

Interesting. Try running HC and QuickPAR at the same time. They do NOT play well together.

[MrC]

I think the actual encoder thread is running at idle priority already.

EDIT: yes, it's confirmed here: http://forum.doom9.org/showthread.php?p=992826#post992826

I do not know if single threads are running in idle, but my system (P4@2.4GHz) slows down a lot when HCenc is encoding. By changing (Task Manager) HCenc.exe priority to low, my system survives quite well....

:confused:

Bye
________
starcraft replays (http://screplays.com)

[hank315]

ATM the actual encoding threads are running at a low priority, the main program runs at normal priority.
I just implemented a priority setting in the next release (settings: idle, low, normal, high) which will set the priority for the main program and all threads.
Will be available as a c/l command too.

[Potlood]

I was reading posts about Bitrate Redistribution in the DVD-RB Forum. Would it be possible to include something like that in HCEnc? (plus providing option to choose sample-size and to run an extra encoding pass) Since there is already an OPV option which is used for Bitrate Redistribution calculations. And the new DVD-RB version will get an option to use HC for Bitrate Redistribution even if you want to use another encoder for the other passes. So why not just include it in HCEnc itself?

[DrP]

I've a problem encoding interlaced content with hc 021 where interlaced video can have very poor quality at scene changes.

If I do a two pass encode, the only way I've found to stop the problem is to turn off scene change detection. If I do a single pass constant quality encode, turning off scene change detection - or - turning of the VBV - or - allowing insanely high bitrates (say 15Mbit/sec) cures the problem.

hcenc's ini file contains:

*BITRATE 4000
*MAXBITRATE 6000
*FRAMES 0 32186
*PROFILE best
*AUTOGOP 15
*DC_PREC 8
*INTERLACED
*TFF
*MATRIX mpeg


Frame from CCE (http://img182.imageshack.us/img182/6608/ccero5.png) (min 0, max 6000, av 4000)
Frame from hcenc with VBV/scene change enabled (http://img180.imageshack.us/img180/9741/badvv4.png)
Frame from hcenc without VBV/scene change (http://img211.imageshack.us/img211/2270/goodmx9.png)

[jdobbs]

I was reading posts about Bitrate Redistribution in the DVD-RB Forum. Would it be possible to include something like that in HCEnc? (plus providing option to choose sample-size and to run an extra encoding pass) Since there is already an OPV option which is used for Bitrate Redistribution calculations. And the new DVD-RB version will get an option to use HC for Bitrate Redistribution even if you want to use another encoder for the other passes. So why not just include it in HCEnc itself?
That doesn't make a lot of sense... because HC concentrates on a single file that is being encoded. How do you distribute bitrate across different files when you are only encoding one?

That's a job for DVD-RB to do -- since it tracks all the segments that are involved in a DVD.

[Potlood]

That doesn't make a lot of sense... because HC concentrates on a single file that is being encoded. How do you distribute bitrate across different files when you are only encoding one?

That's a job for DVD-RB to do -- since it tracks all the segments that are involved in a DVD.

hmmm didnt think of that.. But what are those segments exactly? HC (at least HCgui) has options to import chapterlists, to create chapterlists based on scene changes and to manually create zones to change bitrates. Maybe it can also scan for segments?

[MrC]

ATM the actual encoding threads are running at a low priority, the main program runs at normal priority.
I just implemented a priority setting in the next release (settings: idle, low, normal, high) which will set the priority for the main program and all threads.
Will be available as a c/l command too.

:thanks:

Bye
________
CB900F (http://www.cyclechaos.com/wiki/Honda_CB900F)

[hank315]

@DrP
Yep, Boulder also reported problems with the scene change detection and I've seen it also in my own encodes, there will be some changes in the next release to solve it.

[Boulder]

hmmm didnt think of that.. But what are those segments exactly? HC (at least HCgui) has options to import chapterlists, to create chapterlists based on scene changes and to manually create zones to change bitrates. Maybe it can also scan for segments?There are no segments in a single video file. DVD-RB splits the video into segments depending on the cells (chapters?) on the DVD. You could say that one video file is one big segment.

[Potlood]

Ok I understand a litte better now. But if a program can split cells/chapters into segments, why wouldnt an encoder be capable of doing that? It already has chapter support...

I think it would be an advantage for HC to have native redistribution support (if possible). So output quality becomes more independent of what program people use (like it should be). Maybe it makes HC even more popular, because not everybody uses DVD-RB.

[jdobbs]

I don't think you understand the concept. If you brought the entire film into a single file -- then distribution of available bits based upon demand is inherent in the encoding process (in two+ pass VBR, at least). The reason redistribution exists is to enable doing something similar across multiple sources.

Previous to redistribution, the bitrate allocation across segments was based upon the distribution of the original encoding. That works fine for most sources -- but for CBR or poorly encoded VBR originals it might be less-than-optimal. Redistribution was a way to improve those encodes.

[peter100m]

@hank315: Is it possible to make the HC encoding window not show up at all and take focus? For example, if I have a batch list, every new encode start makes the HC window flash and take focus from other program windows. Even though I use the *SILENT parameter. Thanks so much for your efforts!

[cweb]

@DrP
Yep, Boulder also reported problems with the scene change detection and I've seen it also in my own encodes, there will be some changes in the next release to solve it.
Is the problem only with interlaced encodes?

[foustapfe]

Hi all. First of all thanks to hank for this great encoder and to the people in this community for the great tutorials and support stuff :thanks:

I encoded the movie "I'm a Cyborg, But That's OK" with HC 0.21 using best profile and the movie produced has visible artifacts in a few scenes. Those scenes have in common that they are a shot taken from far away in which there is not much movement, like a person walking in a field shot from far away. The nature of the artifacts is a very pixelated image every few frames. By very pixelated I mean that you are not able to tell what is in the picture.

I tried the same encoding with version 0.19 and it doesn't produce the nasty blocking, but you can tell that some frames has not the same quality as the rest of the scene, so I guess the same bug is present in some way.

I can provide the original clip and the encoded clip if it's not against the rules.

---

Edit: Screenshots showing three consecutive frames in one of the problematic sequences. The one in the middle shows the "bug".

http://img404.imageshack.us/img404/867/shot0048yp7.th.png (http://img404.imageshack.us/my.php?image=shot0048yp7.png)

http://img408.imageshack.us/img408/2600/shot0049za8.th.png (http://img408.imageshack.us/my.php?image=shot0049za8.png)

http://img165.imageshack.us/img165/1148/shot0050il3.th.png (http://img165.imageshack.us/my.php?image=shot0050il3.png)

[Squeeto]

Thankyou to Hank315 and the very helpful others on this thread.

I just upgraded my version of ffmpeg from a quite old:
ffmpeg version 0.4.8, Copyright (c) 2000-2003 Fabrice Bellard
to the newer:
FFmpeg version SVN-r7945, Copyright (c) 2000-2007 Fabrice Bellard, et al.

I don't know if this is a problem with my technique, hcenc or the newer version of ffmpeg.

The m2v file created by hcenc causes the older ffmpeg to report:
Input #0, mpegvideo, from 'd:\dv2dvd\testavis\boogie.m2v':
Duration: N/A, bitrate: N/A
Stream #0.0: Video: mpeg2video, 720x480, 29.97 fps
Must supply at least one output file

This is created from a camcorder DV avi source.

The newer ffmpeg has more to say about the same m2v:
FFmpeg version SVN-r7945, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --enable-mp3lame --enable-libogg --enable-vorbis --enable-faad
--enable-faac --enable-xvid --enable-x264 --enable-mingw32 --enable-a52 --enable
-dts --enable-pp --enable-amr_nb --enable-amr_wb --enable-swscaler --enable-avis
ynth --enable-gpl --enable-memalign-hack --cpu=i686 --extra-ldflags=-static
libavutil version: 49.3.0
libavcodec version: 51.32.0
libavformat version: 51.9.0
built on Feb 12 2007 12:01:35, gcc: 3.4.5 (mingw special)

Seems stream 0 codec frame rate differs from container frame rate: 29.97 (30000/
1001) -> 25.00 (25/1)
Input #0, mpegvideo, from 'd:\dv2dvd\testavis\boogie.m2v':
Duration: 00:00:26.5, start: 0.000000, bitrate: 9001 kb/s
Stream #0.0: Video: mpeg2video, yuv420p, 720x480, 9000 kb/s, 25.00 fps(r)
Must supply at least one output file


My hc.ini:
*infile D:\dv2dvd\testAvis\boogie.avs
*outfile D:\dv2dvd\testAvis\boogie.m2v
*bitrate 5000
*maxbitrate 9000
*matrix mpeg
*profile best
*aspect 4:3
*bias 0
*scanmethod zigzag
*dc_prec 10
*autogop 15
*preview

My boogie.avs:
LoadPlugin("TomsMoComp.dll")
AVISource("D:\dv2dvd\testAvis\boogie.avi")
ConvertToYV12()
TomsMoComp(0,15,1)

I need ffmpeg to do further work but it stalls here. Anyone know the fix?

Thanks again.

[Boulder]

The question that first comes to my mind is, what can ffmpeg do that HC cannot?

[Squeeto]

FFmpeg works my audio and extracts jpeg images for my menu screens.

[Boulder]

Why don't you use the original script for doing those things, it should work just fine.

[Squeeto]

Probably the best idea.
I just wondered if HCenc was not correctly setting flags (or whatever tells ffmpeg 25 or 29.97 fps).
Seems stream 0 codec frame rate differs from container frame rate: 29.97 (30000/
1001) -> 25.00 (25/1)

[gizzin]

I can't wait for a new version of HC.

[cweb]

I can't wait for a new version of HC.
Me too :)

Would like to thank Hank for the excellent program, by the way..
:thanks:

[45tripp]

I don't know if this is a problem with my technique, hcenc or the newer version of ffmpeg.
I don't see any problems.
At least you've pointed to none.

There's nothing wrong with HC output.

Probably the best idea.
I just wondered if HCenc was not correctly setting flags (or whatever tells ffmpeg 25 or 29.97 fps).
Simply seems to be the way ffmpeg treats/sees elementary mpeg2 streams.
No problem here.


I need ffmpeg to do further work but it stalls here. Anyone know the fix?

Stalls where?
When how?
Start a new post with specific details of a problem. Include commandline and it's output.

Why don't you use the original script for doing those things, it should work just fine.
"original script"?

gl

[Boulder]

The script that he feeds to HC - he could simply use the same script in ffmpeg (it does accept avs input, am I correct?)

[jdobbs]

I think it may depend on the version. Some of the releases come with an AVSDIRECT.DLL file. I included that with the version included with DVD-RB. My experience with FFMPEG and MPEG-2 seems to indicate that multiple passes "fail to converge" very often. Really low quants, too... even on low bitrates with high-bitrate matrices. I'm still trying to figure that one out (I see it on MENCODER too, causing undersizing quite often).

[hank315]

Is the problem only with interlaced encodes?
No, but it's more pronounced with interlaced encodes.
On some scenes the sensitivity for SCD is too high now which may cause very short GOPS.

every new encode start makes the HC window flash and take focus from other program windows.
I will change it so the HC window isn't created at all.

I can provide the original clip and the encoded clip
The 'buggy' image seems to have a very high quantizer, lots of blocks.
Best to upload a small sample of the original and encoded clip.

I just wondered if HCenc was not correctly setting flags
HCenc gets the framerate info from Avisynth as nominator/denominator.
If the result is within 0.5% of one of the valid MPEG2 framerates it's considered OK and the correct header is written, otherwise it will abort with an "invalid MPEG2 framerate" error message.
This code hasn't changed since the first release so I guess it should be foolproof by now.
So I don't have a clue what's going wrong in your case.

[45tripp]

The script that he feeds to HC - he could simply use the same script in ffmpeg (it does accept avs input, am I correct?)
yes.
been able for over a year and mencoder for over 2 years.

[Squeeto]

Stalls where?
When how?
Start a new post with specific details of a problem. Include commandline and it's output.


It seems with the newer version of ffmpeg, the 'singlejpeg' parameter has been dropped. 'mjpeg' is a suitable alternative (replacement?) parameter to extract images for my menu screens. I got it working.

It still complains about the codec frame rate differing from container frame rate but I trust that this is a ffmpeg issue. I have decided to just keep the older version of ffmpeg so that I don't have to see the error message.

Thanks again guys.

[Chabb]

I'm using HC021 and Avisynth 2.5.7

simple script:
colorbars(pixel_type="YV12")
trim(0,25)

this is original picture
http://forum.doom9.org/attachment.php?attachmentid=7546&stc=1&d=1188996848

and this is compressed one
http://forum.doom9.org/attachment.php?attachmentid=7547&stc=1&d=1188996853

can someone tell me what's wrong?

[foustapfe]

The 'buggy' image seems to have a very high quantizer, lots of blocks.
Best to upload a small sample of the original and encoded clip.

Here they are:

http://rapidshare.com/files/53562989/samples.rar.html

Rar file contains four clips: original from DVD9 and encodes with HC 0.21, HC 0.19 and CCE 2.7.

[Chabb]

It's not about quantizer or blocks.
I'we used default configuration.
Colours in second image are more than distinctly distorted.

[Chabb]

Ooops!
Last evening researches showed
that this problem appears to be
in internal MPEG-2 decoder of VirtualDubMod 1.5.10.1
Though it works well with mpeg-2 streams created by
other encoders (e.g. TMPEG 2.5)

[Boulder]

If you used ColorMatrix(mode="rec.601->rec.709") in the script, the colors would probably be closer to the original. This is a known "issue", see the ColorMatrix thread in the Avisynth usage forum.

[jjoshua2]

I'm having an issue with HC giving me outputs that are shorter and dropping frames. Details are here (http://forum.doom9.org/showthread.php?p=1044674#post1044674). Is there any tips on fixing this? How much higher quality is HC than Nero Vision's job of converting lossless huffy avi.

[fjhdavid]

Hello,

Thank you for this wonderful software!

does the next release will use the sse 4 instructions (the penrynn will arrive soon)?

thanks
Francois

[hank315]

does the next release will use the sse 4 instructions (the penrynn will arrive soon)?
No SSE4 instructions in the next release.
The MPSADBW instruction looks promising, it can do full search ME very fast but full search isn't used in HCenc.
IMHO SSE4 does have some nice instructions (DPPD is cool) but that's not useful for video encoding.

[Lorax2161]

This is a theoretical question I've been wrestling with in an attempt to quicken the speed of my encodes.

For the sake of argument, let's suppose HC Encoder can process unfiltered video on a given computer system from Avisynth at 30fps. Would it be correct to presume that Avisynth will be waiting for the encoder whether it feeds it at 100fps or 1000fps? If so, there is no sense leaving out an effective filter if there is no appreciable speed penalty. It could be that simple, or there could be much more at work here, which is why I pose the question.

@Hank315... phenomenal encoder, sir. A test DVD of a television crime drama looked as good as when I captured the show in the first place. Remarkable since the source was NTSC DV and it was compressed to about one third the captured size. The fast action of sports has proven a challenge, hence the experimentation with different filters in Avisynth.

Thank you.

[fjhdavid]

Dear Hank,

Does HC require the bt.709 color matrix for encoding?

thanks
francois

[Boulder]

HC assumes Rec.709 coefficients.

[pandy]

HC assumes Rec.709 coefficients.

Hm... by assumption 601 should be used in SD and 709 in HD

[Boulder]

The same behaviour is in QuEnc, mencoder and CCE..where did you actually get that information? I don't know if anybody has found an official specification anywhere.

[fjhdavid]

the problem is that during encoding, you don't know, if after, you will play the encoded DVD as it (SD resolution) or in a upscaled player (HD resolution)

but the encoder must know the color matrix during encoding, so is it bt.601 or bt.709 which is assumed for the HC encoder?

[kumi]

Like Boulder said, HC assumes Rec.709 coefficients. That's what you should feed it.

[tom942]

@Hank315

Just a quick question. Will the new version include something similar to AQM?

Regards and keep on with this great app :).

[pandy]

The same behaviour is in QuEnc, mencoder and CCE..where did you actually get that information? I don't know if anybody has found an official specification anywhere.

If Your question is for me i answer - Capabilities declaration form for HDMI certification http://www.hdmi.org/pdf/CDF1.1.pdf have such declaration:
Source_Alt_Colorimetry (description is: Will the product ever transmit video using a non-default (i.e. alternate) colorimetry under some condition? (e.g. using BT.709 for 480p or BT.601 for 1080i)). So this mean that industry by default use 601 for SD and 709 for HD.

[dragongodz]

by assumption 601 should be used in SD and 709 in HD

by real world example dvds can be 709. i just ran 3 dvds(a disney cartoon, steamboy, logans run) through dgindex to see what they were. all were 709.

i have seen others mention they have come across dvds that use 601 aswell so no i am not saying all dvds are encoded 709.

however the assumption that they all should be falls flat when you bother to look at the reality.

the example you are giving is for hd output and appears to be ignoring the dvd media produced for years. so if it is going to have trouble with content produced by these encoders its going to have the same problem with a lot of the commercial dvds people have bought, and continue to buy, aswell.

i will add this link aswell though i do not know how accurate it is
http://www.afterdawn.com/guides/archive/digital_video_fundamentals_-_color_formats_page_3.cfm

and from that
For the most part, the only two standards you need to know about are Rec. 601 (aka ITU.601, BT.601, or SMPTE 170M) and Rec. 709 (aka ITU.709 or BT.709). Rec. 601 is used for MPEG-1, MPEG-4 ASP (DiVX, XViD, and the like), and DV. MPEG-2 may use Rec. 601, Rec. 709, or SMPTE 240M (almost the same as Rec. 709). HDTV and DVD video are always supposed to use Rec. 709. Just as with nearly everything related to digital video this isn't always as simple as it should be. Some HDTV signals and DVDs are encoded with Rec. 601, and sometimes the colorimetry even changes in the middle of a video stream. In the case of MPEG-2, although the colorimetry used is stored in the file (since it supports multiple standards) sometimes it's missing so Rec. 709 is assumed.

[dragongodz]

Will the new version include something similar to AQM?


version 0.18 included the ability to change/use multiple matrices. RTFM and see if that is what you are after.

[Boulder]

Funny thing is, 99% of the Rec.601 stuff I've seen have been sloppy NTSC to PAL transfers - i.e. butchered quality with fieldblending and a very soft video. Maybe it's the hardware encoder they use, I don't know..I've just not seen much of Rec.601 in good transfers. I assume the industry mostly uses Cinema Craft's products but I may be wrong there.

[pandy]

by real world example dvds can be 709. i just ran 3 dvds(a disney cartoon, steamboy, logans run) through dgindex to see what they were. all were 709.

Probably using particular color space depend from source ie if SD is taken from HD (film tape is converted to the HD and for SD or HD is converted to the SD) then 709 will be prefered color space, if source is taken from analog SD video camera there is high probability that they use a 601.

Im not sure that we should follow industry assumption that 709 is prefered for HD source and for SD 601 is prefered. But from uknown reson industry in HDMI certification process take assumption that 709 is for HD and 601 is for SD and request clear declaration from HDMI source manufacturers that they use or not alternate color space.

[dragongodz]

Probably using particular color space depend from source ie if SD is taken from HD (film tape is converted to the HD and for SD or HD is converted to the SD) then 709 will be prefered color space, if source is taken from analog SD video camera there is high probability that they use a 601.

the problem then is its still dealing with possibilities so can never be sure.

But from uknown reson industry in HDMI certification process take assumption that 709 is for HD and 601 is for SD and request clear declaration from HDMI source manufacturers that they use or not alternate color space.

which frankly is rather stupid to me. its ignoring the precedence of current SD sources such as dvd. so if output to hd is going to be assumed those irrelevant of the real source that would be the dumbest thing ever. unless they want dvds to purposely look worse, now that is a possibility.
the only way those restrictions could make any sense is if it was limited to the hd authored format but i do not see it mentioning that.

[pandy]

the problem then is its still dealing with possibilities so can never be sure.


Hm - i think that this is no problem at all due of mandatory support for various color space inside codecs (H.262, H.264) - especially for H.262 seems that this is no problem due presence of sequence display extension also seems that for h.264 this information is to be much more optional (eg x264 implementations simply don't care about color space).


which frankly is rather stupid to me. its ignoring the precedence of current SD sources such as dvd. so if output to hd is going to be assumed those irrelevant of the real source that would be the dumbest thing ever. unless they want dvds to purposely look worse, now that is a possibility.
the only way those restrictions could make any sense is if it was limited to the hd authored format but i do not see it mentioning that.

In HDMI this is no problem due of mandatory signalization of used color space in AVI Info Frame... so if You use in content (which is HD) a 601 color space this is ok but not default. HDMI transmiter simply set proper color space signaling and everything is ok, You not loose anything... But as i say earlier from uknown to me reason SD by assumption is 601 and HD is 709.
If Your DVD uspcale SD DVD (which is 601) to the eg 1080i then simply signaling that 1080i is on 601 color space.

btw - testing equipment (HDMI analyzers) detect such situations and present AVI Info Frame as suspicious (not error but also not normal).

[tom942]

@dragongodz

I was asking just something similar to CCE's AQM, that, for instance, you use standard matrix, and if it is required it creates a halved or a quartered matrix.

I would like to use it under DVD-RB.

I don´t know Fortran and less which is the algorithm used by CCE, but if it can be included as a DLL or better as a command (like LUMGAIN), it would be great.

Regards.

[Boulder]

The problem is that no-one really knows how CCE determines the points where it changes the matrix. Hank made a decision to include an adaptive quant matrix feature which depends on the luma level, and in my opinion it works fine, helping the low-lit frames. If anyone could come up with a good algorithm (no actual code necessarily but the maths), I'm sure he would consider adding it to the encoder.

[jdobbs]

Funny thing is, 99% of the Rec.601 stuff I've seen have been sloppy NTSC to PAL transfers - i.e. butchered quality with fieldblending and a very soft video. Maybe it's the hardware encoder they use, I don't know..I've just not seen much of Rec.601 in good transfers. I assume the industry mostly uses Cinema Craft's products but I may be wrong there.I've noticed that on NTSC SD DVDs many of the menus, and a significant amount of previews are Rec.601. The features are Rec.709 with very few exceptions. One of the notable places I've seen Rec.601 is in the last (blank) segment of a feature used for command jumps.

[dragongodz]

so if You use in content (which is HD) a 601 color space this is ok but not default. HDMI transmiter simply set proper color space signaling and everything is ok, You not loose anything... But as i say earlier from uknown to me reason SD by assumption is 601 and HD is 709.
If Your DVD uspcale SD DVD (which is 601) to the eg 1080i then simply signaling that 1080i is on 601 color space.

then havent you killed your own request ? mpeg2 can carry colourimetry aswell.

I was asking just something similar to CCE's AQM

try Hc's method and see if it suitable for your needs or not.

[hank315]

IMO the effect of AQM and LUMGAIN is pretty similar, AFAIK AQM will be active when the bitrate can't be hold even with low quantizers so the matrix coefficients are lowered but as Boulder already said, no-one really knows how it works.
LUMGAIN in HCenc is always active and will do a mild or more agressive matrix change dependent of the luma values, it's meant do give a bit-boost on low lit scenes, not specifically meant to keep the bitrate but it will certainly help.

If anyone could come up with a good algorithm (no actual code necessarily but the maths), I'm sure he would consider adding it to the encoder.absolutely...


To flag a stream to be non Rec.709 an encoder needs to write the sequence_display_extension header with the proper settings.
If this header isn't in the bitstream the colorimetry will be Rec.709 by default according to the MPEG2 specs.
HCenc doesn't write this header, neither do QuEnc and CCE basic AFAIK.

Just tested 10 DVD's, 9 are Rec.709 (regular movies), 1 is Rec.470-2, that one is a compilation of TV episodes (Bottom by Adrian Edmondson & Rik Mayall).
Seems DVD-MPEG2 can have all kind of colorimetry flavors.

[pandy]

then havent you killed your own request ? mpeg2 can carry colourimetry aswell.


Hmmm... im not requesting anything - i only say that 601 is assumed as default for SD and 709 for HD in digital video industry.
So making assumption that 709 is for SD is maybe not good idea but... if 709 or 601 is properly signaled then everything is ok. IMHO creating possibility to set in HC all valid fields in MPEG-2 syntax will be nice (especially when add this functionality will not be problem for Hank - He is author of HC and He decide what and when will (or not) be implemented in HC).

**
Hank Thank You again, HC is a great software, appreciate Your work very much.

[dragongodz]

i only say that 601 is assumed as default for SD and 709 for HD in digital video industry.

which of course flies right in the face of

If this header isn't in the bitstream the colorimetry will be Rec.709 by default according to the MPEG2 specs.

so that would make the digital industry the real problem. at least with dvd specs they just used a more restricted subset of the mpeg2 specs rather than this silly assume 601 nonsense.

IMHO creating possibility to set in HC all valid fields in MPEG-2 syntax will be nice

yes thats 1 option for later. its just a pity that it should even have to be thought about.

Hank - He is author of HC and He decide what and when will (or not) be implemented in HC.

i know who Hank is thanks. :sly:

[kumi]

Hello,

It seems HCenc cannot load any HC.INI that has a *CQ_MAXBITRATE directive, and probably any other directive that has decimal number values, when Windows XP numbers configuration (in Regional Settings) is set to

Decimal Symbol: , (comma)
Digit Grouping Symbol: . (period)

The only way to load such an HC.INI is to ensure that the numbers configuration in Windows XP is set to

Decimal Symbol: . (period)
Digit Grouping Symbol: , (comma)


For example, I tried to load this HC.INI file:
*PROFILE NORMAL
*INFILE E:\Temp\D2VAVS\V01_Q_ANALYSIS.avs
*OUTFILE E:\Temp\D2VAVS\V01_Q_ANALYSIS.m2v
*BITRATE 0
*MAXBITRATE 6820
*WAIT 0
*BIAS 20
*CQ_MAXBITRATE 2.3
*LUMGAIN 0
*ASPECT 16:9
*GOP 12 2
*INTERLACED

I tested three combinations of the Windows Numbers settings. Only one of them was compatible with the above HC.INI.

ERROR, input not complete
http://img140.imageshack.us/img140/3117/naamloos3wp2.th.png (http://img140.imageshack.us/img140/3117/naamloos3wp2.png)

ERROR, input not complete
http://img515.imageshack.us/img515/6447/naamloos4jd7.th.png (http://img515.imageshack.us/img515/6447/naamloos4jd7.png)

HC.INI loaded successfully
http://img509.imageshack.us/img509/2654/naamloos5qy9.th.png (http://img509.imageshack.us/img509/2654/naamloos5qy9.png)


- - - - -

Might a workaround be possible?

[tom942]

Excuse me if this question has been asked before, but I've been unable to find the answer in the forum.

It's about HVS matrices, HC and HClow matrices.

For HVS (Good, Better, Best), I found something related on XviD forum, and I understand that they are indicated for medium to high bitrates, don´t I?.

But about HC matrices (HC and HCLOW), I don´t find anything, so what bitrates are indicated for?.

Thanks in advance.

Regards.

Edit: I would like to add a sugestion. It could be a good idea to add in the pdf, in the matrices section, what bitrates are indicated for in each matrix.

[fjhdavid]

the big problem is that wellknown DVD manufacturer like oppodigital always use bt.601 for internal YCB to RGB conversion (for DVD video).

then if HC uses bt.709 to encode, it will be problematic?

for information, the CCE owner's manual say that they use bt.601 (p.51 of the manual)
and this link too:
http://forum.doom9.org/showthread.php?s=&threadid=53770
(Question 12)

[doxville]

Hello!

I don't know why, but recently I have problems encoding with HC0.21 via commandline. I never encoded d2v-files directly, normally I use an avs-script, but the following problem came to show with a direct encode of a DGIndex 1.4.9. project:
The the following ini-file can be started with the 'encode'-button in the HCGUI, but when i try to start it directly from the HCenc.exe via commandline D:\HC021\HCenc_021.exe -ini D:\HC021\HC.ini, I get an error message, that there is no MPEG2 decoder.
The ini-file:*INFILE d:\filme\input.d2v
*OUTFILE D:\Filme\output.m2v
*BITRATE 3124
*MAXBITRATE 6500
*FRAMES 0 262257
*PROFILE best
*ASPECT 4:3
*AUTOGOP 15
*INTERLACED
*TFF
*BIAS 30
*LASTIFRAME
*CUSTOMMATRIX
8 10 16 20 25 28 33 44
10 10 14 26 27 29 34 47
16 14 18 27 29 34 37 48
20 26 27 31 36 37 38 50
25 27 29 32 37 40 48 58
28 33 36 42 45 50 58 68
33 37 39 44 48 56 66 79
37 39 45 48 56 66 79 83

16 18 20 22 23 27 32 40
18 20 22 24 26 32 36 42
20 22 24 26 33 38 42 44
22 24 26 34 38 42 44 46
23 26 33 38 42 44 46 48
27 32 38 42 44 46 48 50
32 36 42 44 46 48 50 52
40 42 44 46 48 50 52 58
*LUMGAIN 2
*CPU mmx

Here (http://tinypic.com/view.php?pic=2daxa8p&s=2) both of the encoding screens, one with error-message from the ini-/HCenc.exe-combination, one without error message from the encode-from-GUI-combination.

Any ideas what is wrong? Where is HCenc.exe looking for the right dgdecode.dll?

[Wilbert]

for information, the CCE owner's manual say that they use bt.601 (p.51 of the manual)
Could you post a screenshot of that page of this manual?

If this is really true, then this is a bug in CCE and should be reported to them. CCE doesn't write any colorimetry in the header of the resulting MPEG-2 streams. Which means that they are Rec.709 by default. This also implies that Rec.709 should be used when feeding RGB stuff to CCE (assuming that CCE does the color conversion).

[hank315]

Any ideas what is wrong? Where is HCenc.exe looking for the right dgdecode.dll?
HCenc uses the normal dll search path so it will first look in the directory from which it is loaded.
Normally it won't be there, HCenc can handle different version of DGIndex/DGDecode so the GUI reads the first line from the D2V file and copies the right version from the dgdecode directory as dgdecode.dll.
If the GUI isn't used just make sure the right dll is in the HCenc directory, or copy it to the windows/system32 directory as dgdecode.dll.

[doxville]

@hank315

Thanx, copying DGdecode in the 'normal' HC021 folder did it! Furthermore, thanx for your great work! I really like HCenc!

[45tripp]

Could you post a screenshot of that page of this manual?

I believe it's this being quoted:

http://img141.imageshack.us/img141/6265/ccemanpej2.jpg (http://imageshack.us)

[Wilbert]

Ok, thanks! So for YCbCr [0,255] <-> RGB [0,255], they use (rounded to four decimals):

Y = 0.3008*R + 0.5859*G + 0.1133*B
etc ...

which is very close to the Rec.601 coefficients. Someone should send them a mail asking them to correct their stuff (either use the Rec.709 coefficients in the conversion or write the appropriate coefficients in the header).

[fjhdavid]

I read somewhere that DVD color matrix is bt.601 because it is SD

for example, oppodigital guys told me that their DVD players are bt.601 compliant for SD output

then it seems normal that CCE use bt.601 as it is wriiten in their owner manual

I think they omit to write the color matrix bt.601 header

anyway, maybe with getgray dvd calibration (which is bt.601), we can see if CCE output bt.601 or bt.709?

[dragongodz]

lets please continue this conversation here

http://forum.doom9.org/showthread.php?p=1059703

as this is basically just cross posting.

[IanB]

@Wilbert,

Not to confuse but Cinema Craft are just using rounded 8 bit coefficients.

0.299 * 256 = 76.544 => 77
0.587 * 256 = 150.272 => 150
0.114 * 256 = 29.184 => 29

Which incidently is not recomended unless performance is an issue.

[jdobbs]

It's also talking about "source" not "output"... which is where the Rec.709 requirement comes in.

[tom942]

@hank315

What bitrates are "HC" and "HClow" recommended for?.

Please, dispel me this doubt :).

Thanks and regards.

[chrishallowell]

Hi all,
I'm hoping someone might be able to help me here...

I'm using HCGUI with an avs file that uses soundOut()

When I hit the Encode button, the Soundout Gui window pops up but when I click on the save as button to encode it as an AC3, I get this error: "Could not initialize encoder. Probably invalid input."

I'm guessing I'm missing a program or it's in the wrong directory....
Any ideas?

I can save it as a wav file.

Here's my test script:

LoadPlugin("degrainmedian.dll")
LoadPlugin("fft3dfilter.dll")
LoadPlugin("ColorMatrix.dll")
LoadPlugin("AudioLimiter.dll")
LoadPlugin("soxfilter.dll")
loadplugin("SoundOut.dll")

avisource("E:\Orginal with audio -480ms delay.AVI",audio=true)
AssumeFPS("ntsc_video",sync_audio=true)
Trim(101,4458).Fadeio(30)
ConvertAudioToFloat().SSRC(41000)
fl = GetRightChannel()
fr = GetRightChannel()
cc = mixaudio(GetRightChannel(),GetRightChannel(),0.707,0.707)
lfe = GetRightChannel() #ConvertToMono(a).SoxFilter("lowpass 120","vol 1.2")
sl = GetRightChannel() #.amplify(-1.0)
sr = GetRightChannel() #.amplify(-1.0)
sl = DelayAudio(sl,0.02)
sr = DelayAudio(sr,0.02)
MergeChannels( fl, fr, cc, lfe, sl, sr).wavgainlimiter(1.0)
SoundOut()
Thanks,
Chris

[LigH]

a) HCEnc does not care about audio. It may be safer to feed it a stripped-down script which outputs only video. Else there could be too many possible reasons for failing.

b) HCEnc requires YV12 video output. Ensure this either via AviSource(pixel_format="YV12"), or by adding ConvertToYV12(interlaced=true/false).

[fjhdavid]

Hank, do you plan an another upgrade to HC encoder? and what would be the improvements?

as you maybe read in the DVD forum, I found that DVD-RB with HC-encoder scaled better with dualcore than with quadcore (my dualcore is around 20% speeder than my quadcore, both having same frequency when I use multiple encoder setting in DVD-RB)

is it possible to improve HC encoder in this way? (but maybe it is inherent to processor architecture)?

[Boulder]

See the 024 beta thread in this very forum ;)

[zeropc]

say, is there any chance that the new version of hcenc will accept .dga as input?

btw, how do you crop on the sides to add new black bars (reduces encoding time, etc.) and center the video/film?

[zeropc]

can no one tell me how to crop the sides to add fresh black bars?

[LigH]

AviSynth has all the functions you'll need to change the size of the "active" video area inside the whole video dimensions: Several "Resize" filters, "Crop" and "AddBorders" (or even "Letterbox" to simply tint a frame without resizing). Tools like "Fit2Disc" may help you creating a script which has macroblock optimized letterbox or even framebox sizes.

HC will encode any video of acceptable dimensions and properties. Optimizing the content is the job of AviSynth, not of HC Encoder.

[Guest]

say, is there any chance that the new version of hcenc will accept .dga as input? There's no point. You can just make an Avisynth script that serves the video and open that.