Experiences with HC Encoder

[SCSI]

What quenc options in DVD-RB (free) should I use when pointing to HCbatch? Does the settings in the HC.ini the ones used instead of the quenc settings?

[DMagic1]

Originally posted by jdobbs
@TheSeeker

If you're talking about the Pro version, yes. In the Pro version you don't need the HC.INI file -- DVD-RB creates it in the working directory.
Oh really it create one if one isn't there? Whats the default matrix when RB creates the hc.ini?

[jdobbs]

Originally posted by SCSI
What quenc options in DVD-RB (free) should I use when pointing to HCbatch? Does the settings in the HC.ini the ones used instead of the quenc settings? The ones on the command line are covered... but you'll need an INI to cover the ones that aren't.

[jdobbs]

Originally posted by DMagic1
Oh really it create one if one isn't there? Whats the default matrix when RB creates the hc.ini? It doesn't create a "*MATRIX" entry in the INI and lets HC use its default. If, though, you have a matrix other than "Encoder Default" selected under the new advanced options -- it will use the one you have selected.

[m3taPT]

Although it is a fabulous work so far, (don't take me wrong) but compared to a 5 or 7 pass CCE encoding (that's my usual standard) on a dual 2.4 Xeon, it is extremely slow, even though it makes several passes less.

Is multiprocessor / multithreading support in the works?

[TCrowe]

I did an HC encode last night with .80 Pro RB and everything looks nice. Just starting the comparison to the original but the troubling part is the final output was only 3.87 GB. I just read in an earlier post in this thread that someone else had a similar experience.

Anyone else coming up short on the final output?



Here is the log from the test:

[23:05:09] One Click encoding activated...
-----------------
[23:05:09] Phase I, PREPARATION started.
- HC encoder selected
- "Half-D1/Half Space for Extras" mode is enabled.
- "Steal Space from Extras" mode is enabled.
- VTS_01: 3,083,385 sectors.
-- Scanning and writing .D2V file
-- Processed 164,723 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 74.4%
- Overall Bitrate : 4,663Kbs
- Space for Video : 3,910,644KB
- Movie improvement from extra reduction = .0%
- HIGH/LOW/AVERAGE Cell Bitrates: 5,261/297/4,663 Kbs
[23:08:24] Phase I, PREPARATION completed in 3 minutes.
[23:08:24] Phase II ENCODING started
- Creating M2V for VTS_01 segment 0
- Creating M2V for VTS_01 segment 1
- Creating M2V for VTS_01 segment 2
- Creating M2V for VTS_01 segment 3
- Creating M2V for VTS_01 segment 4
- Creating M2V for VTS_01 segment 5
- Creating M2V for VTS_01 segment 6
- Creating M2V for VTS_01 segment 7
- Creating M2V for VTS_01 segment 8
- Creating M2V for VTS_01 segment 9
- Creating M2V for VTS_01 segment 10
- Creating M2V for VTS_01 segment 11
- Creating M2V for VTS_01 segment 12
- Creating M2V for VTS_01 segment 13
- Creating M2V for VTS_01 segment 14
- Creating M2V for VTS_01 segment 15
- Creating M2V for VTS_01 segment 16
- Creating M2V for VTS_01 segment 17
- Creating M2V for VTS_01 segment 18
- Creating M2V for VTS_01 segment 19
- Creating M2V for VTS_01 segment 20
- Creating M2V for VTS_01 segment 21
- Creating M2V for VTS_01 segment 22
- Creating M2V for VTS_01 segment 23
- Creating M2V for VTS_01 segment 24
- Creating M2V for VTS_01 segment 25
- Creating M2V for VTS_01 segment 26
- Creating M2V for VTS_01 segment 27
- Creating M2V for VTS_01 segment 28
- Creating M2V for VTS_01 segment 29
- Creating M2V for VTS_01 segment 30
- Creating M2V for VTS_01 segment 31
- Creating M2V for VTS_01 segment 32
- Creating M2V for VTS_01 segment 33
- Creating M2V for VTS_01 segment 34
- Creating M2V for VTS_01 segment 35
- Creating M2V for VTS_01 segment 36
- Creating M2V for VTS_01 segment 37
- Creating M2V for VTS_01 segment 38
- Creating M2V for VTS_01 segment 39
- Creating M2V for VTS_01 segment 40
- Creating M2V for VTS_01 segment 41
- Creating M2V for VTS_01 segment 42
- Creating M2V for VTS_01 segment 43
[05:37:32] Phase II ENCODING completed in 389 minutes.
[05:37:32] Phase III, REBUILD started.
- Copying IFO, BUP, and unaltered files...
- Processing VTS_01
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Rebuilding segment 2 VOBID: 1 CELLID: 3
- Rebuilding segment 3 VOBID: 1 CELLID: 4
- Rebuilding segment 4 VOBID: 1 CELLID: 5
- Rebuilding segment 5 VOBID: 1 CELLID: 6
- Rebuilding segment 6 VOBID: 1 CELLID: 7
- Rebuilding segment 7 VOBID: 1 CELLID: 8
- Rebuilding segment 8 VOBID: 1 CELLID: 9
- Rebuilding segment 9 VOBID: 1 CELLID: 10
- Rebuilding segment 10 VOBID: 1 CELLID: 11
- Rebuilding segment 11 VOBID: 1 CELLID: 12
- Rebuilding segment 12 VOBID: 1 CELLID: 13
- Rebuilding segment 13 VOBID: 1 CELLID: 14
- Rebuilding segment 14 VOBID: 1 CELLID: 15
- Rebuilding segment 15 VOBID: 1 CELLID: 16
- Rebuilding segment 16 VOBID: 1 CELLID: 17
- Rebuilding segment 17 VOBID: 1 CELLID: 18
- Rebuilding segment 18 VOBID: 1 CELLID: 19
- Rebuilding segment 19 VOBID: 1 CELLID: 20
- Rebuilding segment 20 VOBID: 1 CELLID: 21
- Rebuilding segment 21 VOBID: 1 CELLID: 22
- Rebuilding segment 22 VOBID: 1 CELLID: 23
- Rebuilding segment 23 VOBID: 1 CELLID: 24
- Rebuilding segment 24 VOBID: 1 CELLID: 25
- Rebuilding segment 25 VOBID: 1 CELLID: 26
- Rebuilding segment 26 VOBID: 1 CELLID: 27
- Rebuilding segment 27 VOBID: 1 CELLID: 28
- Rebuilding segment 28 VOBID: 1 CELLID: 29
- Rebuilding segment 29 VOBID: 1 CELLID: 30
- Rebuilding segment 30 VOBID: 1 CELLID: 31
- Rebuilding segment 31 VOBID: 1 CELLID: 32
- Rebuilding segment 32 VOBID: 1 CELLID: 33
- Rebuilding segment 33 VOBID: 1 CELLID: 34
- Rebuilding segment 34 VOBID: 1 CELLID: 35
- Rebuilding segment 35 VOBID: 1 CELLID: 36
- Rebuilding segment 36 VOBID: 1 CELLID: 37
- Rebuilding segment 37 VOBID: 1 CELLID: 38
- Rebuilding segment 38 VOBID: 1 CELLID: 39
- Rebuilding segment 39 VOBID: 1 CELLID: 40
- Rebuilding segment 40 VOBID: 1 CELLID: 41
- Rebuilding segment 41 VOBID: 1 CELLID: 42
- Rebuilding segment 42 VOBID: 1 CELLID: 43
- Rebuilding segment 43 VOBID: 1 CELLID: 44
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_01_0.IFO
Correcting VTS Sectors...
[05:48:06] Phase III, REBUILD completed in 11 minutes.

Done.
[05:48:06] PREPARE/ENCODE/REBUILD completed in 403 min.

[buzzqw]

try to force gop to 12

BHH

[JohnG]

No matter what I do I can't get RB to find the HC.exe file. I am using the Pro Rb(079) version and HC_0.01 (obviously renamed to HC.exe). I have placed it in the same directory under C:Program Files\DVD-Rb. Would it help to remove all older versions of RB? I only keep them as zip files in a separate directory anyway.

I usually use CCE but would like to utilize HC with QLB matrix for bitrates ~2k (large backups).

[hank315]

Tried the Pro 080 version with the latest HC version.
Just want to say jdobbs did a great job, worked OK for me.
Rename the HCbatch_xxx.exe to HCbatch.exe, that's all.

Just put the latest batch version online.

Changelog:
- fixed an error where the scan flag wasn't set properly for interlaced source using argument input
- added *WAIT command to speed up exit after encoding
- some other minor bugs fixed
- 1, 2 and 3 frame clips are now encoded using Constant Quant

Download contains GUI and batch version + updated manual.
Will be in the download section soon.

Also at: http://hank315.dyndns.org/HC_012_total.zip

[jdobbs]

Originally posted by hank315
Tried the Pro 080 version with the latest HC version.
Just want to say jdobbs did a great job, worked OK for me.
Rename the HCbatch_xxx.exe to HCbatch.exe, that's all.

Just put the latest batch version online.

Changelog:
- fixed an error where the scan flag wasn't set properly for interlaced source using argument input
- added *WAIT command to speed up exit after encoding
- some other minor bugs fixed
- 1, 2 and 3 frame clips are now encoded using Constant Quant

Download contains GUI and batch version + updated manual.
Will be in the download section soon.

Also at: http://hank315.dyndns.org/HC_012_total.zip Actually you don't even have to rename it. DVD-RB looks for the first file that starts with "HCBATCH" and ends with ".EXE"

[DK]

having copied more than one hc*.exe file into rb's main folder, which will be chosen? :)

[jdobbs]

It has to be "HCBatch..." now, not "HC...", but it will grab the first one in the directory. In other words, you should only keep one there at a time. I was just trying to avoid having to rename it or look for a different name for each version.

[hobyho]

Originally posted by DK
having copied more than one hc*.exe file into rb's main folder, which will be chosen? :)

My question to you is, 'Why have different versions of HC in the RB folder?'

[quantum]

Originally posted by jdobbs
Actually you don't even have to rename it. DVD-RB looks for the first file that starts with "HCBATCH" and ends with ".EXE" Are you sure this works? I copied HCbatch_012a.exe into the rebuilder directory and got a file not found error after the prepare phase (one click mode). Renaming to hcbatch.exe and starting again from the encode phase is working so far. This could be my own error but maybe someone else can confirm.

[hank315]

Renaming to hcbatch.exe and starting again from the encode phase is working so far. This could be my own error but maybe someone else can confirm.Yes, same error message here.
Had to rename it also, after that no problems...

[jdobbs]

Odd... I haven't renamed it in mine... I guess I need to look at that.

[kbello]

for me works without rename

[m3taPT]

Here it works without rename, on 2 machines.

Those 2 machines - One is a Dual Xeon 2.4, the other is an AMD 2200. - doing the same rip have roughly the same encoding speeds.

Is this to be expected?

[hobyho]

No renaming needed for me also. Works fine.

[rpboy]

I wonder if the people who it didn't work for are on Windows 98 or Windows ME?

If it is, I could see where maybe the program isn't seeing the file in those operating systems because of the difference between long file names and the DOS name. HCBatch_012a.exe could be seen as HCBATC~1.EXE which might not get recognized by DVD-Rebuilder.

Just a thought.

[DK]

My question to you is, 'Why have different versions of HC in the RB folder?'

well, rb came with one version of hc*.exe

then hank released a new version and and i tend to keep different versions in order to compare them

sooner or later there might be another release of hc_enc and because there is no option to select hc*.exe like quenc, cce or procoder within the setup (maybe jdobbs could .... ;) ) i have more than one hc*.exe file in my rb folder

[JohnG]

Follow-up-
Since installing the new Rb(080 Pro) I am finally encoding with HC as we speak. I actually put all the files in a different directory than the normal C:Program.....etc. It now resides in my D: drive. I didn't bother to rename the encoder...just configured Rb and fired it up in HC mode and it found everything fine this time. One note though. Seems extremely slow. I'm backing up Lord of the Rings (Fellowship) and it's about 75% the way through and has been running for 12 hrs! Usually I can get CCE2.5 OPV to finish a movie in real time. I have the default matrix set in BEST mode. Is this normal? I am using HC for the quality because the bitrate is near 2000 but I'm not sure the results will be commensurate with the time. CCE can do a good job with filtering as long as the rate stays <2000 and finish MUCH quicker even in 2passVBR.

[jdobbs]

I always use the "NORMAL" or "GOOD" settings. I don't think I have the patience for "BEST"

[jdobbs]

Originally posted by DK
well, rb came with one version of hc*.exe

then hank released a new version and and i tend to keep different versions in order to compare them

sooner or later there might be another release of hc_enc and because there is no option to select hc*.exe like quenc, cce or procoder within the setup (maybe jdobbs could .... ;) ) i have more than one hc*.exe file in my rb folder I may replace the pointer to DECOMB.DLL with it... if DECOMB.DLL is in the AVISYNTH plug-in directory you don't need that line anyway (and it is rarely used).

[JohnG]

Originally posted by jdobbs
I always use the "NORMAL" or "GOOD" settings. I don't think I have the patience for "BEST"

In your experience, is this akin to TMPGEnc's settings of "normal", "high" and "highest"? The difference between high and highest quality is negligible but the encoding time bogs down. Between normal and high there is a difference in quality (albeit small) so it usually is worth going with "high" as a good compromise for speed AND quality. Could this analogy be applied to the HC encoder? In other words, is "GOOD" a nice compromise of speed and quality?

BTW, your product has made my life (and my family's life, now that I spend less time in front of my computer) easier and richer. Thanks for all your hard work. My donation is FAR and away the best money I've ever spent.

[jdobbs]

Thanks, much...

My feeling is that GOOD is the right compromise... but I also don't think that I have a sample base large enough to make a conclusion yet.

[SAPSTAR]

I just tried to use HC instead of CCE just to compare...
Settings :
Quality BEST
Quant. MATRICES :
AVAMAT6 for Main features + Low Bitrates
EQMV3_ULB for Very Low BitRates
BACH1 for Half-D1

DVD-RB 0.80Pro + HCBatch 0.12 (the one coming with the last DVD-RB Pro)
Movie: XFiles Season 3 Disc 7 NTSC

The size of the result was only 4.05G :confused: instead of the usual 4.36G.

Did anybody encounter the same issue ??

P.S. : Jdobbs...you're doing a really good job, the introduction of the Q Matrices is a dream for me !!! When I'll have more money, I'll send you another donation, thank you for your great job ! :thanks:

[TCrowe]

Originally posted by SAPSTAR
I just tried to use HC instead of CCE just to compare...
Settings :
Quality BEST
Quant. MATRICES :
AVAMAT6 for Main features + Low Bitrates
EQMV3_ULB for Very Low BitRates
BACH1 for Half-D1

DVD-RB 0.80Pro + HCBatch 0.12 (the one coming with the last DVD-RB Pro)
Movie: XFiles Season 3 Disc 7 NTSC

The size of the result was only 4.05G :confused: instead of the usual 4.36G.

Did anybody encounter the same issue ??

P.S. : Jdobbs...you're doing a really good job, the introduction of the Q Matrices is a dream for me !!! When I'll have more money, I'll send you another donation, thank you for your great job ! :thanks:


Yes, my experiment came out 3.87 GB. Someone recommended "try to force gop to 12", I have not tried this yet. If you do can you please post your results?

Thanks

[SAPSTAR]

I'm currently trying to encode Xfiles Season 3 Disc5 with the latest version of HCBatch, I'll keep GOP Size on Auto as I read (in the HC Encoder forum) that it doesn't really change the size of the result....The latest version is supposed to correct some bugs, the scan flag for example...:cool:

[TCrowe]

Thanks for the info SAPSTAR, look forward to your results.

[ElRey]

So far I've had great results with HC. In the past I had tried DVD-RB before, but I didn't want to lay out the $$ for CCE and using QuEnc with DVD-RB took like 25 hours to encode a full DVD on my machine where HC is taking like 8 hours. Anyways, it's enough of a speed improvement that I went and donated to DVD-RB and plan to use it (and HC) as my main app for this.

I have a P4 with hyperthreading though and I noticed that when encoding that only 50% of the CPU was being used (probably 100% of one of them). Anyways, I got to thinking if it would be possible to run 2 copies of HC at the same time and get 100% CPU utilization. So, I ran 2 copies and set each to use one of the AVS files created by DVD-RB on the last run (just picked the first 2). HC appears to have run fine and both encodes finished at about the same time (haven't had a chance to look at the m2v files yet to make sure they look ok). CPU utilization was 100% during the run. Is there any chance DVD-RB could be enhanced to allow this kind of operation? I would be a quick and easy way to cut my encoding time in half!

[jdobbs]

Wow. It has been my experience that QuEnc is considerably faster than HC... I guess it all depends on your environment.

[Rockas]

@ElRey
Have you tried to change your process priority?

[SAPSTAR]

Originally posted by jdobbs
Wow. It has been my experience that QuEnc is considerably faster than HC... I guess it all depends on your environment.

And the settings too :) I suspect that the undersize pb could rise only with the BEST mode. I have a test running, once finished if it still undersized, I'll run with the GOOD mode. And if this test is bad again, I'll test a PAL movie, as I only tested NTSC movies !
Anyway, so far I found the quality surprisingly good in comparison with CCE or others....

[SAPSTAR]

Originally posted by TCrowe
Thanks for the info SAPSTAR, look forward to your results.

The result is 4.28Gb with HC 0.12a...it's a little bit undersized but I'll keep it...it took 11 hours to be processed. Anyway, the quality is really good. I suspect that HC Encoder is using 1024 instead of 1000 for kilobits.......We should ask to Hank !?!?!

[ElRey]

Originally posted by Rockas
@ElRey
Have you tried to change your process priority?

That wouldn't make a difference. From Windows XP's standpoint, the hyperthreaded processor is treated as 2 processors. If I go into Task Manager and select "View / CPU History / One Graph Per CPU" on the menu, I actually get 2 CPU Usage History graphs instead of just one.

So when I'm running an encode with DVD-RB and HC, one processor is ~100% dedicated to HC and the second processor is ~100% dedicated to DVD-RB (which is more or less inactive waiting for HC to finish). In Task Manager one graph is at 100% and the other graph is near 0%. When I run 2 copies of HC encoding simultaneously both graphs go to 100%.

When you use the multithreaded version of CCE, the one CCE process is handling splitting the workload across the 2 "processors" on the HT P4. Since HC is single threaded it doesn't split the work across processors itself like CCE does, but if you run 2 copies of HC at the same time, Windows spreads the work over both processors for you. It's the difference between multiple threads in the same process versus multiple processes.

So if DVD-RB could spin off 2 HC processes at the same time both "processors" would be engaged and (theoretically) the time to encode should be cut in half (each processor takes half of the segements).

[m3taPT]

Originally posted by ElRey
That wouldn't make a difference. From Windows XP's standpoint, the hyperthreaded processor is treated as 2 processors. If I go into Task Manager and select "View / CPU History / One Graph Per CPU" on the menu, I actually get 2 CPU Usage History graphs instead of just one.

So if DVD-RB could spin off 2 HC processes at the same time both "processors" would be engaged and (theoretically) the time to encode should be cut in half (each processor takes half of the segements).

I have dual processors (yes, Task Manager shows 4) and i tried running 2 processes like you did, and yes, i could make 2 of them used.
The "first" processor and the "threaded" processor of the first (how shall one call it? the virtual-threaded maybe?) were used, but that still didn't make the second and the threaded second to be used.

And i don't think that spawning FOUR processes would be the logical (to say the least).

CCE's behaviour: 1st and 3rd go to 100% cpu, and the 2nd and 4th (the threaded ones), vary between 60%-90%.

And with the enormous amount of fans i installed on this box specially to make it dedicated to encoding... right now, CCE is still the logical choice to maximize cpu usage (and all the other hardware).

[ElRey]

Originally posted by m3taPT
I have dual processors (yes, Task Manager shows 4) and i tried running 2 processes like you did, and yes, i could make 2 of them used.
The "first" processor and the "threaded" processor of the first (how shall one call it? the virtual-threaded maybe?) were used, but that still didn't make the second and the threaded second to be used.

How about "logical processor" (vs physical)? So, since you have 4 logical processors if you start 4 copies of HC and get them all encoding at once, do all 4 logical processors go to 100% in Task Manager? You need to start one encode per logical processor to repeat my test.

And i don't think that spawning FOUR processes would be the logical (to say the least).

Why not? Programmers have been using fork(), exec(), etc. in Unix for like 30 years! Windows will automatically manage the workload across CPU's for you, and DVD-RB is already spawning one process per segment for the encoding step, just serially instead of in parallel. If the capability is there in Windows already, why not use it? Granted that creating a process is heavier than creating a thread, so a MPEG encoder process with multiple threads should be more optimal than running multiple MPEG encoder processes, but it's a cheap way for those of us who don't have CCE (but do have HT P4's) to see a major increase in encoding performance.

[dragongodz]

ok lets clear this up so people can PLEASE stop asking.

HC 0.12 uses 1000Kbit/s.

HC can undersize using any of the modes. better rate control is already on the list to be worked on.

HC is not multithreaded so on dual cpu or P4 HT will not be using the full cpu resources unlike CCE. try it on a single cpu or HT turned off however and it is pretty quick.

[Thor263]

Ok, I've run into a different problem with DVD-RB 0.80 + HCBatch_012 (or 12a for that matter) that I haven't seen posted anywhere. I'm trying to encode the original NTSC Tomb Raider and HC seems to loop partway through the encode - it indicates it is an intermediate pass. Task manager shows HCBatch_012 as taking all of the cpu. I've tried the version that came with 0.80 and the newer 12a version - both exhibit the problem. There doesn't seem to be any problem stopping the process using the DVD-RB "Stop/Pause" button however.

I'm running XP Pro w/ SP2 on an Athlon 1800+. No preprocessing of any type was done. I've included the RB log - VTS_03 segment 13 is where the problem occurs. What other information can I supply that would be useful?

[20:16:03] Phase I, PREPARATION started.
- HC encoder selected
- "Half-D1/Half Space for Extras" mode is enabled.
- VTS_02: 44,443 sectors.
-- Scanning and writing .D2V file
-- Processed 3,020 frames.
-- Building .AVS and .ECL files
- VTS_03: 2,002,902 sectors.
-- Scanning and writing .D2V file
-- Processed 144,672 frames.
-- Building .AVS and .ECL files
- VTS_04: 560,700 sectors.
-- Scanning and writing .D2V file
-- Processed 45,773 frames.
-- Building .AVS and .ECL files
- VTS_05: 140,363 sectors.
-- Scanning and writing .D2V file
-- Processed 12,264 frames.
-- Building .AVS and .ECL files
- VTS_06: 403,382 sectors.
-- Scanning and writing .D2V file
-- Processed 36,395 frames.
-- Building .AVS and .ECL files
- VTS_07: 188,263 sectors.
-- Scanning and writing .D2V file
-- Processed 14,376 frames.
-- Building .AVS and .ECL files
- VTS_08: 210,960 sectors.
-- Scanning and writing .D2V file
-- Processed 16,991 frames.
-- Building .AVS and .ECL files
- VTS_09: 128,903 sectors.
-- Scanning and writing .D2V file
-- Processed 13,033 frames.
-- Building .AVS and .ECL files
- VTS_10: 80,634 sectors.
-- Scanning and writing .D2V file
-- Processed 7,241 frames.
-- Building .AVS and .ECL files
- VTS_11: 41,235 sectors.
-- Scanning and writing .D2V file
-- Processed 3,792 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 53.5%
- Overall Bitrate : 2,351Kbs
- Space for Video : 3,561,568KB
- Movie improvement from extra reduction = 53.6%
- HIGH/LOW/AVERAGE Cell Bitrates: 6,839/393/2,351 Kbs
[20:23:20] Phase I, PREPARATION completed in 7 minutes.
[20:28:05] Phase II ENCODING started
- Creating M2V for VTS_02 segment 0
- Creating M2V for VTS_02 segment 1
- Creating M2V for VTS_03 segment 0
- Creating M2V for VTS_03 segment 1
- Creating M2V for VTS_03 segment 2
- Creating M2V for VTS_03 segment 3
- Creating M2V for VTS_03 segment 4
- Creating M2V for VTS_03 segment 5
- Creating M2V for VTS_03 segment 6
- Creating M2V for VTS_03 segment 7
- Creating M2V for VTS_03 segment 8
- Creating M2V for VTS_03 segment 9
- Creating M2V for VTS_03 segment 10
- Creating M2V for VTS_03 segment 11
- Creating M2V for VTS_03 segment 12
- Creating M2V for VTS_03 segment 13

[m3taPT]

Originally posted by ElRey
Why not? Programmers have been using fork(), exec(), etc. in Unix for like 30 years!

I'm a *nix programmer. (not for 30 years, "only" for almost 20). Please don't dare to compare *nix's way to do things with Windows. It's a sacrilege, and this is not the proper place to do it.

[ElRey]

Originally posted by dragongodz
ok lets clear this up so people can PLEASE stop asking
HC is not multithreaded so on dual cpu or P4 HT will not be using the full cpu resources unlike CCE.

That was (IMHO) the beauty of the technique I was suggesting. You can get full CPU utilization on a HT P4 or dual CPU box without modifying the existing HC at all. Only DVD-RB would have to be modified.

If you think of it in terms of batch files, my impression of what DVD-RB does now during the encoding step would look something like:

REM Write the hc.ini
HCbatch –ini hc.ini
REM Write a new hc.ini
HCbatch –ini hc.ini

and what I'm suggesting is more like:

REM Write one INI file per segment during the Prepare step
start HCbatch –ini segment01.ini
HCbatch –ini segment02.ini

The second batch has 2 copies of HC running concurrently (due to the START command) and will always finish in less time (and have better CPU utilization) on a dual processor / HT P4 box than the first batch file (all other things being equal). Concurrent encoding would (IMHO) be a nice option to have built into DVD-RB for folks with HT P4's / dual CPU machines.


P.S. For the dual HT P4 scenario (4 logical processors) it would be something like:

REM Write one INI file per segment during the Prepare step
start HCbatch –ini segment01.ini
start HCbatch –ini segment02.ini
start HCbatch –ini segment03.ini
HCbatch –ini segment04.ini

[dragongodz]

That was (IMHO) the beauty of the technique I was suggesting. You can get full CPU utilization on a HT P4 or dual CPU box without modifying the existing HC at all.
yes i understood what you were suggesting and my reply wasnt aimed at you. it was to all the people that keep saying or asking about things that have been discusses and said already, such as speed and output undersize etc.

[quantum]

I just finished an episodic dvd9 disk which was filled to the brim with interlaced NTSC. I tried both CCE 2.6x and Hanks latest encoder using the best option. Looking carefully at several frames there are many frames where Hanks output is clearly better. There are others where CCE might be slightly better. So it's an interesting dilema, but one that I'm glad to have. Kudos again to Hank for his fine work.

[Pabloz]

im having problems to download the HC BATCH posted in the stiky
the elinks seems to be wrong

[Vanderlow]

This link should work.

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

[Trahald]

hank updated hcenc12batch with a different filename (some bug fixes ) and apparently took down the one linked in the sticky

[Morte66]

Does anyone have a view on whether it's best to enable/disable scene change detection in HC?

[edeus]

Is there a general concensus that HC is best (compared to other encoders) for both high and low bitrate encodes?

I'd love to make the switch as I am finding if CCE 3pass doesnt have 3gb+ of main movie space, quality drops terribly.

From what I am reading CCE is still great due to quality+speed but HC overall is better quality wise sacrificing quality.

i always thought dvd-rb + cce was good enough to handle a 2 hour movie + 1 hour of extras recompressed without noticable image loss but i am realising the awful truth about dvd5 limitations now. perhaps it is still necessary to cut out extras if they are too large as i am finding 50% quality drop is still taking up valuable space even though they are basically unwatchable.

[hank315]

Does anyone have a view on whether it's best to enable/disable scene change detection in HC?Best is to enable it.
On a scene change a new GOP will start, that's better than have a intra coded P or B frame in a GOP or there must be a special reason to have a fixed GOP length.

For people having trouble downloading HC, it's also in the Doom9 download section.