:mrgreen: sorry :oops:
My bad assumption.
And yes, I've read the thread where you, Karl and Andrej discussed it and I couldn't make my mind on what you all found out or agreed on :roll:.
Understood.
What do you mean with "by default"?
Isn't it the "Output YUV data as Basic YCbCr not CCIR601"?
If so, should I set it to on or to off? I believe the default is off (unticked), isn't it?
Ok then. So if I want to compare the two of them (in fact along with NuEnc) I should enable the above Tmpgenc option so that Tmpgenc doesn't clamp the chroma/luma values, right?
Even because HC and NuEnc don't have such a feature themselves, right?
Will do so, for the testing purposes but what about in real life encodings?
Isn't that bad for the TV set? I mean not with small testing clips but with a lot of big >=2h00 movies?
You mean that you're not sure if Tmpg cuts or rescales the ranges?
BTW what's the difference?
I'm going so much off topic that I wonder if we shouldn't split the thread at this point :roll:
Sorry about that, guys.

As you say, the default is off, means "TV scale" and it's the setting to use.
(this can be discussed if you have somthing like a plasma screen)

That sounds correct.

What I told you is for real life encoding.

You missed something : I told you to use the option for luma clip in TV range for the encoder. So your TV can't be harmed.

No I am not and that is what Inc tries to find out but as yourself, I'm sure sure about his conclusion :)

Take something taht is between 0-255, you can cut the part at both ends to have something between 16-235 or you can shrink the values (by a mathematical operation) to tuen then 0-255 into 16-235. First is clipping, second is scaling.

Did some tests with the movies kwag made.

There are some differences:

Luma scale: TMPGenc uses a clipped scale of 16 - 235, HC uses 0 - 255.
Took the same frame (both B-frames) and put them online:

TMPGenc frame: http://hank315.dyndns.org/KVCD_TMPGenc.jpg
HC frame: http://hank315.dyndns.org/KVCD_HC.jpg

Bitrate: Bitrate distribution looks almost the same but what puzzles me is the difference in the quantisation values. All settings seem compatible, this would mean the TMPGenc encoding should be much better because of the lower Q values but I can't see that big difference.

Please look at: http://hank315.dyndns.org/KVCD_bitrate.jpg

I never used TMGenc so don't know the settings but it seems it uses some kind of filtering so the content can be compressed more easily.

grtx. hank

There something else that puzzle me in all these snapshots : in both cases (audioslave post and now in yours, hank) the picture form tmpgnec does not have the same A/R (or resolution, I don't know) than the one form HC !
It's very obvious when you open it in two tab under mozilla and change from one to the other.

Is that normal ?

Just did a clipping cut somewhere in the black bars (vertical direction), just checked it but the originals are really equal.

EDIT: only equal in size :)

@Hank
Is it possible for you to add a "Luma Selector" in the new HC version? From my experience a luma scale of 16 - 235 looks much better than 0 - 255 when viewed on a TV screen.

@Dialhot
About the aspect ratio: The screenshots I posted looks, and are, identical in regards to the AR?! But, the ones that Hank posted were different... :roll:

@Hank,

Feature request: Could you add 3:2 "Pulldown" on a future release :?:
It would be nice not to have to run the .m2v through pulldown.exe after encoding :)

Also, I second Rui's comments about avalon. He was kicked out of this site for stealing other people's work and claiming it was his work, and it's all well documented in this forum.
Just wanted to let you know ;)

-kwag

Ok Phil,
I'm still digesting what you posted and I am having a hard time to understand it. I will post details about it.
But what puzzles me the most is that you're actually very strong when you say tmpg clip is darker than HC clip.
And that both audioslaves's pics are different in A/R.
I can't understand how you're getting such differences.
For me it is very clear that tmpg is darker than HC.
It may or not be related to luma/chroma different scales but tmpg looks darker.
I don't know if it's my eyes or if it has something to do with my screen but that's what I got.
On the matter of audioslaves pictures, whichever way I open them and compare them I find the A/R to be the same/identical.
So I'm feeling very bad if it's only me getting this result.
Or is there anybody else in here having the same results?
I know that we're comparing oranges with apples but this is really what I got and I am having a hard time to tell my eyes and my brain that it is not.
I will get into details further on today.
I'm in a hurry to get to work ;-)
BTW it seems to be useless to post any comparisons between encoders until I get them to work in exact same conditions.
So I'll only post my results after I understand all that is going on here.
TIA Phil
Cheers

:D Okay.

I am talking about the SNAPSHOTS (png files). I did not DL the clip (m2v files).

Not the snapshots from audioslave :-).

I just checked with Audioslave's one and they are identical (in size) "today" :-). I think I had a problem on my PC with an "autozoom" extension for Mozilla that did not show the picture at 100% size. So drop this point. But the tmpgenc snapshot is still lighter ! ;-)

As HC continue to hangs on the second open of the same avs on my PC, I can't do anything but wait for the next release.

Hank ?

Another bad call from me :(
Because I was not trying to refer to the clips (m2v's) :arrow: I was trying to refer to audioslave's png pictures.
Using my home PC and my work PC I see Tmpg's picture darker than HC's picture :sad:.
Will someone else please report about these pictures, please?
Anyone, please.

Good, at least we made some progress on the AR :arrow: we now see the same thing and have the same opinion about it.
As to the picture's darker/lighter I already expressed myself above.

That's odd.
Anyone else with same issue?
I can open as many avs as I want :roll:
I guess you would be using a simple Mpeg2Source() and not many options right?
That is, you've tried HC on more than one script, right?
Any clues on this one Hank?

Listen, I took the left part of the tmpgenc snapshot and put beside it the right part of the one from HC. If you continue to see the left darker than the right, then we have a english problem :-)

http://www.digitalfaq.com/archives/error.gif

What can I say :roll:
I don't think that I can clearly say something about that picture.
If I take a look at the ground's color (orange dust) I would say that it looks darker on the left side than on the right side...
But it's a tough call because it could be just like that in the source ;-)
My terminology assumptions:
Darker: meaning that colors tend to get closer to black than to white. Usually harder to see details.
Lighter: meaning that colors tend to get closer to white than to black. Usually easier to see details. As if a spot light was illuminating the subject.
Are these assumptions correct?
I am almost ready to accept that I am wrong here :twisted:
Will somebody else please say what they think about this color dark/light issue?
Cheers

Lol. Look at the original pictures : the sand is darker on the right than on the left for both picture ! The light is not uniform in all the picture :-D
Please rui, do open the two pictures in 2 tab and switch from one to the other, tmpgenc is definitely lighter !

We never talked about the source. The point here is just "one is lighter than the other" with no assumption on which one is correct and which is not.

Yes.

The logic of the file buttons isn't very good ATM, this will be solved in the next version, also Avisynth errors will be reported.
But starting the encoder again and opening an AVS file should work.
I hope to finish the new GUI in about a week, most of the errors are already solved and the preview section is almost finished.

About all the other questions, everything is possible if I could find the time...

Now I'm going to code all evening :lol:

grtx. hank

It is not the case on a win2000 PC and a script using avisource. The GUI hangs for ever insteed on the second load of the avs. You have to reboot to restore the situation.

That's why I said I wasn't sure when you posted your pict with two halfs of the 2 original pictues ;-)
That's mostly what I've been doing, I assure you.
But!...this last time that I opened both pics side by side, I thought about the definition of darker and lighter.
Darker with stronger colors and less defined details.
Lighter with weaker colors and more defined details.
That's when I saw that I have always been looking at the top of the picture, especially to the sky.
It appears to me that the sky is lighter on HC's pic than on tmpg's.
But then I took a look at the trees, wagon, floor and I saw what you've been trying to tell me all this time.
On tmpg's pic I can clearly see the top of the trees on the left side, and the details of the left side wagon back door.
I cannot do the same on HC's pic.
And I also saw that the floor's orange color is weaker on Tmpg's pic.
So now I'm starting to think that you were right all the time.
But what about the sky???
Why is it clearer on HC's pic?
Maybe this isn't really a darker/lighter issue.
Maybe this has something to do with color saturation or contrast or whatever.
But now if you tell me that Tmpg's pic is lighter, I will nod 'yes' :mrgreen: even if I'm not 100% convinced that it has to do with dark/light ;-)
So sorry about that, old fellow :oops: :lol:
What is absolutely true, although I think it would be wise to proove which one is closer to the source :arrow: not just the pics :arrow: the whole movie clips.
But I'm sure you'll guess that it is tmpg's the closer one.

@Hank
Sorry for going so much off topic here buddy.
Now that we're getting very close to the bottom of it, and if we proove that HC encodings are darker than the sources, I wonder if you could add to the very bottom of your to-do list a feature to cut (or scale or whatever) the luma/chroma levels to TV set acceptable ranges?
One other thing: I've noticed that when I load HC encodes in bitrate viewer it always reports "Nom. bitrate: 9800000 Bit/Sec" even if I set the max bitrate for 5.000.000 or 8.000.000.
That hasn't represented any problems when muxing or anything (why should it, right?).
But just in case, could you take a look at it one of these days?
And maybe it would be nice if HC could change the framrate on the encoded clip. I don't need it but others might find it cool.
I know :!:
We should start a thread for the wish list ;-)
Now how about that? :)
Cheers

Hey Rui,

My samples were just to show HC's good motion estimation :!:
Not to cause a color space havoc :rotf: :lol: I'll answer that :)
You can use DVDPatcher to "Brand" the mpeg file to whatever you want ;)

-kwag

I wanted to tell in my last post than light/dark was not the good word. This is more about vivid or not. "Vivid" is a combination of luma and saturation. So you're right :)

When I look at the pictures I really don"t know. Mainly because I found the (darker) HC picture more pleasant to watch so I have the whish this is the correct picture :?

@Karl
The samples reveals others things, it is not void to discuss these point also.

Yes, it's fine :)
But that was not my intention :cool:

-kwag

Tried to replicate this error but my PC runs all tests OK, running XP, SP1. Never got it so far that I had to reboot...
Think (hope) the next version will solve all this.

About the 9800000 bits issue: this has a relation with the size of the VBV buffer which I set at the maximum. And yes, you could run into trouble if you want to mux it with multiple high bitrate audiostreams but AFAIK the muxer will look at the actual bitrate and not this bitrate value.
It's just a maximum value, the upper bound of the coded data which is fed into the VBV buffer.
But please, correct me if I'm wrong on this, it can easily be changed.

A comparison is difficult because of the different Luma scales.
I found the HC pics also more pleasant to watch, not because it's my own encoder, still try to be objective :D .
But, I watch them on my PC screen, on a TV screen it might be completely different.
With CCE you can also choose a 16-235 scale, but it will not produce the same "foggy" output as TMPGenc, still think it's some kind of filtering...
But again, don't know that much of TMPGenc, it's just a first visual impression (on a PC-screen :wink: )

This is why it not sure if tmpgenc simply clip values to 16-235 or scale them to 16-235!

Damn, I'm glad we got this one sorted out :D
Don't ask me why but I get the feeling we'll come back to this matter again in the near future ;-)

So do I Phil, so do I ;-)

@Hank
The only question is if you had already thought about this luma/chroma cutting/rescaling matter.
Would it be hard to implement it on HC?
Just from the theoretic point of view, if you know what I mean?
Because we may come to the bottom conclusion that HC is better than the other encoders we usually use, but that we won't be able to use 'cause it lacks such a feature.
Since we're still starting our testings I don't think it will be a big issue for now.

Cheers all

CCE doesn't touch the range unless you feed RGB data in it, no matter what the setting is.

My guesstimate is that TMPGEnc does something similar to ColorYUV(mode="pc->tv") because that produces a washed out look at least in my eyes.

Hey Phil, do you remember that issue on TmpgEnc and the tests I made, I'll have to search for that Thread.

IMHO an encoder only should "crop" the luma range IF a conversion to a 16-235 Luma Range is wanted. And also an option that leaves the luma as it is should be present in an encoder. We mainly use Avisynth as Input where an already right Luma Range should be the output out of the script.

Beginners could affect their luma range in a fatal way if the source is already correct 16-235 which "could" be again scaled to less bandwith IF that 16-235 scale choice is given in the encoder.

:)

Ok, I know I've said here that I would present my tests to you guys, but I can't.
I can't make Tmpg and HC present the same kind of Luma/Chroma levels :(
No matter what I do they are always different and that must have an impact with the quality they spit out.
Nevertheless here is a small resume of my latest run.
Same Avisynth script used on both encoders:
This script gives me a 2 percent of the whole movie via Incredible's Slicer function.

TMPG

Clip Size: 32.092KB
Elapsed time: 8m32s

Video Settings

Stream type: MPEG-2 Video
Size: 720x576
Aspect ratio: 16/9
Frame rate: 25
Rate control mode: 2-pass VBR
Max bitrate: 8000
Avg bitrate: 1803
min bitrate: 400
Padding: enabled
VBV buffer size:224
Profile & level: MP@ML
Video format: PAL
Encode mode: Non-interlace
YUV format: 4:2:0
DC componente precision: 10 bits
Motion search precision: Motion estimate search (fast)

Advanced Settings
Video source type: Non-interlace(progressive)
Field order: Top field first (field A)
Source aspect ratio: 4/3 628 line (PAL)
Video arrange method: Center

GOP structure Settings

Number of I pics in GOP: 1
Number of P pics in GOP: 5823
Number of B pics in GOP: 2
Output interval of sequence header: 1
MAX number of frames in a GOP: 15
Closed GOP: disabled
Detect Scene change: enabled
Force pic type setting: disabled

Quantize matrix Settings

"The Notch" as per template
Output YUV data as Basic YCbCr not CCIR601: enabled
Use floating point DCT: enabled
No motion search for still pic part by half pixel: disabled

HC

Clip Size: 31.646KB
Elapsed time: 10m01s

---------------------------------
| HC - MPEG2 encoder - rel. 0.1 |
---------------------------------

input: D:\SPIDER2\D2V\SP2.AVS
output: D:\SPIDER2\D2V\SP2.m2v
log file: D:\SPIDER2\D2V\SP2.log

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

profile: BEST
frames: 1 3645
framerate: 25.00
aspect ratio: 9:16
bitrate Kb/s: 1803
max. bitrate Kb/s: 8000
restart: no
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: no
goplen,B-pic: 15 2
dc_precision: 10
scan method: ZIGZAG
time code: 0 0 0 0
CPU: MMX/SSE
matrix: NOTCH

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

nr. of frames in source: 3645
width*height: 720*576
fps: 25.00
nr. of frames to encode: 3645
frames to encode: 1 - 3645
movie length to encode: 0:02:26 (145.80 s)
est. outfile length: 32860 kB

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

pass 1 encoding time: 0:07:12 (432 s)
average fps: 8.4

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

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

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

pass 2 encoding time: 0:02:47 (167 s)
average fps: 21.8

total encoding time: 0:10:01 (601 s)

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

intra matrix used
8 9 12 22 26 27 29 34
9 10 14 26 27 29 34 37
12 14 18 27 29 34 37 38
22 26 27 31 36 37 38 40
26 27 29 36 39 38 40 48
27 29 34 37 38 40 48 58
29 34 37 38 40 48 58 69
34 37 38 40 48 58 69 79

non-intra matrix used
16 18 20 22 24 26 28 30
18 20 22 24 26 28 30 32
20 22 24 26 28 30 32 34
22 24 26 30 32 32 34 36
24 26 28 32 34 34 36 38
26 28 30 32 34 36 38 40
28 30 32 34 36 38 42 42
30 32 34 36 38 40 42 44

nr. of gops: 278
nr. of frames: 3645
nr. of I-frames: 278
nr. of P-frames: 1065
nr. of B-frames: 2302
average quant (non linear): 10.306
VBV underflows detected: 0
VBV underflows fixed: 0

HC Pics
B Frame
http://www.digitalfaq.com/archives/i.../2005/02/2.png
P Frame
http://www.digitalfaq.com/archives/error.gif

TMPG Pics
B Frame
http://www.digitalfaq.com/archives/error.gif
P Frame
http://www.digitalfaq.com/archives/i.../2005/02/3.png

Do check the skateboard guy's face and the skate board.
HC picture looks blockier than tmpg.
But the key word here may be "looks".
Since both are not working with the same luma/chroma there may be an advantage on one of the encoders...
Cheers

Hi Rui,

Have you tried making a pseudo AVI from the .d2v with VFAPIConv :idea: :?:
Then processing this avi with both encoders.
This would discard any AviSynth colorspace/brightness/contrast issues, by just delivering the unfiltered frames to both encoders.

-kwag

No I haven't.
But as far as I'm aware, HC can only load d2v projects and avs scripts.
So I don't see how I can load an avi (even a pseudo) in HC.
And from the results I already posted I'm affraid I'm comparing apples with oranges, such as Phil has already pointed out.
One thing seems to be clear to me: B frames and P frames compression should be improoved on HC.
Maybe it's using some extra bits in I frames that Hank could use in B and P.
I say this because quality wise HC's I frames are as good as Tmpg's I frames or maybe even better.

OT
I'm affraid I've been doing a terrible mistake because all my encodes are really darker than the source when I open them in VDubMod.
Now I remember Jorel's posts concerning this issue.
I'm stoping KDVD encodes until I can understand what's happening here.
/OT
Cheers

Just finished a new version: HC 0.11 beta

Changes:
- GUI updated, many bugs fixed
- preview option added
- TFF/BFF flag added for interlaced encoding
- shows Avisynth script errors
- max. bitrate is written in sequence header instead of 9800
- minor changes in bitrate control for bitrate < 2000 kb/s
- AUTOGOP option didn't work if scene change detection was switched off, fixed
- bitrate now in kb/s, m2v file size in Kbytes (1 kbit = 1000 bit)
- MPEG matrix is set as default matrix

get it at: http://hank315.dyndns.org/HC_011.zip

Thanks to Amnon, dragongodz and scatha for testing and feedback.

Nothing really changed in the encoding engine except for bitrates < 2000 which should give a slightly better result.

I wondered what is this AUTOGOP. Can you tell us ?

This feature was meant for DVD creation, GOP sizes will be 15 or less.
While encoding HC "caches" source frames and analysis them for scene change detection and the amount of "action" of the frames.
If the action is low the GOP will look like IBBPBBPBBPBB...
In high action scenes the GOP will look like IBPBPBPB...
P frames will be better predicted because they are closer to the last I or P frame and will be smaller, also B frames can be predicted better, that's the general idea, a variable GOP structure.
Did a lot of tests with it and in my eyes it really works :)

Variable GOP is a great feature Hank :D
Your encoder is looking very amazing :cool:
I assume if I set the GOP to 18, and then select "autogop", the GOP size will vary from a minimum preset value, to the GOP size you select under "length" :?:

Thanks,
-kwag

Just a note Hank.
After reading you "changelog.txt" file, I noticed that you changed the bitrate to represent 1000 bits :!:
In communications and engineering, 1 Kilobit is defined as 1024 bits :)
You had it like that on your 0.10 release, but I don't know why you changed it 8O

http://www.webopedia.com/TERM/K/kilobit.html
http://simple.be/tech/reference/bit

Leaving it set to 1000 bits is going to throw off several (most!) video bitrate calculators ;)

-kwag

No, the maximum GOP length will be 15 to be PAL-DVD compliant but I'm planning to do a complete workover of the bitrate control and maybe it can be used for longer GOPS as well.

About the kbit/Kbit issue, also had this discussion with dragongodz, seems most people prefer 1 kbit = 1000 bit which seems to be "normal" in video-land. The method in the first version was probably best, simply put in the nr. of bits but it had so many zero's...
Maybe it should be an extra input option :)

grtx. hank

Ok, I just thought that if I did set it to 18 it would use 18 as max, because 18 is the max for NTSC. So we would get a little more compression on NTSC if 18 was allowed :) Normal, where 8O :?:
All bitrate calculators, FitCD, MovieStacker, my own CalcuMatic, etc, use 1024 as reference :!:
I don't know where they got that "1000" bits.
If I ever said that 1 Kilobit is 1000 bits, where I work, I would probably get fired :D But then 1024 bits won't be divisible by 128 bytes to produce "8" which is the bits per byte.
It would produce 7.8125 :!: :o
Oh well, we could go on and on to nibbles, endian order and bit splicing :oops: :mrgreen: :lol:
So a 1000/1024 option would be cool ;)

-kwag

@hank

Hi! Great job! I just wonder how I set up a .mtx custom matrix to use in HC Encoder. What about a matrix template, so I just have to modify it? :D

Keep up the good work,

To be honest, for me a Kbit = 1024 bits but apparently some idiot came with the stupid idea that 1000 is easier :roll:
(Can you really splice a bit, please tell me the secret, just means better compression :D )

I know but I live in PAL land :)

It just uses plain ascii code, just save the default intra custom matrix and use an editor to see the format and edit and save it.

OK, mate! I did suppose to be that the correct procedure, but I was unsure.

Thank so much!

Now, I'm gonna work! :D

Keep up the good work,

:rotf: I knew you were going to jump on that one :lol: :lol:
Don't ballet dancers "splice" a "bit" :?: :lol:

-kwag

@hank

Hi! I just ran a test using the actual HC release and I' ve to say that the image quality if very, very, very good! I' m impressed :!:

By the other hand, it is still slow compared with other (CCE, MainConcept, NuEnc, FreeEn). My processor is a Athlon XP 2500+@2GHz ("Barton" Kernel with 512 KB de cache L2). The speed went about 16 fps, while with other ones I get about 40 fps ... 8O

Only question: in "constant quantization" mode, what's the range of Q variance?

My respects,