Quote:
|
Quote:
Don't ask me why but I get the feeling we'll come back to this matter again in the near future ;-) Quote:
@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 |
Quote:
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. |
Quote:
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: Code:
Mpeg2Source("D:\SPIDER2\D2V\SP2.d2v") 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. |
Quote:
|
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 :) |
Quote:
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 Code:
Kilobit = 1 Kilobit http://simple.be/tech/reference/bit Leaving it set to 1000 bits is going to throw off several (most!) video bitrate calculators ;) -kwag |
Quote:
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 |
Quote:
Quote:
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 Quote:
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, |
Quote:
(Can you really splice a bit, please tell me the secret, just means better compression :D ) Quote:
|
Quote:
|
Quote:
Thank so much! Now, I'm gonna work! :D Keep up the good work, |
Quote:
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, |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.