HCenc 024

[hank315]

Update 10-sep-2010
For the final HC024: http://hank315.nl

----------------------------------------------------

A beta of HCenc 024 can be downloaded here (http://www.mediafire.com/?vzbmydxgv4k)

For now it's the encoder only so you have to edit the hc.ini file manually.
New features:

*1PASS
This command enables 1 pass VBR encoding.
1 pass can be used for clips > 1000 frames, smaller clips are done using 2 pass.

*CHROMAFORMAT 420
*CHROMAFORMAT 422
Output can be 420 (default) or 422 color space,
for 422 color space YUY2 input is required, for 420 input can be YV12 or YUY2

*INTRAVLC 0
*INTRAVLC 1
Chooses the VLC table for intra blocks: 0 = table14, 1 = table15. (non-intra blocks are always table14)
Default is *INTRAVLC 0.
In general *INTRAVLC 0 is better for low bitrates, *INTRAVLC 1 for high bitrates.


Notes:
- The 1 pass is really *very* beta.
- HCenc now accepts YUY2 input, for 420 output the chroma is sub-sampled progressively, in the final release it can also be done interlaced.
- Some bugs are solved, probably some new introduced...

Many thanks to manolito and Darksoul71 for the 1 pass code discussion/testing :)

[Video Dude]

:thanks:

One pass and YUY2 input are great new features.

[Adub]

Yes, indeed. Thanks a lot for your hard work there Hank!

[MrC]

Thanks for this new beta. As I said you during my preliminary testing some weeks ago, 1-pass VBR is really impressive: accurate and high quality. My only concern was the "small" predictive routine timings: faster than a standard 1st pass but slower than a 10% OPV (constant quantization).

Another question: when you say In general *INTRAVLC 0 is better for low bitrates, *INTRAVLC 1 for high bitrates what is the limit between high and low bitrates? I mean, high bitrates for DVD-MPEG2 could be considered low bitrates for BD-MPEG2...

Thanks again for your hard and great work.

;)

Bye

[manolito]

Also thanks very much for this version. This one-pass mode is so good, I have already abandoned 2-pass VBR altogether...:)

The only issues I found are the same as in the older beta: A slight stability issue when exiting the encoder during the second stage of the sampling phase (sometimes HC just freezes), and the command line parameters "-1pass" and "-2pass" are not implemented yet.

My only concern was the "small" predictive routine timings: faster than a standard 1st pass but slower than a 10% OPV (constant quantization).

I cannot confirm these findings on my machine (single core CPU). My last encode was a 2 hour movie. Sampling took a little under 12 minutes, and the actual encode took 8 hours and 10 minutes. This translates to about 2.5% for the sampling phase which is excellent in my book. Remember that for the normal prediction phase you need at least 4 to 5 sample passes to get a useable result.

I did notice a slight speed difference between the two beta versions. Generally the older beta was a little faster than the current one. Not only during the sample phase, the main difference was during the actual encode where the current beta was about 10% slower than the older one.

A happy new year to everyone,

Cheers
manolito

[blutach]

Thanks Hank and Happy New Year!

Regards

[Dark Shikari]

Here's a feature suggestion: make an "auto" intraVLC option (like direct auto in x264) that simply tries both during the first pass and then chooses the best for the second.

If that costs too much speed, just take a random sampling of intra blocks (maybe 1% of them) during the first pass to try both on.

[MrC]

These were my testings in early december, comparing current AVStoDVD 1-pass OPV routine (5% CQ prediction) with new HCenc 1-pass VBR (CPU used is a good old fashioned AMD Athlon XP 1800+):

Sample 1 (short time and bad quality clip):
Video: E:\Movies\Test\video.flv
Info: Sorenson H263 - 328 kbps - 320x152 - DAR 2.105 - 24 fps - - 2:29 minutes - 3585 frames

*MAXBITRATE 9000
*BITRATE 4199
*1PASS
*PROFILE BEST
*ASPECT 16:9
*PROGRESSIVE
*BIAS 40
*DC_PREC 9
*MATRIX MPEG
*AQ 1
*LUMGAIN 0


OPV oversize: +31%
OPV tot encoding time: 242 s
VBR oversize: +17%
VBR tot encoding time: 243 s

Sample 2 (medium time and good quality clip):
Video: E:\Movies\video.avi
Info: XviD - 2000 kbps - 720x576 - DAR 1.25 - 25 fps - PPF - 12:11 minutes - 18283 frames

*MAXBITRATE 9000
*BITRATE 4398
*1PASS
*PROFILE BEST
*ASPECT 4:3
*PROGRESSIVE
*BIAS 40
*DC_PREC 9
*MATRIX MPEG
*AQ 1
*LUMGAIN 0


OPV downsize: -4%
OPV tot encoding time: 1427 s
VBR downsize: 0% :eek::cool:
VBR tot encoding time: 1800 s

Surely encoding time depends from a lot of factors (source clip type, CQ prediction passes number, etc.), but I was surprised that new HCenc sampling pass has been a little "long" in sample #2.

I have to admit that I did not make any further tests with more recent betas. I will do.

BTW, I repeat, 1-pass is really impressive for both quality and size accuracy. When hank will be confident enough about it, I will surely adopt it into AVStoDVD.

;)

Bye

[hank315]

My only concern was the "small" predictive routine timings: faster than a standard 1st pass but slower than a 10% OPV (constant quantization).
The prediction stage isn't multi-threaded ATM, in the final release it will be multi-threaded so higher speeds can be expected.

The only issues I found are the same as in the older beta: A slight stability issue when exiting the encoder during the second stage of the sampling phase (sometimes HC just freezes), and the command line parameters "-1pass" and "-2pass" are not implemented yet.
ATM the whole 1pass VBR prediction is only one thread with minimal error handling, still beta :)
Command Line parameters -1pass and -2pass are implemented but I never tested it...

Here's a feature suggestion: make an "auto" intraVLC option (like direct auto in x264) that simply tries both during the first pass and then chooses the best for the second.

If that costs too much speed, just take a random sampling of intra blocks (maybe 1% of them) during the first pass to try both on.
I also think it's needed to do both because there's no way to predict which VLC is optimal, a complete frame has to be done twice to see which table produces the smallest code.
But probably it's better to do it in the final pass only because the optimum highly depends on the fill rate (runs/levels) of the intra 8x8 blocks.
The first pass is always done with Q=4, Q in the last pass depends on chosen bitrate etc. so there can be a large difference in the nr of runs for pass1 vs pass2.


For those interested, some technical info:
MPEG2 has 2 options for VLC (Variable Length Coding) of intra blocks, it can use 2 tables for coding the DCT coefficients
If the fill rate per block is high, VLC using table15 is more efficient but the overhead is larger because the EOB (EndOfBlock) code is 4 bits for table15 and only 2 bits for table14.
An optimal encode can be done because the VLC table can be changed every frame, it's marked by a flag in the picture extension header.

[Dark Shikari]

I also think it's needed to do both because there's no way to predict which VLC is optimal, a complete frame has to be done twice to see which table produces the smallest code.
But probably it's better to do it in the final pass only because the optimum highly depends on the fill rate (runs/levels) of the intra 8x8 blocks.
The first pass is always done with Q=4, Q in the last pass depends on chosen bitrate etc. so there can be a large difference in the nr of runs for pass1 vs pass2.Then fix your first pass to be target-bitrate as well. It should give ratecontrol benefits in the second pass to have a first pass relatively near the bitrate of the second pass anyways, especially for lower bitrate encodes.For those interested, some technical info:
MPEG2 has 2 options for VLC (Variable Length Coding) of intra blocks, it can use 2 tables for coding the DCT coefficients
If the fill rate per block is high, VLC using table15 is more efficient but the overhead is larger because the EOB (EndOfBlock) code is 4 bits for table15 and only 2 bits for table14.
An optimal encode can be done because the VLC table can be changed every frame, it's marked by a flag in the picture extension header.In which case this really is exactly like --direct auto in x264, as direct mode is a flag that can be changed per-frame as well.

You could borrow x264's method of doing it in 1pass--simply keep a moving average of the mode scores and pick whatever one has been best in recent frames. For intra VLC, this should be even more accurate than for direct auto in x264.

[Smetvid]

WOW! thanks a lot for the 4:2:2 encoding. I used to use Main Concept for 4:2:2 material for editing masters and recently I started using FFMPEG but that was kind of a pain. For me HCenc has been an awesome encoder but I was always missing the option of encoding 4:2:2 material. I encode a lot of 150 mbit 4:2:2 I frame only material for HD editing systems.

I will try it out this weekend but I'm sure HCenc will now be able to do everything I ever wanted in a encoder.

[Chumbo]

I tested the issue reported in the HCEnc 023 thread and it still crashes. The issue I'm referring to is referenced here (http://forum.doom9.org/showthread.php?p=1228612#post1228612), here (http://forum.doom9.org/showthread.php?p=1228941#post1228941) and here (http://forum.doom9.org/showthread.php?p=1229102#post1229102).

[Trahald]

@Chumbo
You cant delete them since people have replied to it so there would be a confusing gap. You should edit your post above to only have the links to the original posts. not full quotes.

[Gromozeka]

hank315
Its the great coder :thanks:
May be you add trellis quantization and GOP>36?

[Chumbo]

@Chumbo
You cant delete them since people have replied to it so there would be a confusing gap. You should edit your post above to only have the links to the original posts. not full quotes.
Thank you. I updated the post above.

[manolito]

Command Line parameters -1pass and -2pass are implemented but I never tested it...
Just retested both beta versions I have - these command line parameters are ignored...

Cheers
manolito

[hank315]

@manolito
OK, will check it out, will be fixed in the final 024 release.
Thanks for the report...

[fjhdavid]

Dear Hank, (I already post this message in the HC encoder thread, but I think it is better here)

as you maybe read in the DVD-RB 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 and I am using multiple encoder (2) and (4) setting in DVD-RB)

is it possible to improve HC encoder in this way? (but maybe it is inherent to the processor architecture)?

[Fishman0919]

Dear Hank, (I already post this message in the HC encoder thread, but I think it is better here)

as you maybe read in the DVD-RB 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 and I am using multiple encoder (2) and (4) setting in DVD-RB)

is it possible to improve HC encoder in this way? (but maybe it is inherent to the processor architecture)?


My quadcore is much faster then my dualcore with HC and DVD-RB.

My AMD Athlon 64 X2 5400+ 2.8GHz dualcore takes about 50-55 mins to encode The Hulk DVD Full disc.

My AMD Phenom 9950 BLACK EDITION 2.6GHz takes about 30 min's.

[fjhdavid]

my laptop is an intel dual core2 duo 2.1Ghz (45nm) and typical speed with my script is : 11fps (multiple encoder(2))
my PC is an intel quad core2 duo 2.5Ghz (45nm) and typical speed with my script is : 8.5fps (multiple encoder(4))

as you can see and if you take into account speed processor, it is nearly 35% less for my quadcore !

and if I use only 2 core with my quad, I still have 8.5fps !

and seems that my quad is waiting something ...both computers are under window Vista and have 4GB RAM with big hardrive and no other software like antispy...

I use also "lossless file" and "best" settings for HC encoder 0.23

PS: I tested HC encoder 0.24 beta and it is the same results and problem

[hank315]

my PC is an intel quad core2 duo 2.5Ghz (45nm) and typical speed with my script is : 8.5fps (multiple encoder(4))
That must be a *very* slow script...
My PC is an Intel quad core (Q9450 2.66 Ghz), typical encoding speed 200-250 fps using DVD-RB.

Please dump the *LOSSLESS parameter, using 4 instances of HCenc also means you have to maintain 4 very IO intensive operations which will slow down speed, especially using Vista.

[fjhdavid]

yes, I use fft3Dfilter for denoising and sharpen! (slow but as you know wonderful)

But, I did a re-encoding without the script and without the "lossless" and I have (PAL film 704x576):

125fps with my dual core
and 120fps with my quad (compare to your 200-250fps)!!! My quad is a Q9300.

as you see, there is a problem with my quad!

Hank, do you have any idea?

PS: with HC 0.24, the first 30 minutes of my black and white PAL movie was ok, but the end of the film was black and green.... (with HC 0.23, all the film is of course fine). Hope this will help.

[Fishman0919]

my laptop is an intel dual core2 duo 2.1Ghz (45nm) and typical speed with my script is : 11fps (multiple encoder(2))
my PC is an intel quad core2 duo 2.5Ghz (45nm) and typical speed with my script is : 8.5fps (multiple encoder(4))

as you can see and if you take into account speed processor, it is nearly 35% less for my quadcore !

and if I use only 2 core with my quad, I still have 8.5fps !

and seems that my quad is waiting something ...both computers are under window Vista and have 4GB RAM with big hardrive and no other software like antispy...

I use also "lossless file" and "best" settings for HC encoder 0.23

PS: I tested HC encoder 0.24 beta and it is the same results and problem

AMD 9950 OC'ed to 2.8ghz Redistributing (http://i467.photobucket.com/albums/rr37/fishman0919/QuadcorePredict.jpg)
AMD 9950 OC'ed to 2.8ghz Encoding (http://i467.photobucket.com/albums/rr37/fishman0919/QuadcoreEncode.jpg)

AMD 5400+ at 2.8ghz Redistributing (http://i467.photobucket.com/albums/rr37/fishman0919/DualcorePre.jpg)
AMD 5400+ at 2.8ghz Encoding (http://i467.photobucket.com/albums/rr37/fishman0919/Dualcoreencoding.jpg)

You must has something else going on for it to be that slow.

[halsboss]

But, I did a re-encoding without the script and without the "lossless" and I have (PAL film 704x576):

125fps with my dual core
and 120fps with my quad (compare to your 200-250fps)!!! My quad is a Q9300.


Wow!!!! I have a stock 4-core Q9450/4Gb/2Disk/nvidia8800GT (& Trend anti-virus) and still never ever get above about 60-80fps with xvid avi input and latest ffdshow codecs and setMTmode specifying 4 threads. I'd be happy with your speeds, let alone hank's or Fishman0919 which appear amazing to me.

Would it be possible to post a sample clip somewhere, your HC's .ini and .avs script so that I can try it out and compare ?

If there's a standard "test suite" and comparative timings for this somewhere then could someone please provide a link ?

Thanks.

[Chumbo]

@hank,
Just a few "wish list" items if you have time to add:
- create a path if it doesn't exist as in the case of the dbpath or lossless file when configured directly in the ini file
- when multiple encodes are going, it would be nice if HC recognizes the lossless file is there and seializes the next one or like you do with the db now. I know we don't want to run too many lossless operations due to the IO intensity, but in the case of two, it would be nice.

Thanks for your consideration.

[EDIT] On the 2nd bullet above, personally, I use two different physical drives, so I don't have that issue. I'm curious how it performs when there are two lossless files on a RAID system during the 2nd pass. I was curious, so I tested it on a single drive and even 2 bring processing to its knees.

[fjhdavid]

I think there is still something strange in the way that "multiple encoders process is handled" with quadcore.

let me explain:

I use hc encoder in "best" setting with "no lossless" parameters and I encoded a PAL 704x576 25fps film.
I disabled avisynth and filters

With a dualcore2 at 2.1ghz I have : 2x36fps = 72fps
With a quadcore2 at 2.5ghz I have : 4x25fps = 100 fps

but more important for Hank, with dualcore it is almost linear if I use one core or 2 cores (I played with the boot.ini of XP to choose one or two cores)

for the quadcore there is a bootleneck somewhere, as:

with two cores I have: 2x50fps = 100fps
with three cores I have: 3x33fps = 99fps
with four cores I have: 4x25fps = 100fps

where does it come? I have no others software installed

If I use avisynth, results in fps are lower of course but the bottleneck is almost identical with the quadcore. In this case quadcore is even slower than the dualcore!!!!
my two cents.

EDIT: the only difference is that my quadcore has "single channel" memory and the dualcore has "dual channel" memory, could it be the reason?

[Fishman0919]

the only difference is that my quadcore has "single channel" memory and the dualcore has "dual channel" memory, could it be the reason?

Again, look at my pic's.

My Dual core is encoding 2 instances of HC at about 45 fps. with ddr2 800 mem.

My Quadcore is encoding 4 instances at about 55 fps. with ddr2 1066 mem.

Both cpu are running at 2.8ghz.

Something is going on funny with your quadcore.

[halsboss]

I'd like to know what your avisynth scripts are actually doing - if they're "passthrough" I'd expect to be quicker than my resizing/resharpening script fps, however if they do similar things then I too will know my q9450 4-core is slower than it should be. What anti-virus do you run and is it configured to intercept/examine everything ?

[fjhdavid]

I do a bicubicresize (Mitchell-Netravali variant)
I do several color and luminosity tweaking

but 90% of the coomputational time is done with a filtering in the frequency domain (denoising and sharpening) with the fft3dfilter.

I use the same script with my dual and quad, and have the same antivirus on both. I did the test without the antivir, and results are identical.

As the speed is very slow in term of fps, I think there is no bottleneck with I/O.

[halsboss]

do you mind posting your actual script and a test clip ?

[fjhdavid]

here is my script:

-------------------------------------------------------
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\FFT3DFilter.dll")
Crop(0,72,0,-72)
ColorYUV(off_y=15)
ConvertToRGB(interlaced=true)
RGBAdjust(1,0.96,1,1,0,1,2,0,1,1,1,1)
BicubicResize(704,576)
ConvertToYV12()
ColorYUV(gain_y=15)
FFT3DFilter(sigma=3,bt=3,bw=32,bh=32,ow=16,oh=16,plane=3)
FFT3DFilter(sigma=1.5,bt=3,bw=32,bh=32,ow=16,oh=16,sharpen=0.7,plane=0)
---------------------------------------------------------

IMPORTANT:

you have to put the file : fftw3.dll in the \windows\system32 folder (it is a mathematic library you need in order to use fft3dfilter)

but the file is too big (381kb), I can send it to you by mail?


you have to put the file (attached file): FFT3DFilter.dll in the "plugins folder" of avisynth

---------------------------------------------------------

you can use any video clip, but mine is a PAL 704x576, so maybe the best will be for you to use a 704x480 (NTSC) but put BicubicResize(704,480)!

I choose HC encoder with BEST settings, GOP=auto and DC=10

------------------------------------------------------------

I use standard PAL clip but you can use the clip you want (even NTSC)

[halsboss]

eek, ive been told never resize an interlaced clip like that with a plain resize. all the other best settings in the world will not help with that. is it upsizing or downsizing ? i thnk you need to denoise before resizing too. sorry for the offtopic. i'm pal too.

[fjhdavid]

you are absolutly right, but:

my films are PAL film progressive (frame based and Y progressive) but interlaced coded for colors component only (U and V), so interlaced=true and the resize is ok in this case.

the denoising could be done before or after (usually you do it before to save computing time as you crop before and because it is spatially better), but in my case, denoise and sharpen are frequencies filtered and have to be done together at the end (for sharpen efficiency) and if I want to do only one FFT transforms....which is very math intensive....

but If I had a core i7 I would do it separatly: "before for denoising" and "after for sharpening" !

dowload the math library directly from here:

ftp://ftp.fftw.org/pub/fftw/fftw3win32mingw.zip

and you have to put the file : fftw3.dll in the \windows\system32 folder


tell me your results as soon as you can!

[halsboss]

I have those already. Post a 2-minute clip of your source so we can compare like for like, script and source and timings; doing otherwise is leaves too many variables, eg I'd never realistically compare your script to any of mine. Do you have the MT version of anyisynth installed ?

[stenews]

Hi to every gurus that are posting over this thread,
first off I have to said that I'm not so good as you in those kind of things, but I'm absolutely fascinated to learn about that.

I read how fjhdavid is using fft3Dfilter to encode with Hcenc.
What I'd like to know is if it's something to use with DVD-RB or with d2s too?
In case, cloud someone explain be better how to set-up those applications for that?
I'm already using all that but for AviSinth script and other things like that I need a step by step help.

Hope someone would help me in learning those procedures.
Bye,
Stefano. :p

[fjhdavid]

Halsboss, here is the link to my clip:

http://www.megafileupload.com/en/file/82334/VTS-01-1-VOB.html


Stenews,

you can use avisynth filters with dvd-rb but in order to understand how to use it, I invite you to visit the avisynth.org site or doom9 forum. You will find "newbie" manual.

[stenews]

Thanks fjhdavid,
could you post me the doom's link where I can find those kind of explanations?
I'm not finding it at moment...

bye and thanks again!:)
Stefano.

[jeffy]

@fjhdavid: Did you try VirtualDub - File->Run video analysis pass? How fast is it? Maybe you are feeding the frames too slow :confused:

You might try MT("FFT3DFilter(sigma=3,bt=3,bw=32,bh=32,ow=16,oh=16,plane=3)",4)
MT("FFT3DFilter(sigma=1.5,bt=3,bw=32,bh=32,ow=16,oh=16,sharpen=0.7,plane=0)",4)

[fjhdavid]

yes I tested with MT. Same bottleneck.

I am waiting for halsboss and maybe you if you have time to do the test.

If you have the same fps I got, I think quad is scaling worse than dualcore (the reason could be the L2 cache which was designed for dualcore access...I read a very intresting article about that, and they say that the new core i7 has been built, him, with quadcore and cache acces in mind....).

But if you have better results, my system (or me) is faulty....

[Konrad Klar]

I think there is still something strange in the way that "multiple encoders process is handled" with quadcore.

let me explain:

I use hc encoder in "best" setting with "no lossless" parameters and I encoded a PAL 704x576 25fps film.
I disabled avisynth and filters

With a dualcore2 at 2.1ghz I have : 2x36fps = 72fps
With a quadcore2 at 2.5ghz I have : 4x25fps = 100 fps

but more important for Hank, with dualcore it is almost linear if I use one core or 2 cores (I played with the boot.ini of XP to choose one or two cores)

for the quadcore there is a bootleneck somewhere, as:

with two cores I have: 2x50fps = 100fps
with three cores I have: 3x33fps = 99fps
with four cores I have: 4x25fps = 100fps

where does it come? I have no others software installed

If I use avisynth, results in fps are lower of course but the bottleneck is almost identical with the quadcore. In this case quadcore is even slower than the dualcore!!!!
my two cents.

EDIT: the only difference is that my quadcore has "single channel" memory and the dualcore has "dual channel" memory, could it be the reason?

Maybe it is related to the fact that C2Quads have two seperate caches L2, one per each of pair of their cores and no L3 cache (for all cores).
So if some data are accessed/processed at the same time by cores from different pairs (with separate cache) that data cannot be cached at all and must be readed/written directly from/to RAM.

It would explain why Phenoms (and presumably Nehalems) are not affected by this issue (or less affected - L3 is slower than L2).

I don't know internals of HC's code, so I may be wrong on this.

[halsboss]

downloading the clip now. it's a vob.

Please post your full script including the source statement etc, and outline any pre-processing you do with versions (eg dgindex).
Also post your full HC.INI and full HC commandline and state which version of HC.

it may well not be HC.

wow Konrad likes frying chips and using half installed memory if he's an XP32'er !GA-EP35C-DS3R, Core2Quad Q6600 2400@3160MHz, 7.0GB/800 MHz DDR2, 2x500GB SATA RAID0, Radeon X1050 128MB, 22x DVD-RAM SATA :D

[Konrad Klar]

Konrad is 64'er :)

[halsboss]

Lucky devil. I'm not smart enough (read: too lazy) to get into that. And too cheap. Not enough of the progs I use are 64-bit - mainly avisynth and "legacy" related editors etc. Anyway, given the dribs of info supplied to date, I'm unconvinced in the interim it's HC.

[fjhdavid]

Halsboss,

I just enter the avisynth script, as it is and as I gave you, in the DVD-RB "Options" and "Filter editor".

I have no other software installed, or dgindex pre-proc. I use ONLY DVD-RB Pro 1.28 (with the dginex included) and avisynth 2.57 and FFT3Dfilter as I told you.

I use the .VOB clip I gave you as it is.

You will find attached my rebuilder.ini

Now, you have everything I have.
I use HC 0.23.

The explainations of Konrad about the Quad Cache is absolutly right, I read it already on technical forum and can explain why, under some circumstances, dualcore are faster than quadcore. About HC tweaking, I don't know but maybe it could be looked at by Hank.

[halsboss]

Ah, more dribs and drabs of info. DVD-RB, now, is it ?

Now, you have everything I have.No, in fact I don't.


LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\FFT3DFilter.dll")
Crop(0,72,0,-72)
ColorYUV(off_y=15)
ConvertToRGB(interlaced=true)
RGBAdjust(1,0.96,1,1,0,1,2,0,1,1,1,1)
BicubicResize(704,576)
ConvertToYV12()
ColorYUV(gain_y=15)
FFT3DFilter(sigma=3,bt=3,bw=32,bh=32,ow=16,oh=16,plane=3)
FFT3DFilter(sigma=1.5,bt=3,bw=32,bh=32,ow=16,oh=16,sharpen=0.7,plane=0)

I wondered why you had no source statement. I can't replicate yor setup (no DVD-DB) as I don't know anything about that application such as how it inserts the vob source in avisynth or what else it does. Maybe someone else can test it for you.

[tin3tin]

A nice HCenc feature would be to check before rendering, if there is enough free harddiskspace for the resulting file and throw a warning if there isn't. And maybe also a warning if there is too little RAM on the computer.

[mikenadia]

It seems that if in the avs file I enlarge too much (width above 1920: I know this is above specs !) , I have a windows XP error message (MPEG2 needs too close), I have an info message: HC.ini loaded; avisynth.dll loaded...

[hank315]

The maximum resolution HCenc can handle is 1920x1152, this is according to the first MPEG2 specification.
ATM the check for it in the GUI fails causing the crash, fixed now, thanks for the report.

[Chumbo]

I'd like to submit a feature request please. With titles like The Dark Knight and Transformers 2 released in a "hybrid" format, i.e., both IMAX and letterbox, I'm sure more titles will follow. The problem this presents, when encoding to DVD, is we can't really use one setting for the top/bottom for cropping on these titles without breaking every section up and encoding it separately.

I'm wondering if it's possible to add a similar section for cropping that is now available for Preview/Zones, for example. In this area we can add crop and shift info based on the frames. This would be a tremendous feature. Thank you for considering it.

[~Revolution~]

Is there a guide to describe the most beneficial "usage scenarios" for all of the built-in matrices in HCenc? Also if someone can point me to a guide about matrices and how they specifically work I would appreciate it :)

[mikenadia]

http://forum.doom9.org/showthread.php?t=133470 (posts 7 to 10)

[~Revolution~]

http://forum.doom9.org/showthread.php?t=133470 (posts 7 to 10)

Thanks! :)

[cweb]

I tested the issue reported in the HCEnc 023 thread and it still crashes. The issue I'm referring to is referenced here (http://forum.doom9.org/showthread.php?p=1228612#post1228612), here (http://forum.doom9.org/showthread.php?p=1228941#post1228941) and here (http://forum.doom9.org/showthread.php?p=1229102#post1229102).

I have this issue too when I use dgmultisource From the latest dgindexnv with hc encoder beta 24. Version 23 works for me so I'm switching back to that.

[Sharc]

Source is interlaced cptured *.avi, 25 fps = 50 fields per second at half hight.
Encoding with HCenc 0.24 set to 'interlaced' produces 2 identical (possibly blended) fields@50 fields per second when analyzing the encoded .m2v with SeparateFields(). I would have expected to get 2 different fields like in the original. Do I get something wrong?

[dansrfe]

When I encode progressive content, should I set it to top field (If I choose auto as the mode and Top Field First) or bottom field? Also, should I set DGPulldown to the same setting as used for HCEnc or it doesn't matter? As a matter of fact I'm not even sure if the "field" setting in HCEnc or DGPulldown matter for progressive material.

[dansrfe]

Anyone? :o

[AVIL]

Hi,

I`ve never used DGPulldown but IMHO in progressive footage, the field indicator is irrelevant. In HCENC's interlacing options (Settings 1 tab) you check the progressive hole and field indicators are automatically greyed and (very probably) ignored.

[dansrfe]

How can I run pass 1 and pass 2 separately? I want to be able to do pass 1 then start pass 2 after a restart of my computer.

[hank315]

It's not possible, there's a lot of intermediate data which only resides in memory so pass 1 and 2 have to be done in one run.

[dansrfe]

I'm just curious but is the avs file needed for the second pass in HCenc or does it just load that from memory? For that matter what about x264 and XviD second passes? Thanks.

[hank315]

I'm just curious but is the avs file needed for the second pass in HCenc or does it just load that from memory? For that matter what about x264 and XviD second passes? Thanks.
Avisynth will invoke the script again at the start of the HCenc second pass. I don't know how x264 and Xvid handle the second pass.



New HC024 beta, 31-07-2010.

- bug fixed using lossless mode
- minimum autogop size set to 8
- some small GUI changes

download here (http://hank315.nl/files/HC024_beta_31-07-2010.zip)

[mikenadia]

Thanks a lot hank315 for the new beta.
.
HC seems to have scene change on by default and to have scene change off, we just put NOSCD in the Ini file. Is it possible to have the ability to put scene change on in the Ini file. I am using Rb-opt that during some sampling phase is sending the NOSCD instruction to HC and I would like to have the possibility to overwrite it.

I was wondering if the scene change detection system could have different settings (strong...) or if it was not efficient enough because if in the avs file, I have SelectRangeEvery (250,13) with Autogop 13 in the ini file, I was expecting to have always GOP 13 * Closed and some are open . Same thing if I put autogop 15, most of them are GOP 13 * closed but I have some GOP 15 * and GOP 11 * Open.
I know I will just put GOP 13 2 but it was just a thought.
The likelihood that there is no SCD every 13 frames is low.

Thanks a lot.

[manolito]

HC seems to have scene change on by default and to have scene change off, we just put NOSCD in the Ini file. Is it possible to have the ability to put scene change on in the Ini file. I am using Rb-opt that during some sampling phase is sending the NOSCD instruction to HC and I would like to have the possibility to overwrite it.
I believe that this would be a bad idea. The concept behind HC's interface is that a setting passed via command line will ALWAYS override a setting in the INI file. I would hate to see this consistency disappear...

Cheers
manolito

[mikenadia]

From Hank315:
Avisynth will invoke the script again at the start of the HCenc second pass. I don't know how x264 and Xvid handle the second pass.

Even in lossless mode?

@manolito : no problem!

[Boulder]

- minimum autogop size set to 8Thanks :)

[manolito]

@mikenadia
I am using Rb-opt that during some sampling phase is sending the NOSCD instruction to HC and I would like to have the possibility to overwrite it
If you want to take control over the command line parameters passed to HC by some other software (like RBOpt) you can use a small wrapper script (a simple batch file will do) to filter the command line parameters.

The following batch file will discard any -scene and -noscene parameters passed to HC. Save it to a file like HC_mod.bat to your HC folder and instruct RBOpt to use this batch file instead of HCenc.exe

@ECHO Off
SET HC_DRIVE=%~d0
SET HC_PATH=%~p0
SET CMDLINE=

%HC_DRIVE%
CD "%HC_PATH%"
IF NOT EXIST HCenc.exe COPY /b HCenc*.exe HCenc.exe >NUL

:assemble
IF !%1==! GOTO doit
IF NOT %1==-scene IF NOT %1==-noscene SET CMDLINE=%CMDLINE% %1
SHIFT
GOTO assemble

:doit
HCenc.exe%CMDLINE%
Note: This batch file assumes that your HC executable is HCenc.exe. If it does not find a file with this name it will rename any file with the filespec HCenc_xxx.exe to HCenc.exe.

Cheers
manolito

[mikenadia]

Thanks a lot, Manolito. I was already using the wrapper HCwrap from Darksoul ( hence my initial request : NOSCD in HCwrap.txt is working but SCD is not) and will use yours on top of that.

[Taurus]

Avisynth will invoke the script again at the start of the HCenc second pass. I don't know how x264 and Xvid handle the second pass.



New HC024 beta, 31-07-2010.

- bug fixed using lossless mode
- minimum autogop size set to 8
- some small GUI changes

download here (http://hank315.nl/files/HC024_beta_31-07-2010.zip)
Just to mention: :confused:
7 out of 42 Virusscanners at virustotal.com are detecting the new beta as a virus.
Filesize of the older version 2MB, new version only 438KB.
Same for the SSE4 version.
Is this packer related?
Dont have the time to analyze and investigate.

[manolito]

@mikenadia
HCWrap is very nice, but in your case this approach cannot work. HCWrap modifies the INI file for HC, but if the calling application issues a command line parameter to HC, this will always override any setting in the INI file.

You need a wrapper which sits between the calling application and HCenc.exe and modifies the command line parameters (not the INI file).

My batch script approach is a littly clumsy, but it works well, and it cannot only kill parameters from the command line, it can also replace parameters.

Example:
IF %1==-hq SET CMDLINE=%CMDLINE% -profile best
I need this when I use HC inside DVD2SVCD which only supports QuEnc.

The only cosmetic flaw using this method is that there is no way to hide the console window which pops up when a batch file is executed. Solution: Compile the batch file using Quck Batch File Compiler by Abyssmedia in "Ghost Application" mode.
(There is an older version of this app where they forgot to activate the shareware nag screen in ghost mode... PM me if you are interested)

Cheers
Manolito

[manolito]

@Taurus,
Yes, this is packer related. The current beta is packed with MPress, and the AV companies are still too ignorant. You probably remember when they would tag any file packed with UPX or even any AutoIt executable. Bottom line here:
FALSE ALARM

The only thing which bugs me is that MPress does not have an unpack option (contrary to UPX). Hank probably got annoyed with people like me who have the habit to explore EXE files with a hex editor to find undocumented commands...:devil:


Cheers
manolito

[Taurus]

@manolito
Thanks for clarification.
I noticed Mpress, but wasn't sure about its features :p

[hank315]

From Hank315:
Avisynth will invoke the script again at the start of the HCenc second pass. I don't know how x264 and Xvid handle the second pass.

Even in lossless mode?
Yes it still does that when lossless is active although there's no real need for it, will dump it.


About the new exe files, they are packed with Mpress 2.15 and I checked it with Avast Anti Virus which I use, no problem.

The only thing which bugs me is that MPress does not have an unpack option (contrary to UPX). Hank probably got annoyed with people like me who have the habit to explore EXE files with a hex editor to find undocumented commands...:devil:
LOL...:rolleyes: the files are just smaller but if it's a problem I will upload it again unpacked.
I kind of like the fact it can't be unpacked, it's also a (weak) protection against reverse engineering :)

[manolito]

:):):):):)

Did a few encodes with the new beta in 1-pass VBR mode, all is good...
But this small issue is still there: http://forum.doom9.org/showthread.php?p=1408705#post1408705


Cheers
manolito

[tin3tin]

Avira has no problems with the gui version, but the non gui version is causing a false positive and the file is locked up making it unuseable. :(

I wonder why - are they packed differently?

[hank315]

First of all a small bug report for HC 0.24 beta 04-04-2010:
In 1-pass VBR mode the HC log file always reports an average quantizer which is too small by a factor of 10 (0.400 instead of 4.00). Haven't tested it in 2-pass VBR.
I can't repeat this, somebody who can?

@tin3tin
All files were compressed using the same settings.
Seems this doesn't work for everyone, the AV companies should do a better job :devil:
Will update it soon, unpacked.

[manolito]

Just double-checked this again, but only in 1-pass VBR. Here's the log:

---------------------------------------
| HCenc - MPEG2 encoder - rel. 0.24.0 |
---------------------------------------

MPEG profile@level: MP@ML
input: I:\Movies\AviSynth_Script_file.avs
output: I:\Movies\Encoded_Video_QuEnc_PAL.mpv

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

profile: FAST
frames: 0 - 174924
framerate: 25.000
aspect ratio: 16:9
chroma format: 4:2:0
bitrate Kb/s: 4784
max. bitrate Kb/s: 8500
pass: 1 (VBR)
pulldown: no
closed gops: no
VBV check: yes
scene change det: yes
interlaced: auto, TFF
goplen,B-pic: AUTO
dc_precision: 10
intraVLC: auto
scan method: auto
bias: 30
chapter frames: 0
time code: 0 0 0 0
CPU: MMX
priority: idle
SMP active: no
matrix: CUSTOM, adaptive
luminance gain: yes, level 2
adaptive quantization: yes, strength 2
deadzone quantization: auto

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

nr. of frames in source: 174925
width*height: 720x576
fps: 25.000
nr. of frames to encode: 174925
frames to encode: 0 - 174924

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

pass 1 encoding time: 4:05:33 (14733.12 s)
fps: 11.9

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


adapted intra matrix used
adapted non-intra matrix used

nr. of gops: 12332
nr. of frames: 174925
nr. of I-frames: 12332
nr. of P-frames: 48942
nr. of B-frames: 113651
average bitrate: 4787
minimum bitrate: 148
maximum bitrate: 8499

bytes in bitstream: 4188556128
bits in bitstream: 33508449024

average Quantizer: 0.608

total CPU time: 4:15:29 (15329.12 s)
total elapsed time: 4:19:13 (15552.74 s)

Base Q determined in stage 1 of the sampling phase was 5.47, so an average quantizer of 6.08 makes sense.

Cheers
manolito

[mikenadia]

Cosmetics.
It seems that Hc crashes (failed to successfully initialize avisynth )
when the last line of the avs is a LoadPlungin( ).
If I put a command (Trim, convert,filter...) after that, everything is fine (those avs generated automatically :)).
I did not try with another encoder ; it may not be HC issue.

Thanks.

Explanation in post 2 of http://doom10.org/index.php?topic=452.0

Edit:
@um3k;
That is why I said " cosmetics". Those avs files are generated automatically by Rb-opt when sample size= 100% and I cannot intercept them to edit them ( I can do it after the crash, but not patient enough to do it 20 times in a row!). In this particular case, I'd rather have sample size less than 100% so that the last line of the avs file is "SelectRangeEvery".
Rb-opt , in its prediction phase, is taking an avs script generated by DVD-RB ( which begins by Loadplugin and mpeg2source) and is adding after that, its own LoadPlugin and SelectRangeEvery (only if sample size is less than 100%). Hence, the issue and its solution. It was just a curiosity.:)


@hank315
May be put in the log autogop 12 instead of auto.
Thanks.

[um3k]

Why not just put the source filter after the LoadPlugin calls? That's the usual way to do it.

[hank315]

New HC024 beta.

It's pretty much the same as the 31-07-2010 release, files are not packed.

The bug reported by manolito about the logged 1pass VBR Quant value is fixed.

download here (http://hank315.nl/files/HC024_beta_05-08-2010.zip)

[Guest]

Any chance to answer the question I asked you in PM? Thank you.

[tin3tin]

No complains from Avira anymore. :)

However the non-gui version still crashes for me in the end of the first pass(at 50%) like all the previous 0.24 betas.

Same thing if I use the default hc.ini.

In the error details it says that it is somehow connected to 'ntdll.dll'.

I think I've already send you the avisynth script, which is the script from DVD slideshow GUI. If not here's a script which makes HCenc crash for me:
http://download.videohelp.com/tin2tin/crash.avs (http://download.videohelp.com/tin2tin/crash.avs)

Can anyone else confirm this bug?

[Guest]

Can anyone else confirm this bug? I don't know if it is the same bug but I too get crashes. I've notified Hank and provided details of a possible cause and patiently await his response.

[Boulder]

I think I had similar crashes a long time ago with HC023. I never found out the cause though.

[video_magic]

If it's crashing at the end of the 1st pass, have you guys tried using the *AVSRELOAD command?

If that doesn't work then sometimes *LOSSLESS


....
However the non-gui version still crashes for me in the end of the first pass(at 50%) like all the previous 0.24 betas.

Same thing if I use the default hc.ini.

In the error details it says that it is somehow connected to 'ntdll.dll'.
..... ...

[tin3tin]

If it's crashing at the end of the 1st pass, have you guys tried using the *AVSRELOAD command?

If that doesn't work then sometimes *LOSSLESS
*AVSRELOAD = crash.
*LOSSLESS = no crash.
... however it would be nice to render without hogging up the harddisk with a huge temp file(potentially running out of hhd space during render etc. DVD slideshow GUI uses HCenc to render).

[video_magic]

It seems that you problem is that the 2nd-pass decode of your source is not bit-identical with the 1st-pass decode.

That is why *LOSSLESS worked for you, because it used the same file already decoded from the first pass (so guaranteed to be the same).

So you need to look at what decoders and decoder settings are being used on your source which you are feeding to HCEnc; something to definitely try is:

Not using multi-threading decoding. Either turn off that setting, and/or also try a different decoder if possible.

Avoid Directshow decoding - is there another way of feeding in your sourcefile? There are usually alternatives available.

[Mr. Monte]

Would also like an unpacked version.

Over here in Kuwait..the filtering is blocking

Had my wife in the states try to download it..got the file..but Google will not allow it to be attached to an email to send it to me. Even if I rename it

Thanks

[hank315]

Here's another build (http://hank315.nl/files/HC024_beta_09-08-2010.zip), the way Avisynth is used has been updated.
Many thanks to neuron2 for his help on this.

It might solve some of the mentioned crash issues but still beta...

Note: files are NOT packed.

[Guest]

For use with DGDecNV please use build 2024. Hank and I have coordinated our efforts to make a crash-free result. Please report if you still see any crashes with these two versions of the software. Of course, also report if you see crashes with HCEnc using other source filters.

(There are some rare instances of HCEnc hanging before starting the encoding, but it is reproducible with different source filters, so it is not attributable to DGNV. Hank has duplicated it and is investigating.)

Thanks for your efforts to resolve these issues, Hank!

[tin3tin]

It seems that the 50% bug(1.pass) bug has been fixed. :)

[Guest]

Good news. Thank you for your testing.

[Mr. Monte]

For use with DGDecNV please use build 2024.

Neuron,

I do not see build 2024. I have the Beta build dated 09-08-2010...and when I clcik on the about HC it says 0.24.0

Is this the one? (BTW I am using the SSE3.exe)

TIA

[Revgen]

2024 is DGDecNV, NOT HCEnc.

[Mr. Monte]

Roger..thanks

[AGKnotUser]

I have tried to upgrade the version of HCenc from 0.23 to the more recent betas of 0.24. Any version past 12-29-2008 fails to run unexpectedly. It may run for one segment, it may run for 30 segments, but they all fail at some point. The error message is: ERROR, input not complete, required input: input file, output file, bitrate, maxbitrate. I'm running Win 7 Home Prem. 64 bit.

[soneca]

The same thing happens here with any beta version 0.24.
Use DVD Rebuilder + HCenc since version 0.17/18 and never had problems until now.

[hank315]

There are some rare instances of HCEnc hanging before starting the encoding, but it is reproducible with different source filters, so it is not attributable to DGNV. Hank has duplicated it and is investigating.
This should be solved now, I did about 30000 short encodes, no hangs anymore.

Download here (http://hank315.nl)

[Guest]

Thanks, Hank. I can no longer duplicate the hang with that build.

[soneca]

Now seems to be alright!
Could encode without crashes!:)

:thanks: Hank

[hank315]

Thanks for testing...
Nice to see a friday 13h build works OK :)

[Rumbah]

I cannot download the latest beta, could you please reupload it?

[hank315]

I just removed it, there are some things I have to check first regarding possible MPEGLA licensing liabilities.
The discussion here (http://forum.doom9.org/showthread.php?t=156287) also applies to HCenc.

[Brazil2]

I just removed it, there are some things I have to check first regarding possible MPEGLA licensing liabilities.
The discussion here (http://forum.doom9.org/showthread.php?t=156287) also applies to HCenc.
AKAIK it doesn't apply in Netherlands neither in most European countries.
That's even the reason why (http://forum.doom9.org/showthread.php?p=1427881#post1427881) the official site to download binaries of x264 is x264.nl (http://x264.nl).

[hank315]

Maybe not, but I'm not a laywer and I just want to be sure I'm not personally liable for this hobby project.
Also the rules for H.264 are different than the rules for H.262, neuron2 already removed the binaries of DGDecode from his site.
In the HCenc package are, apart from the encoder itself, 7 different versions of DGDecode...

I contacted MPEG LA about this, will report back when I have an answer.

[Guest]

In the HCenc package are, apart from the encoder itself, 7 different versions of DGDecode... If the patents cannot be enforced in NL, you could distribute my binaries as well as your own.

My ISP host is located in the US, so unless I change that, I cannot distribute my binaries via my web site.

Don't expect MPEGLA to properly advise you about the enforcability of their patents in foreign countries.

[Biggiesized]

Don't expect MPEGLA to properly advise you about the enforcability of their patents in foreign countries.

Bolded for effect. They're more than likely going to give you misinformation if you give them a ring.

[burfadel]

Any news on this?...

[hank315]

Any news on this?...
Yes: http://hank315.nl

[Guest]

Hank,

Thanks very much for the link to my binary for DGMPGDec! You should probably put a link to my web site right there with a source code offer, to comply with GPL.

And thanks for the release of HCEnc 24.

[hank315]

Hm, I thought the sources were also in the package.
Will solve it...

already done, site updated

[Guest]

Thank you. I have linked to your page at mine.

Also, maybe you'd like to change the thread title to remove "beta"? Hit Edit on your first post and then Go Advanced. You'll find an edit box for the thread title.

[Midzuki]

hank315 wrote:

For the final HC024: http://hank315.nl

Not a beta anymore? :devil:

Yeah, about time! :D

10^6 :thanks:

[tommy_vercetti]

Thanks for the good work!

[Boulder]

Thank you hank, it's nice to see an excellent program still being developed over the years :)

[Fishman0919]

Thank You much Hank!

[soneca]

Thank you!!!

[sneaker_ger]

I didn't follow all the discussion, but is there any consensus about field order etc. for progressive PAL content? I want to use the same settings as "professional" encoders like CCE use.

[burfadel]

Thanks! what about the link in your sig?

[MatLz]

Thank you very much !

[dansrfe]

Hank you're a rockstar! Thank you! :)

[juhok]

Thank you. :)

Is it possible to change the donation url to point to an english PayPal page?

[Guest]

Google Translate worked for me. :)

[Chumbo]

Now that there's a 64bit AVISynth and many plugins have already been ported over, any chance of seeing a 64bit version of HC and DGDecode sooner than later? That would be tremendous for those of us on a 64bit OS. HC runs fine on 64bit, it just crashes when exiting which requires manual intervention to go to the next file when batch encoding. Thanks for the consideration and thank you for the continued support and development.

[Guest]

Now that there's a 64bit AVISynth and many plugins have already been ported over, any chance of seeing a 64bit version of HC and DGDecode sooner than later?. I'll kick off 64-bit support for DGMPGDec. We're getting a bit overdue for a new release.

[Chumbo]

I'll kick off 64-bit support for DGMPGDec. We're getting a bit overdue for a new release.
Tremendous. Can't thank you enough.

[Emulgator]

Congratulations, Hank !
And here as promised, my second donation.
Many thanks for continued improvement !

[Mr. Monte]

Just D/L'd te latest HCEnc. I read the documentation, but it does not mention the SSE4 version of HC included since the beta. I have an i7 that supports SSE4. Is there any stat's to indicate the speed improvement of using HC SSE4 vs just HC ?

TIA

[burfadel]

Just use the SSE4 build, there's two builds that come with HCENC...

[Mr. Monte]

burfadel,

If you read my post, I am aware their are two builds in his release. This is why I was asking if any testing was performed to document the benefits? It was not in the PDF documentation with the release.

Thanks,

[hank315]

@ Mr. Monte
The speed difference will be small, only the CPU dispatcher logic is dumped.
Don't expect a speed difference > 1%.

HC runs fine on 64bit, it just crashes when exiting...
I did a lot of tests with this release but never encountered this one, can you give more info so I can replicate and solve it.

Is it possible to change the donation url to point to an english PayPal page?
Should be fixed now. And thanks :)

[Chumbo]

...I did a lot of tests with this release but never encountered this one, can you give more info so I can replicate and solve it....
Are you on Windows 7 64bit? Right now I can't load an AVS that uses a 64bit chain like this one for example:LoadCPlugin("D:\Multimedia Tools\megui64\tools\ffms\ffms2.dll")
FFVideoSource("E:\Media\work\encoding\OneMinuteClip.ts")
Load_Stdcall_Plugin("D:\Multimedia Tools\megui64\tools\yadif\yadif.dll")
Yadif(order=1)
BicubicResize(1280,720,0,0.5) # Bicubic (Neutral)
I can load standard avs files, i.e., 32bit chain, but that's when the crash happens. It's actually typical of all 32bit apps to crash when using these 32bit plugins. I encountered the exact same thing with megui until megui64 became available.

The script above loads fine into megui64 and VirtualDub64. This script uses the 32bit chain and works fine but the encoder crashes after it's done:DirectShowSource("E:\Media\work\encoding\OneMinuteClip.ts", audio=false, convertfps=true, fps=29.970)
Crop(10,4,-6,-4)
BicubicResize(1280,720,0,0.5)
trim(0,200)My media file's detailed info as as follows:General
ID : 1
Complete name : E:\Media\work\encoding\OneMinuteClip.ts
Format : MPEG-TS
File size : 68.1 MiB
Duration : 1mn 0s
Overall bit rate : 9 519 Kbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Duration : 1mn 0s
Bit rate mode : Variable
Bit rate : 8 661 Kbps
Maximum bit rate : 20.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.139
Stream size : 62.0 MiB (91%)
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Duration : 59s 936ms
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Video delay : 33ms
Stream size : 2.74 MiB (4%)
Language : English
The crash is the standard application crash with the message "MPEG2 enconder has stopped working" which happens either at the end of a successful encode or if I hit the exit button to stop the encoding and exit.

Once I'm back at the main GUI, hitting exit then crashes the main UI too with "HCgui 0.24 beta has stopped working." Note that I did this with the official released version and not beta even though it shows beta in the title.

Let me know what other info I can provide. Thanks a lot.

[hank315]

Running Win7-64bit prof.

I tried to replicate the crash with your script and source:

DirectShowSource("E:\HC_projects\HC024\Chumbo\OneMinuteClip.ts", audio=false, convertfps=true, fps=29.970)
Crop(10,4,-6,-4)
BicubicResize(1280,720,0,0.5)
trim(0,200)

I had a batch file running this script for 2 hours, it didn't crash.

There were some source mismatches between the first and second pass probably caused by DirectShowSource.
Using DGDecodeNV solved the mismatches.

BTW, I can't find the 64 bit ffms2.dll, do you have a link to it?

[Mr_Khyron]

64 bit ffms2.dll
http://code.google.com/p/avisynth64/wiki/PluginLinks

[hank315]

I also found that one but the ffms2 link at kemuri-9 is dead...

[Mr_Khyron]

I also found that one but the ffms2 link at kemuri-9 is dead...

http://kemuri9.net/dev/avs/ffms2/ffms2-x64.zip


http://kemuri9.net/dev/avs/LoadCPlugin/

[hank315]

Thanks...

[Chumbo]

Running Win7-64bit prof.

I tried to replicate the crash with your script and source:

DirectShowSource("E:\HC_projects\HC024\Chumbo\OneMinuteClip.ts", audio=false, convertfps=true, fps=29.970)
Crop(10,4,-6,-4)
BicubicResize(1280,720,0,0.5)
trim(0,200)

I had a batch file running this script for 2 hours, it didn't crash.

There were some source mismatches between the first and second pass probably caused by DirectShowSource.
Using DGDecodeNV solved the mismatches.

BTW, I can't find the 64 bit ffms2.dll, do you have a link to it?
Wow, I wonder what the difference is. I'm running Win64 Ultimate and not Professional but that shouldn't make any difference you would think. Mind boggling.

What happened when you loaded the script via the GUI and then used encode? Did the encoder successfully complete and close without the crash? If so, were you running the GUI through any Compatibility mode?

@Mr_Khyron,
Thanks for helping out with the DLL. Much appreciated. :)

Btw, you can find the ffms2 info here (http://doom10.org/index.php?topic=25.0).

[hank315]

What happened when you loaded the script via the GUI and then used encode? Did the encoder successfully complete and close without the crash? If so, were you running the GUI through any Compatibility mode?
No, a compatibility mode isn't needed, just load the AVS script and run, no problem at all here, I tested it several times.

FYI:
This script runs in 80 sec with source mismatch errors between the first and second pass:
DirectShowSource("E:\HC_projects\HC024\Chumbo\OneMinuteClip.ts", audio=false, convertfps=true, fps=29.970)
Crop(10,4,-6,-4)
BicubicResize(1280,720,0,0.5)
trim(0,1200)


This script runs in 54 sec without errors:
DGMultiSource("E:\HC_projects\HC024\Chumbo\OneMinuteClip.dgi")
Crop(10,4,-6,-4)
BicubicResize(1280,720,0,0.5)
trim(0,1200)

DGDecNV does a better and faster job here.

[Chumbo]

No, a compatibility mode isn't needed, just load the AVS script and run, no problem at all here, I tested it several times.

FYI:
This script runs in 80 sec with source mismatch errors between the first and second pass:
DirectShowSource("E:\HC_projects\HC024\Chumbo\OneMinuteClip.ts", audio=false, convertfps=true, fps=29.970)
Crop(10,4,-6,-4)
BicubicResize(1280,720,0,0.5)
trim(0,1200)


This script runs in 54 sec without errors:
DGMultiSource("E:\HC_projects\HC024\Chumbo\OneMinuteClip.dgi")
Crop(10,4,-6,-4)
BicubicResize(1280,720,0,0.5)
trim(0,1200)

DGDecNV does a better and faster job here.

Hmmm, I just don't get why it would behave differently on the same OS essentially. Any ideas on what to check for? I'm stumped.

Yes, I get the mismatch errors too by the way, but only when I don't use a lossless file which makes sense. I'm glad the lossless option is not blowing up any longer with non-mpeg2 sources like it used to. :)

All my video cards are ATI which is why I had asked for a 64bit version of DGDecode. In this case I'd need a 64bit version of DGAVCDecode but I think there are licensing issues for now with that one.

Did you try ffms2 and if so, how did it compare? Assuming you found a way to load it.

[hank315]

Used script with (32bit) ffms2.dll:

LoadPlugin("E:\HC_projects\HC024\Chumbo\32bit\ffms2.dll")
FFVideoSource("E:\HC_projects\HC024\Chumbo\OneMinuteClip.ts")
Crop(10,4,-6,-4)
BicubicResize(1280,720,0,0.5)
trim(0,1200)

A constant quant encode finishes OK.
In a 2pass run it will do the first pass, then a crash when the second pass starts, seems it can't rewind the file.
In a 1pass VBR run it crashes immediately meaning it can't do random frame access.

Win 7 error log:
Faulting application name: HCenc_024.exe, version: 0.24.0.0, time stamp: 0x4c86995a
Faulting module name: ffms2.dll, version: 0.0.0.0, time stamp: 0x4c7469e6
Exception code: 0xc0000005
Fault offset: 0x0023a699
Faulting process id: 0x11fc
Faulting application start time: 0x01cb54bdf1f60798
Faulting application path: E:\HC_projects\HC024\HCenc_024.exe
Faulting module path: E:\HC_projects\HC024\Chumbo\32bit\ffms2.dll

Can you generate an error log with your DirectShowSource script?

[Chumbo]

Used script with (32bit) ffms2.dll...Duh, of course 32bit. Ugh.
...Can you generate an error log with your DirectShowSource script?I can't believe I didn't think of looking in the logs for a possible pointer to the problem.

This is the encoder crash log:Faulting application name: HCenc_024_SSE4.exe, version: 0.24.0.0, time stamp: 0x4c869963
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x02382be5
Faulting process id: 0x17d0
Faulting application start time: 0x01cb5542a0ebc518
Faulting application path: D:\Multimedia Tools\HC024\HCenc_024_SSE4.exe
Faulting module path: unknown
Report Id: ee5697ca-c135-11df-a1d3-b8e322b06d28
I was curious as I have another script that encodes using a .dga file as the source. Here's the log from that:Faulting application name: HCenc_024_SSE4.exe, version: 0.24.0.0, time stamp: 0x4c869963
Faulting module name: BassAudio.dll_unloaded, version: 0.0.0.0, time stamp: 0x47da3274
Exception code: 0xc0000005
Fault offset: 0x023e2be0
Faulting process id: 0xad0
Faulting application start time: 0x01cb55428e5a2915
Faulting application path: D:\Multimedia Tools\HC024\HCenc_024_SSE4.exe
Faulting module path: BassAudio.dll
Report Id: dc7e58fb-c135-11df-a1d3-b8e322b06d28
This is the GUI app crash:Faulting application name: HCgui_024.exe, version: 0.24.0.0, time stamp: 0x4c868ff3
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x01c92be5
Faulting process id: 0x18f0
Faulting application start time: 0x01cb554315e2d0d0
Faulting application path: D:\Multimedia Tools\HC024\HCgui_024.exe
Faulting module path: unknown
Report Id: 6dbc9285-c136-11df-a1d3-b8e322b06d28

[yup]

Hi all!
After loading last version from hank site, HCEnc not finishing after encoding but m2v file exist. I by hand at task manager terminate HCEnc and after gui.
I am using Avisynth 2.6 Set release and official Aisynth 2.58 with the same result.
Script very simple
AVISource("aaa.avi")
Trim(1000,0)
Source file use Lagarith codec. 13 August version work fine.
yup.

[hank315]

@Chumbo
The fault offset is high, that's outside the range of the HCenc executable.
And as long as I can't repeat the error I can't solve anything...

@yup
Can you please post some more info about your system, OS, crash report.

[Chumbo]

@Chumbo
The fault offset is high, that's outside the range of the HCenc executable.
And as long as I can't repeat the error I can't solve anything...

I understand, so I just installed a fresh copy of Win7U64 in a VM. Clean install with all the latest Windows Updates updates. The only other media related stuff I installed are:

ffdshow 64 1.1.3463
haali splitter 1.10.262.12
avisynth 2.5.8 and 64bit additions

I used the Win7DSFilterTweaker 3.6 to try running both Microsoft and ffdshow h.264 decoders and the encoder still crashes. Here's the crash info with ffdshow as the default decoder:Problem signature:
Problem Event Name: APPCRASH
Application Name: HCenc_024_SSE4.exe
Application Version: 0.24.0.0
Application Timestamp: 4c869963
Fault Module Name: bass_mpc.dll_unloaded
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4383b424
Exception Code: c0000005
Exception Offset: 00362be0
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789The referenced module is a 32bit DLL in the avisynth plugins folder. How do you have your filters set up for h.264? Using ffdshow or Microsoft as a default?

Maybe a stupid question, but are you running a debug build on your system or the release version? It just seems like the crash is probably due to a bad pointer/null being accessed and operated on or maybe a memory freeing operation on a null or something like that? That's usually the most likely cause of an exception error c0000005.

I still don't get how it's working on your end. Is it possible you have some SDK that's providing files that we may not have? I'm grasping at straws at this point.

[yup]

@hank315
Windows XP 32 Professional SP3, Avisynth 2.58 official release,
sccript
video=AVISource("lect1lag.avi")
audio=WavSource("lect1monodenallnorm.wav")
Audiodub(video,audio)
#trim(1600,0)
trim(1600,4600)

lect1lag.avi encoding use Lagarith 1.3.20.
No crash! Program not exit after encoding finished.
yup.

[video_magic]

Never mind, just re-read the posts above. Was going to suggest Lagarith could have been the problem.

[yup]

@video_magic
The same problem with Ut 8.2 codec.
Both codec multithreated.
yup.

[hank315]

I've found a source which always hangs at the end, the encode finishes OK but HCenc will not close.
Will investigate...
And as always, thanks for the report.

EDIT: please try the HC025.exe beta release at http://hank315.nl
If you want to use it with the HC024 release, just rename this new HC025 beta.

Please report if this solves the issue.