HC Encoder v0.19 released

[halsboss]

Yes, in all seriousness thanks a huge amount for your work hank315 !! Life's good, with your HC to play with. Also cheers for the decoder warning tip, dragongodz.

[peter100m]

@hank315
First: thanks for your hard work!
Second: I have a small bug report. When using TIMECODE, the resulting timecode starts 2 seconds before the time set.
1:55:57:10 becomes 1:55:55:10.
Using 0.19.0.1.

[zambelli]

Indeed, thanks for the great work and also for the very prompt response to the 3:2 pulldown GOP bug!

[dragongodz]

is it safe to say the level of quality HCenc brings has been improved?
i havent done enough tests to comment on that. things i notice in a pre-release i will direct to hank315. so what is released may not be totally relevant to what i am seeing now. :)

[techreactor]

@katjarella
The new release is almost finished but there are still some unpredictable errors :(
Don't know how long it will take to fix it...

Is there anything on the adaptive matrix front in the new version, on similar lines of work done by SAPSTAR in the AQMEnc (QmatOp).

[maxfu]

The GUI hangs with avs input. HC Version is 0.19.0.1. AVISynth version is 2.5.7.

avs script:

AVISource("D:\Source\Source.avi")
LanczosResize(720,360)
AddBorders(0,60,0,60)
AudioDub(DirectShowSource("D:\Source\Source.ac3"))

The avi file is a xvid file.

[AlanHK]

The GUI hangs with avs input. HC Version is 0.19.0.1. AVISynth version is 2.5.7.

avs script:

AVISource("D:\Source\Source.avi")
LanczosResize(720,360)
AddBorders(0,60,0,60)
AudioDub(DirectShowSource("D:\Source\Source.ac3"))

The avi file is a xvid file.

Comment out the audiodub line.
I mostly use
AVISource("D:\Source\Source.avi",false)
to turn off sound from the avi when encoding, it can only cause problems.

[Ebobtron]

@maxfuYou may try AlanHK's suggestions if adding " ConvertToYV12() " to the end of your script does not help, both HC and QuEnc require YV12 from AviSynth. I suppose it is not impossible to have an avi source that is YV12 but it is at least as unlikely. Use the function info() after AviSource and load your script into a viewer / player then look at line three.

[Boulder]

HC doesn't hang when non-YV12 data is imported, it simply prompts an error message. Using DirectShowSource is probably the culprit, you'd better do as AlanHK says. If you want to load the AC3 file in your script, NicAC3Source is better (in nicaudio.dll).

[Ebobtron]

@maxfuLet me apologize for suggesting something so simple.My pointThis has been very common in the past.

More that one person as sat waiting for HC to parse a script only to not notice the message in a little window describing the trouble.

I suggest this because I am forced to assume by maxfu's post that the script works in other applications, ie VirtualDub, MediaPlayerClassic or I must assume maxfu writes and encodes (??), possible.
AlanHK's suggestion to kill the audio will never hurt when using HC.
Boulder's suggestions are good.
My idea sucks, I assume.

[Emulgator]

Back to Post Nr.42 in this thread:

Hi Heini011 !

Some weeks ago I also ran into this 3:18:45 stutter bug.

With contributions from me and MatzeHB
moonman could isolate and fix this bug
within the muxer engine of DLP,
which led to timestamps dropping to zero

This was a fault of DVDLabPro,
now fixed from DLP Version 2.24
(containing dvdlibx.dll build 41) onwards.

The whole story is there:

www.mmbforums.com/phpbb/viewtopic.php?t=15868

Not an encoder issue.
Happy now.

[Emulgator]

The next longplay stuttering issues I found at this occasion
are also not the result
of previous MPEG2-Encoding and/or DVD-Authoring:

PowerDVD5 exhibits a microstutter from 2:28:xx hrs onwards
on any of my 3 testing systems.
Even with DLP-2.24-authored HDD folders and discs
that play smooth anywhere else into that range.

This microstutter consists of 1..2 frames missing in display
of every GOP,so every ~0.5 sec one frame is frozen for the duration of 1..2 frames.

Visible only when played as DVDfolder using PDVD5 from HDD.

Not visible when played as VOB-files using the very same PowerDVD5 from HDD on the very same system.

Not visible when played from burned disc on standalones.

This bug does not change when DVD is authored with different versions of DLP.
---------------------------------------------------
PowerDVD 6 does not exhibit this 2:28:xx
microstutter anymore.

Therefore heavy stutter from roughly 3:20:xx on
as described in my post above.

But this time also in DLP 2.24-authored DVDs
that play smooth into that range anywhere else on standalones.

Can anybody confirm ?

[Emulgator]

Sorry for my 3 posts in sequence,
but I have been held up so long...

...in this forum's
5-days-newbie-quarantine. ;-)

Highest appreciation to Hank315 for HC !

Smooth picture !
No block flicker as with japanese encoders.
(TE4XP)

I tested and donated !

Suggestion to Hank:

Maybe bitrate distribution could be improved a little.

Right now with HC 0.19.1:

I see a too low short-time average bitrate
at the beginning of a MPEG2-stream (50% below total average)
and in the mid and end of the stream
short-time average bitrate is increased
slightly over the total average.

Bitrate viewers show a ramp.
In my testing case footage was ~1:52:xx hrs
and was to be encoded at 0-5000-8000 kbps VBR .

The stream started with short-time averages of 2500 kbps,
increased steadily over the first 15 minutes to the intended average
of 5000 kbps and in the mid and end range I saw
the short time average rising above 5500 kbps.

Because in the end there was still filesize to spend
that had been given too miserly in the beginning.

This lead to mediocre picture quality in the first 5 minutes
of the movie.

A small fix, I guess...

Keep up the good work !

[maxfu]

@maxfuYou may try AlanHK's suggestions if adding " ConvertToYV12() " to the end of your script does not help, both HC and QuEnc require YV12 from AviSynth. I suppose it is not impossible to have an avi source that is YV12 but it is at least as unlikely. Use the function info() after AviSource and load your script into a viewer / player then look at line three.

The problem solved. Thanks

[Mug Funky]

@ Emulgator:

on the bitrate distribution thing... what are the quantizers showing ? these are a much better indicator of quality than bitrate.

typically a movie will start quiet, get more action-y until about 2/3 of the full length, then will settle down again.

then when the credits roll, typically bitrate gets maxed due to subpixel compensation not being good enough (credits roll at any fraction of a pixel, not just halves, so the residual is deceptively large).

interestingly enough, Cinemacraft appears to detect credits and automatically hit them harder. i guess if contrast is high and motion vectors are all pointing upward it's a fair guess to make...

[zambelli]

interestingly enough, Cinemacraft appears to detect credits and automatically hit them harder. i guess if contrast is high and motion vectors are all pointing upward it's a fair guess to make...
What if the credits roll down like in "Run Lola Run"? :)

[Boulder]

interestingly enough, Cinemacraft appears to detect credits and automatically hit them harder. i guess if contrast is high and motion vectors are all pointing upward it's a fair guess to make...Now that would make a fine feature request although hank315 said that he'll add tweaking the bitrate for credits to HC.

@Emulgator: I don't think you need to apologize for posting all that stuff..if only all bug/test reports were as detailed as yours:) Often they are just "help me, it doesn't work" and no details included. I deal with software testing at work and I'm very annoyed when I have to reproduce a problem with very little information.

[cweb]

From the v0.18 thread:

I got this error message on my last encode. The script is very simple:LoadPlugin("c:\progra~1\dvd-rb pro\dgdecode.dll")
MPEG2Source("tombraider.d2v",idct=6,cpu=4)
vbw1=MVAnalyse(isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=16,idx=1,sharp=2)
vfw1=MVAnalyse(isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=16,idx=1,sharp=2)
MVDegrain1(last,vbw1,vfw1,thSAD=200,idx=1)
Limiter()
The source is a DVB capture run through DGIndex v1.1.0 (to be able to use NaN's DGDecode.dll).
I'm getting this error with a DV source and use of MVAnalyse as above.
Has there been any progress on this error?

[Boulder]

I've not had that error in v0.19. Have you tried updating Avisynth and MVTools?

[cweb]

I've not had that error in v0.19. Have you tried updating Avisynth and MVTools?
I have the latest version of both.

I moved things around a bit, specifically a reversed trimmed clip, to a later part and it seems to be working fine again now.
As long as it's working I'm happy...

Thanks anyway but the bug is still there somehow... some obscure condition triggered it.

[Mug Funky]

What if the credits roll down like in "Run Lola Run"? :)

hehe... don't know - i didn't encode it :) you could do a bitrate scan of it... it may be a generalised behaviour where if all vectors point the same way (rather than just upward), and are short enough, a slow pan is detected and quants are raised.

you'd have to ask the people at Custom Technology about that one...

[Asmodeus]

At first sorry for not reading whole therad but simple Ctrl+F "VBV" didn't pointed my bug.

This are my settings:
*INFILE d:\some.avs
*OUTFILE d:\some.m2v
*FRAMES 0 59100
*PROFILE best
*ASPECT 4:3
*GOP 18 2
*CQ 3.000
*CQ_PFACTOR 1.50
*CQ_BFACTOR 3.00
*DC_PREC 8
*CLOSEDGOPS
*PULLDOWN
*LASTIFRAME
*MATRIX hvsbest
There is also zigzag, seq encode, and rest as default.

Bug is related to "constant Quantization - check VBV/max bitrate".
Difference for file size obtained is:
2.81GB without checked
1.35GB with checked

I don't think it's normal. Ok it can be +- few %, but 2 times bigger :confused:
Movie is document so there isn't much action.

[Emulgator]

Back after work...
Thank you, Boulder and Mug Funky !

@ Mug Funky:
on the bitrate distribution thing....
typically a movie will start quiet, get more action-y
until about 2/3 of the full length, then will settle down again.
then when the credits roll, typically bitrate gets maxed
due to subpixel compensation not being good enough
(credits roll at any fraction of a pixel, not just halves,
so the residual is deceptively large).

I know what you mean...

Of course bitrate will move up and down
with the difference to tell from frame to frame -> action, noise, shakyness

I will try to be more detailed :

The footage I had to encode
was private material shot by someone else
18 years ago on a VHS-C camcorder.
No credits, no tripod, constant low-level-action,
the usual slightly shaky and noisy thing.

Because this footage exhibited the usual flaws and started
with very dark scenes shot in an underground station,
I considered it a challenge for any encoder.
The dark scenes contained something to be encoded,
no saturated blacks.

I used it to test 7 encoders :
MC XS (built-in EditStudioPro 5.0.1), MCEnc 1.5.1 Standalone,
TMPGEnc 2.524.63.181, TE4XPress Version 4.2.3.193,
QuEnc 0.71, HC 0.19.1, CCE 2.67.

With this kind of source footage
only HC's bitrate and picture quality
showed a drop in the beginning.

(In my post I should have said "slope", not "ramp")

Quantisation was too high, macroblocks were visible in the dark.

This situation improved over the first 5 minutes,
independent from the content.
Picture Quality was beautiful then.

With the other encoders bitrate distribution was ok.

Both MCs did the best in saving bitrate on pure blacks
and giving on motion.
But noise was encoded as slightly vertically
and horizontally striped macroblocks.
CCE (3-pass) was a little bit strange
and wasted 2.5Mbps on pure blacks,
but still had enough room left for encoding noise properly
beside of encoding good frame content
Both TMPGs showed striped macroblocks
and macroblock flicker per GOP.