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
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

__________________
Rui

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

P Frame


TMPG Pics
B Frame

P Frame


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

__________________
Rui

Hi Rui,

Have you tried making a pseudo AVI from the .d2v with VFAPIConv
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

__________________
Rui

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
Your encoder is looking very amazing
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

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
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 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
Oh well, we could go on and on to nibbles, endian order and bit splicing
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?

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
(Can you really splice a bit, please tell me the secret, just means better compression )

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!

Keep up the good work,

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

-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 ...

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

My respects,