HC encoder

[hank315]

But is the encoder under these conditions, capable of strictly obeying the GOP limits of 13 and 14 ?The first test release didn't strictly handle the limits so a setting of 14 could generate some GOPs with a length of 15, this might explain the pulldown error.
The last test release will follow the given GOP sizes exactly, it can ofcourse be smaller in case of a scene change but it will never be larger.
BTW, an open GOP 13 in HC looks like: IBBPBBPBBPBPB, closed: IPBBPBBPBBPBB
open GOP 14: IBBPBBPBBPBBPB, closed: IPBPBPBBPBBPBB

[jdobbs]

I am unaware if this issue I'm having now is HC-specific or just in general when changing GOP size. From my posts above, you can see that I had to lower the GOP # for my encode. Now that I am using a GOP or 12, the encode is going at least 2x slower. Is this normal? Before when I had HC on autogop, the 2-pass encode with my script took appx. 65 hours. Right now it's been 43 hours just for 74% of pass #1.65 hours? :eek:

You don't have to shovel coal into the back of your computer to make it run do you? ;)

[EpheMeroN]

lol no i don't... the pc isn't that old either. it's a p4m 1.7ghz dell laptop with 256mb ddr ram. it's the script that bogs it down so much. i call funkydeblock, limitedsharpen, and hqdering in it. good times i know!

any ideas why it's even slower this time around now that i lowered the gop to 12?i actually thought it would be faster as i removed undot() from the script.

[jdobbs]

Hmmm... just for everyone's sake -- while this formula works very well with CCE, it seems to be off on HC. I'm working on a new formula for HC now.Well I have to stand corrected... it appears that at least with HC a linear computation works much better. I've just changed the predictive code for HC in DVD-RB...

[Marius-the-Mad]

@ all: Thank you for the answers. :)

@ jdobbs: Sometimes, all it takes to slow down the processing to 0.02x RT, is using iip() with an analog capture. ;) Even though my Athlon XP is probably two times slower than EpheMeroN's Pentium M, we'd still be near 0.05x RT for him.

Sometimes I really wish hardware grew on trees... :(

</offtopic> ;)

[Darksoul71]

@jdobbs:
Well I have to stand corrected... it appears that at least with HC a linear computation works much better. I've just changed the predictive code for HC in DVD-RB...

I´m just as curious as usual :D

Would you mind sharing your prediction code for HC with us ?
What start value do you use for the Q-Value ?

TIA,
D$

[jdobbs]

Here is the formula I use to get a start value:

Q = Int((EncFrames / TargetSectors) * Q_ROM_Constant)

My default value for Q_ROM_Constant (rough order of magnitude constant) is 256 and is used for both HC and CCE -- but if you are using it exclusively for HC you may want to play with it a little to get closer. The resulting value is divided by 10 for HC. EncFrames is the number of frames to be encoded, TargetSectors is the number of 2048 byte sectors that would represent a perfect sizing.

By the way, somewhere earlier in this thread I mentioned dividing by 100 -- actually I meant 10. I'll go back and change it to avoid confusion.

[Xeno86]

And regarding pulldown... maybe this will help:

The GOP size is a count of physical frames in the bitstream and is independent of the display duration of the frames in the GOP. DVD limits the GOP sizes to 18 for NTSC and 15 for PAL, but the count is actual encoded frames, not the display duration of those frames.

There is a case however, with 23.976 pulldown and 15 frame GOP's, where a set of GOP's may be encoded such that they cannot be made DVD compliant. Use 12 frame GOP's to avoid the problem.

DVD specifies that the stream be broken into VOBU's, a VOBU starts with a GOP and may contain more than 1 GOP but the display duration of the VOBU must be >= 0.4 seconds and <= 1.0 seconds (except for the last VOBU which may be <= 1.2 seconds).

If a 15 frame GOP is created followed by a 9 frame GOP (say because of a chapter point) and then followed by another 15 frame GOP, the 9 frame GOP cannot be combined into a VOBU and would be considered to have an illegal length.

The 9 frame GOP display period is 367.0333... or 383.71666... ms (4 or 5 frames will have repeat first field = 1), too short to be in a VOBU by itself so it has to be combined with the previous or next GOP to form a VOBU.

The 15 frame GOP's display period is 617.28333... or 633.9666... ms (7 or 8 frames will have repeat first field = 1).
http://forum.mainconcept.com/viewtopic.php?p=5891#5920

[Xeno86]

Everything is fine but I don't understand this:

This example is for 23.976 -> 29.97 pulldowned GOP
Normally you would have either:

15 frame GOP: 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 (8 extra fields)
9 frame GOP: 2 3 2 3 2 3 2 3 2 (4 extra fields)
15 frame GOP: 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 (8 extra fields)

633.9666 + 367.0333 = 1000.999... too large!

BUT!
If we make similar calculations for 23.976 not pulldowned, progressive GOP we have:

15 frame GOP: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 (0 extra fields)
9 frame GOP: 2 2 2 2 2 2 2 2 2 (0 extra fields)
15 frame GOP: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 (0 extra fields)

9 frame display period = 9/23.976 = 375.375... ms
15 frame display period = 15/23.976 = 625.625... ms
375.375 + 625.625 = 1000.999... which is also too large :eek:

Can anyone confirm that my assumptions and calculations are ok?
Because for me it seems that regardless the stream is pulldowned or not we have identical display times which would suggest that it is ok to apply pulldown to 18 frame GOP stream :devil: .

[Marius-the-Mad]

Great find, Xeno86! Thank you!

As for your second post, however, I'm not sure I know the right answer. :(

[Sir Didymus]

Hey Xeno86, you are not considering that just PAL and NTSC standards are allowed for DVD, even though mpeg2 admits other frame rates, so for sources at 24 fps, the pulldown process is simply unavoidable (in other words no VOBUs based on plain 24fps streams are admitted)...

Said this, your calculations are correct, but this is simply due to the fact that the pulldown process does not change the speed of the stream (so the whole duration of the pulldowned and not pulldowned GOPs are clearily the same...)... Just the framerate is changed...

Cheers,
SD

[Xeno86]

Thank you for your reply Sir Didymus I simply forgot about that :)

But while using GOP 15 we can still make a dvd compilant stream with 23.976 -> 29.97 pulldown. The only thing that is required is NOT to use 9 frame GOP before/after 15 frame GOP so that VOBU will never be longer than 1.0 s.
I should be also possible to use GOP 18 but we there can't be a 6,7,8 or 9 frame GOP after 18f GOP, no 7,8,9 after 17f... and so on.
The encoder should avoid such GOP combinations and everything should be DVD compilant then.

Again, correct me if I'm wrong ;)

[Sir Didymus]

?????

Hei Xeno86, it seems you miss again some very basic constraints about encoding and authoring...

You can not impose such strong limitation to an encoder, otherwise it would be impossible to properly handle scene changes and, for example, while feeding it with an n frames stream, you would simply be unable to obtain n frames as output...

Also, for the precision of the chapter points placemen, it is a fundamental feature of many high level encoders to be able to position I frames (in a single given video stream, and based on some definition or list of chapter points), wherever the user needs...

Cheers,
SD

By the way, sorry again for the little digression, since it's going definitely off topic...

[Xeno86]

@sir didymus
Why do you think it would be a limitation? At the moment you HAVE TO use GOP length 12 setting in HC to produce dvd compilant stream after pulldown. What I am suggesting is to add ADDITIONAL CAPABILITY to use longer GOPs in pulldowned stream it doesn't limit anything - regular streams would be totally unafected! It just adds functionality!
I don't think it would arise problems when it comes to scene changes, chapters, etc.
Most encodes are done in 2 passes so in the first pass encoder checks where to put I frames and in the intermediate state it can calculate GOP lenghts so that they do fit exactly where we want them.
What I am trying to tell is to try to avoid such GOP lenght combinations that would cause problems and use other. And again I say that is should be totally optional so that the user can decide wheather to enable it or not.

For example instead of using problematic GOP set:
18 18 18 18 18 18 18 7 18 (last VOBU too long)
the encoder could use this:
18 18 18 18 16 16 16 13 18 (everything fine)

So please tell me wheather it is possible or not... It would help gain quality and use less bits. So i think it's worthy.
BTW. I don't think that it's off topic :)

[jdobbs]

I'm having a little trouble following this... why would the GOP length have an effect on pulldown anyway? The pulldown flagging sequence isn't done against a single GOP but against the temporal frame positions of the entire stream. What am I missing here?

[Xeno86]

@jdobbs
see post #508 (http://forum.doom9.org/showthread.php?p=714018#post714018) and link (http://forum.mainconcept.com/viewtopic.php?p=5891#5920) under that post.
why would the GOP length have an effect on pulldown anyway?
It is described in the link above - using GOP combination eg. 15-9-15 violates the rule that VOBU's display time >= 0,4s & <= 1,0s. I'm trying learn if it would be possible to bypass this limitation using gop-length combinations (as in my previous posts) and not to be 'glued' to max gop length = 12 when using pulldowns (while dvd standards allow to use max. gop lenght=18 for NTSC) or am I mad and trying to do something what is impossible? ;)

BTW. I'm basing whole this teory on what BB said in his post (http://forum.mainconcept.com/viewtopic.php?p=5891#5920) so blame him :p

Thx for all your answers

[jdobbs]

Wow. Brent Beyeler himself was speaking in that link. That guy's a legend. In fact, if I recall properly, the PULLDOWN.EXE utility was based upon his sources.

[hank315]

You can not impose such strong limitation to an encoder, otherwise it would be impossible to properly handle scene changes and, for example, while feeding it with an n frames stream, you would simply be unable to obtain n frames as output...Properly handling scene changes is still possible, HC already knows where to put a scene change at least 2 GOPs ahead because it caches and analyses 80 frames before encoding.
It will need some extra checking and inserting some shorter GOPs but it's not impossible.

[Sir Didymus]

@sir didymus
...
For example instead of using problematic GOP set:
18 18 18 18 18 18 18 7 18 (last VOBU too long)
the encoder could use this:
18 18 18 18 16 16 16 13 18 (everything fine)
...


Ok. I see what you mean... it seems it is necessary to look at least three or four gops in advance, but Hank315 saying it is possible means it's ok...

So, let me apologise for the wrong assumptions I made, and lets' add this "15 GOP size for 24 --> 29 pulldown streams" mode in the requests for the HC encoder !!!!

All the best,
SD

[Xeno86]

and lets' add this "15 GOP size for 24 --> 29 pulldown streams" mode in the requests for the HC encoder !!!!
Nice to hear that but please let me also add "18 GOP size mode" to this request ;)

Cheers

[johnhamler1]

why HC is so slow???

[jdobbs]

Slow? Compared to what? It isn't as fast as CCE -- but it is considerably faster than most encoders.

[video_magic]

"why HC is so slow???"

It depends a lot on the settings that you use for an encode, as to how long an encoding might take.

Plus what pre-processing you do like in Avisynth (got many filters, resizing?)

There are other factors too: like what other tasks are happening on the PC at the same time as you are encoding, what class of hardware is in your PC, whether your Windows is set up well & tidy, got enough free memory is it paging a lot, etc etc

[Fishman0919]

why HC is so slow???

?!?!?!?, HC is pretty fast for encoders, at best settings it's faster then Procoder, TMPGEnc, Mainconcept and Sony Vegas... and is as good if not better in most cases. If you are comparing to CCE, then most encoders will fall short when comparing speed but quality of HC to CCE is real close... sometimes better.

[Sounddude]

This is becoming my favorite encoder. Speed, quality, it doen't get much better than this. Big thank you to Hank!!

[Amnon82]

but quality of HC to CCE is real close... sometimes better.

... thats right. Hank did/do a good job here. Can't wait for the next release ...

[Prodater64]

Related to the CQ encoding.
CQ mode is not a good solution as hank315 answered me some time ago, btr spikes can't be avoided. I don't know if he fixed it in any way.
cq_maxbitrate will be a solution when hank315 manage to bring back "cutted bits" (to keep dvd compliant). At the present state most CQ_maxbitrate encodings undersizes.
Im worked on, but not tested yet, a prediction model based in Cuadratic Lagrange Interpolation polynomials. I have a test model wrote in Windows cmd scripting language (old dos batch). If anybody is interested in this, I can post it or PM it where you want.
This method could compensate the present CQ_maxbitrate limitation (I don't know Newton implemented method in ROBA but related we are talking with Danpos, it is a lineal method, opossite with the Lagrange that is not, so maybe this last one would be better when CQ curve is not lineal).

Edited: Sorry, I find out that Newton Raphson method is not Newton interpolation I talked with Danpos.

[hank315]

The undersizing using CQ_MAXBITRATE is probably caused because of the "lost bits" which aren't given back to the bitstream.
Keeping track of these lost bits and putting them back into the bitstream is still not implemented :(

Im worked on, but not tested yet, a prediction model based in Cuadratic Lagrange Interpolation polynomials. I have a test model wrote in Windows cmd scripting language (old dos batch). If anybody is interested in this, I can post it or PM it where you want.Yes, I'm interested.

BTW. Newton-Raphson is a very fast solution method, the convergence rate is quadratic.
One of the drawbacks is you have to know the derivative of the function but that can also be solved with some simple math tricks.

[Prodater64]

The undersizing using CQ_MAXBITRATE is probably caused because of the "lost bits" which aren't given back to the bitstream.
Keeping track of these lost bits and putting them back into the bitstream is still not implemented :(


I think it would be worh to work on that feature as CQ encoding mode would be much more accurate and predictable.


Yes, I'm interested.


http://rapidshare.de/files/5497745/Lagrange.zip.html

You will see in the batch file some equations that represents 3 sample encodings (3% each one).
Using that formulas you can find out the CQ_maxbitrate for a given sample length.
These equations have an error that can be calculated also.
Your target must to be between the extremes (and better near it). Opposite is extrapolation and it is not on this batch sight.
You can read something and view equations in http://mathworld.wolfram.com/LagrangeInterpolatingPolynomial.html
A brief search also will give you many results about Lagrange interpolation.

I hope you get success with OPV encoding soon.
See You.

[dragongodz]

The undersizing using CQ_MAXBITRATE is probably caused because of the "lost bits" which aren't given back to the bitstream.
I think it would be worh to work on that feature as CQ encoding mode would be much more accurate and predictable.
just a few small commens on this if i may. ;)

the maxbitrate limiting is already taking this slightly away from being CQ but is of course done with the purpose of dvd compatability.
now if you add the bits lost from this back in you are taking it away even more to the point it could really be considered a CQ/VBR hybrid. this does not mean hank315 shouldnt do it if he chooses but simply that maybe he would want to think about changing what its called.

as for predictability, well thats not really the encoders fault at all. it is not being given a bitrate or size to target only the quant to use and in this case the ability to adjust when they go ever the max bitrate. as such you will of course never get 100% predictability from a tiny sampling ,that includes with the bits put back in, but i guess it would make it more easy to be close for others doing the prediction. ;)

as for accurate though, sorry but HC is accurate because it is doing exactly what it is meant to, again it has no average bitrate or size to try and target only a quant. it is the prediction by other means that is not accurate. this of course goes back to the predictability by other means.

[Prodater64]

@dragongodz: My sentence was not in any way a negative one, sorry. English is not my native language so maybe my sentences couldnt be understood.
Sorry for that.
I hope hank and others now can understand what I meant.
I just want to contribute with this encoder wich in vbr mode gives almost perfect streams in all senses.
CQ_maxbitrate at the moment don't permit you a good prediction related to the final size.

[dragongodz]

My sentence was not in any way a negative one, sorry.
i didnt really take it as so either, sorry if it appears i did. ;)

CQ_maxbitrate at the moment don't permit you a good prediction related to the final size.
yes i was just trying to point out where these changes are taking the CQ mode and the fact that CQ is never 100% predictable and thats not really the encoders fault. to do that you need to give it either a target bitrate or size.

[hank315]

I hope you get success with OPV encoding soon.Well, I have a very premature version which I'm testing now.
Last night I did LOTR-Fellowship at bitrate 3200, it came out 0.6% oversized (bitrate 3221).
Prediction took about 8 minutes, one pass encoding was done in 1:55 hour (37 fps on a P4 3.2).
So far it looks promising...

[Prodater64]

Well, I have a very premature version which I'm testing now.
Last night I did LOTR-Fellowship at bitrate 3200, it came out 0.6% oversized (bitrate 3221).
Prediction took about 8 minutes, one pass encoding was done in 1:55 hour (37 fps on a P4 3.2).
So far it looks promising...


Wow!!
Thanks and keep the good work!!

[Darksoul71]

@Hank:
Sounds promising ! :D
BTW: Even the worst "Q-Factor" search (e.g. bi-section) will take something like 8-10 prediction-runs to hit your target size. This still would mean 90% time saving compared to a normal 2 pass encoding.

To me anything below 2% tolerance would be acceptable (something around 80 MB for a standard full DVD movie). I don´t need to fill a DVD to the limit. Those few kBit/s lost want hurt my eyes. I often experience undersized movies when using D2SRoBa. In case a movie is really oversized you still have the option to shrink the movie with rejig and please noone tells me that he´ll notice a decrease in quality when requantizing his mpeg by 2-5%.

I can´t wait to get my hands on the "OPV" version of HC enc :)

Take your time, Hank

-D$

[hank315]

As you can imagine it is not a real CQ mode, the prediction run (3 iterations) is done to get a nice starting Q.
While encoding the Q can vary if the target seems not to get hit exactly.
If only the prediction was used results were mostly done with a +/- 10% size error.
I think if anyone can do a real CQ run with an error always < 5% the prediction algorithm used is already *very* good.

[Darksoul71]

@hank:
As you can imagine it is not a real CQ mode, the prediction run (3 iterations) is done to get a nice starting Q.
While encoding the Q can vary if the target seems not to get hit exactly.

/me stupid ! This is something I don´t understand. Speaking as a complete layman for me CQ means constant quality = the encoder "does not care" about the bitrate spent (unless it´s above a defined bitrate level) and tries to keep the quality at a defined level. Having this in mind, I encode few (more or less reprensentative) pieces of my movie (e.g. SelectRangeEvery via AVISynth). For each CQ value I´ll get a certain final size depending on filters, compressibility of the movie, encoder settings, etc. Depending on your search approach you´ll find sooner or later at Q-value matching your target size. Unless your movie samples are not very representative for the complete movie or the encoder doesn´t keep the quality very well, you´ll mostly hit your target size within 2-3%. At least that was always my impression. Even with my scaled down formula I use for FitDVD and Komprezz2MPEG I´ve never really experienced oversized movies with CCE. Same goes for D2SRoBa / DVD2SVCD.

If I understand you correctly you are talking about a little different approach:
1) Doing CQ prediction similar to CQ search of e.g. AutoQ or D2SRoBa
2) Using this CQ value as base and adjusting the CQ value on the fly

Is this correct ? If yes, then I still don´t understand why this is really neccessary. I didn´thave the time to continue my work on the prediction code for HC enc but wouldn´t be supprised to get the same precision. May be HC enc is a bit different as it provides a finer scale for the Q-value compared to CCE´s integer values.

If only the prediction was used results were mostly done with a +/- 10% size error.
Hm, this keeps me thinking........
10% would mean something like 400 MB over/-undersize for a DVD media.

Well, I´ll keep my mouth closed and wait for your implementation <ggg>

-D$

[Xeno86]

While encoding the Q can vary if the target seems not to get hit exactly.
This sounds like 1-pass VBR :)

@Darksoul71
In HC CQ=Constant Quantizer not quality (as in TMpeg)

@hank315
You should change "Constant Q" to "Const. Quant." as many people confuse this "Q" with "Quality".

[Darksoul71]

@Xeno86:
uh oh, I guess I´m really a dumba$$ in regard to MPEG2 stuff :rolleyes:

CQ = Constant Quantizer <> Constant Quality ! Correct ?

I always thought that constant quantizer is somewhat identical to constant quality because the video is compressed with a constant "factor".

Well, I never told I´m an MPEG2 expert <ggg>

I guess I´m beginning to understand what hank talks about: He describes an encoding method which is similiar to the way realtime MPEG2 cards work in VBR mode: You specify a VBR average bitrate and a max bitrate. The hardware encoder tries to keep the average bitrate but will adjust the bitrate based on the action / complexity level of the movie -> a lot details / movements = more bits spent. Hank describes a similar approach where the quantizer is adjustet if the average bitrate of the movie get´s too high or too low.

-D$

[dragongodz]

This sounds like 1-pass VBR
yes it is in effect a type of 1 pass VBR. well not really, more a short predictive first pass to base second pass on. to the user it will be close enough to a 1 pass VBR ,or a VBR/CQ hybrid with pre-prediction if you want to get picky. ;)

In HC CQ=Constant Quantizer not quality (as in TMpeg)
You should change "Constant Q" to "Const. Quant." as many people confuse this "Q" with "Quality".
2 points.
1. HC is not tmpgenc so people should learn what HC is and not base things on ONE other encoder.
2. in the docs(pdf) that comes with HC it quite clearly states CQ is constant quant. people should read the docs before trying to guess.

He describes an encoding method which is similiar to the way realtime MPEG2 cards work in VBR mode: You specify a VBR average bitrate and a max bitrate. The hardware encoder tries to keep the average bitrate but will adjust the bitrate based on the action / complexity level of the movie -> a lot details / movements = more bits spent.
yes this is basic VBR.

[ernstblaauw]

Is it possible to queue some files in the GUI, so I can encode some movies over night?

I now only see a batch command in the command line version. Because I make always some mistakes if I have to make my own batch file, those encodings will (almost always) fail.

[Prodater64]

Is it possible to queue some files in the GUI, so I can encode some movies over night?

I now only see a batch command in the command line version. Because I make always some mistakes if I have to make my own batch file, those encodings will (almost always) fail.

For that exist the command line version.

Read this:

http://forum.doom9.org/showthread.php?p=692791#post692791

[ernstblaauw]

I encoded a home made movie (DV AVI) using HC 15a and later, when the problem still existed, with HC 16tr2. The movie just acts as normal if I watch the avi or the .avs (which only contains DirectShowSource() ).
The encoded movie has the correct length, but it does not contain the encoded movie, but only the last frame of the encoded movie, in a row (so I can watch the last frame for the correct length of the movie).
Anyone familiar with this problem?

edit: I just discoverd that during the first-pass, the preview window shows the correct movie. But in the second pass, already only the last frame is shown.

The command I used to start the encoding:
start "HC-Batch" /wait HCbatch_016_testrelease2_16-09-2005.exe "-ini" "D:\film progs\HC_016_tr2\hc - progressive.ini" "-i" "D:\Jox\Sodom.avs" "-o" "D:\Jox\MPEG2\Sodom.m2v" "-log" "D:\Jox\log\Sodom.log"

The ini:
+-------------------------------
HC.ini template
These commands are required
Use full pathnames and just use the bitrate you want
-------------------------------
*infile d:\Jox\
*outfile
*bitrate 8000
*maxbitrate 9000
-------------------------------
Next commands are optional
putting a space for it disables a command
Not all commands are shown here,
see the manual for a complete list and default values
-------------------------------
*aspect 4:3
*bias 30
*dc_prec 10
*logfile D:\film progs\HC_016_tr2\hc.log
*profile best
*wait 5
-------------------------------
Next commands you can specify interlaced
tff => top field first
bff => bottom field first
Don't know? Check with AviSynth command:
AsummeTFF() or AssumeBFF()
SeparateFields()
-------------------------------
*bff
*tff
*interlaced

The log:

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

input: d:\jox\sodom.avs
output: d:\jox\mpeg2\sodom.m2v

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

profile: BEST
frames: 1 4950
framerate: 25.00
aspect ratio: 4:3
bitrate Kb/s: 8000
max. bitrate Kb/s: 9000
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 30
chapter frames: 0
time code: 0 0 0 0
CPU: SSE2
matrix: MPEG

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

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

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

pass 1 encoding time: 0:02:42 (162 s)
average fps: 30.7

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

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

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

pass 2 encoding time: 0:06:26 (386 s)
average fps: 12.8

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

total encoding time: 0:09:09 (549 s)

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

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

nr. of gops: 331
nr. of frames: 4950
nr. of I-frames: 331
nr. of P-frames: 1053
nr. of B-frames: 3566
average quant (non linear): 1.027
VBV underflows detected: 501
VBV underflows fixed: 501
minimum bitrate: 4030
maximum bitrate: 8958
average bitrate: 7610

[Centurione]

I got some similar problem (but not related to HC encoder), when using the "DirectShowSource(..) statment in the AVS script.
Sometimes, perhaps when the film has to be "rewinded", at the beginning of the second pass, not always this happens correctly.
Is this the case ?

regards, Centurione

[ernstblaauw]

I got some similar problem (but not related to HC encoder), when using the "DirectShowSource(..) statment in the AVS script.
Sometimes, perhaps when the film has to be "rewinded", at the beginning of the second pass, not always this happens correctly.
Is this the case ?

regards, Centurione
How can I avoid to use DirectShowSource? I don't see another possibility than using DirectShowSource to open the file. But it happens every time with this particular movie, and I didn't happened before with any other video.

[midnightsun]

avisource if it's an avi or mpeg2source if it's an mpeg1/2

[Prodater64]

I encoded a home made movie (DV AVI) using HC 15a and later, when the problem still existed, with HC 16tr2. The movie just acts as normal if I watch the avi or the .avs (which only contains DirectShowSource() ).


Im wondering why you download the last version without read what hank315 wrote about it:

http://forum.doom9.org/showthread.php?p=712482#post712482

A new test release: http://hank315.dyndns.org/HCbatch_016_testrelease2_16-09-2005.zip

Thanks for the feedback, most issues are solved now:
- hangs while running minimized
- wrong GOP size for some fixed GOPs
- artifacts at the right side of some frames

The artifacts were caused because motion vectors could point out of the frame by half a pixel, some decoders don't like that...

Still one issue left, using Avisynth DirectShowSource with the WMV decoder sometimes won't read the stream correct during the second pass, it can skip frames or even jump back.

As your file is an avi try Avisource() (I don't know if it can manage digital video)

[ernstblaauw]

Im wondering why you download the last version without read what hank315 wrote about it:

http://forum.doom9.org/showthread.php?p=712482#post712482



As your file is an avi try Avisource() (I don't know if it can manage digital video)
I read the comment, but the video is not a WMV, but a DV AVI (it is not the same, is it?). So I assumed I could use DirectShowSource. I will now try it using AVISource.

[Boulder]

DirectShowSource can be problemous at times so that might well be the cause.

[ernstblaauw]

DirectShowSource can be problemous at times so that might well be the cause.
I just changed all 'DirectShowSource()' to 'AVISource()' in my AVS-files. No I'm reencoding using a batchfile. Luckily it are not that big files.
Again a lot of thanks to Hank315 for delivering such a high quality encoder!