HC encoder

[parcival]

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

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

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

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

[Kika]

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

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

[LigH]

@ parcival:

(Welcome to the doom9 board...)

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

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

[parcival]

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

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

[parcival]

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

[johnhamler1]

hello,

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

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

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


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

[hank315]

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

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

[Encoder Master]

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

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

[jdobbs]

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

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

[rail grinder]

GGRRRRR

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

keep up the awesome work hank ;)

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

[freelock7]

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

[Kika]

@jdobbs, Encoder Master, hank315

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

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

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

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

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

[Xeno86]

hi

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

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

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

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

[Encoder Master]

Problem with the shutdown option:

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


@Kika

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

[LigH]

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

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

[Kika]

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

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

OK, back to topic.

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

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

[Encoder Master]

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

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

[Kika]

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

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

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

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

[hank315]

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

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

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

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

[LigH]

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

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

[Kika]

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

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

[LigH]

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

[hank315]

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

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

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

[hank315]

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

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

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

[Kika]

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

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

[hank315]

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

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

[LigH]

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

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

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

Nice statement for posting #1000?! ;)

[hank315]

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

And yes another milestone: 1000 posts :D

[vhelp]

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

CQQ = "Constant Quantizer Quality"

-vhelp

[Xeno86]

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

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

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

[Kika]

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

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

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

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

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

[zilexa]

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

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

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

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

[Archimedes]

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

Best regards
Josef

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

[zilexa]

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

[MuttLover]

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

Good luck!

[johnhamler1]

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

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

[lunario]

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

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

avi2dvd , avixdvd they both give the error

pS dvd-rb doesn´t give me that error

[skipper152]

Hi,

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

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

014 has been working fine on the Athlon.

batch015 works on my Pentium M laptop, no problems.

Skip

[doxville]

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

Thanks! :)

[feedback]

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

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

Regards,:)

[urvieh]

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

No competition meant, just my two cents.

[Kika]

What did you use? 2pass, 1pass?

[urvieh]

What did you use? 2pass, 1pass?

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

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

[johnhamler1]

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

[urvieh]

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

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

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

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

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

[johnhamler1]

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

[urvieh]

well, the cheapest player work better.

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

[Heathcliff!]

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

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

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

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

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

Thanks alot and keep up the good work!
Heathcliff

[dragongodz]

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

[urvieh]

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

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