View Full Version : Who wants to test a new MPEG2 encoder
Pages :
[
1]
2
3
4
5
6
7
8
9
10
hank315
25th January 2005, 21:30
For some time I've been working on a MPEG2 encoder,
maybe there's somebody who want to run some tests with it.
Some information about the encoder (named HC):
(complete manual is included)
Input can be a d2v project or input using Avisynth.
GUI version and batch version.
The encoder should run on any Intel and AMD processor using Windows XP/2000.
At least MMX/ISSE must be present to run the encoder.
If SSE2 or SSE3 is present HC will also use it.
2 pass VBR encoding.
Variable GOP structure dependent of the video content or fixed GOP structure.
Scene change detection.
Pre-programmed matrices or use your own matrices.
Restart possibility to run the second pass again.
Bitrate control: average and max bitrate can be set.
Buffer underflows will not occur, the VBV is constantly checked so no bitrate spikes.
Complete package: http://hank315.dyndns.org/HC_013.zip 0.13 beta version, last update 17-04-2005
Please remember that it is a work in progress... there may be a few bugs :)
Ebobtron
26th January 2005, 08:58
I don't know what to say.
Configuration technique is unique and might even be elegant. Might be hard to do batch encoding, but I can write ini files from a batch file.
I still have testing to do but the stream looks compliant.
I test scene detection with music videos. The cuts are often quick and complex. A quick look at the first 15 cuts of my test video have me at a loss for words. In short, for now, HC appears to be dead accurate. Original video sometimes misses scene change by a frame or confuses large motion for a change. Your encoder hits the scenes a major motion picture release on DVD misses.
Quality looks very good.
And yes, bugs. I'll post logs and bug-list tomorrow.
Thanks for your help before. I do lots of NTSC.
Ebob
video_magic
26th January 2005, 09:15
;) I had downloaded last night but can't test yet because I have another big mpeg2 encode running at the moment with Nuenc, but I look forward to running a clip through yours after that finishes.
Nic
26th January 2005, 10:47
Is this written in Fortran?
If so. Very Hardcore. :)
Haven't tested it yet...I'll let you know.
-Nic
ps
May I ask what your future plans are for your encoder?
i.e. Going to go opensource, commercial, freeware, just doing it as a hobby etc...Either way, good luck :)
hank315
26th January 2005, 13:15
Is this written in Fortran?
If so. Very Hardcore.It is written in Fortran95
+ a little C code to communicate with DGdecode.dll and Avisynth
+ about 6000 lines of assembler, mostly MMX/SSE/SSE2 stuff
Hardcore, LOL.. that C stuff guys are writing here, that's real hardcore.
I've always programmed in Fortran, had to, when I started there was no C.
In the 80's I tried C but it was a great dissapointment, compilers were buggy and slow and the generated code was buggy and slow.
Nowadays a lot has changed, with C you can do everything and it is (almost) as fast as Fortran :), but for writing this kind of applications I'll just stick to Fortran.
May I ask what your future plans are for your encoder?
i.e. Going to go opensource, commercial, freeware, just doing it as a hobby etc...Either way, good luck I was just curious how the MPEG compression scheme works.
Also I was surprised to discover that all encoders are (very expensive) commercial codes or based on ffmpeg or mpeg2enc so I decided to start from scratch and not to look at the open source C code (which in my case wasn't so hard because I can hardly read the stuff :) )
So it started as a hobby...
open source - probably not, most people will not understand or can compile the Fortran sources
freeware - probably
commercial - unlikely, but come on guys, make me an offer I can't refuse:D
It was also a good exercise to start writing a H.264/AVC encoder.
Future plans for HC:
- Speed and quality improvement and getting all the bugs out
- Support for hyperthreading and multi-processing systems
- Writing a GUI but I really hate that!!
Nic
26th January 2005, 13:25
Very impressive.
If you really don't fancy making a GUI for it...Could you not make a DLL out of your Encoder, so that it could be fed the parameters and YV12 frames? That way I could plug it into QuEnc ;)
Good luck finding bugs, and you're right, I doubt many could follow the Fortran code. :)
Take Care,
-Nic
mean
26th January 2005, 16:16
... and building a .so for the nix guys :)
Ebobtron
26th January 2005, 18:35
Bug report:
------------------
Opening command window reports frame-rate incorrectly under encoder settings. Reports correctly under source stats. Output to log is correct.
-----------------------------------------------------------
--------------------> encoder settings <-------------------
-----------------------------------------------------------
input: faithv.avs
output: Faith_HC_T04.m2v
log file: Faith_HC_T04.log
profile: GOOD
frames: - end
framerate: 25.00 <---------------
aspect ratio: 9:16
bitrate: 8000000
max. bitrate: 8000000
restart: no
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: yes
goplen,B-pic: 15 2
dc_precision: 9
scan method: ALTERNATE
CPU: SSE2
-------------------------------------------------
Sequence header reports bit-rate as 9800000 always.
Sequence header reports first GOP-timestamp as 1h 0m 0s 0f.
----------------------------------------
Flashing pink or sometimes green horizontal line in bottom right of displayed video. Bad lines are in odd fields only even fields look great..
------------------------------------------
Seems that CPU Auto doesn’t select SSE2 my max. But not sure.
----------------------
More later
Ebob
hank315
26th January 2005, 20:36
Opening command window reports frame-rate incorrectly under encoder settings. Reports correctly under source stats. Output to log is correct.
: 25.00 <---------------Will be corrected in the next version, just wrote the default value to the screen.
Sequence header reports bit-rate as 9800000 always.HC just writes the max. value for the VBV in the video file to be on the safe side. Should be OK.
Sequence header reports first GOP-timestamp as 1h 0m 0s 0f.You wonder why? I also did and still do;)
Just took this value because most encoders do but couldn't find any information why (is there somebody out there who knows). Can easily be changed or an extra command to set the timecode.
Seems that CPU Auto doesn’t select SSE2 my max. But not sure.The encoder was developed using a P4 3.2GHz (Prescot core) which can use all of the present extensions, testing on all other systems always shows the right CPU but there was only one AMD machine amongst them (which was recognized as an AuthenticAMD, only MMX/SSE support). I'm just checking bit 0, 23, 25 and 26 with the proper calls to cpuid. If you choose a wrong extension, one your CPU can't handle, the encoder will crash or it will produce absolute rubbish. BTW, what CPU do you have?
Flashing pink or sometimes green horizontal line in bottom right of displayed video. Bad lines are in odd fields only even fields look great..That's a hard one, I'll try and reproduce this error. Would you try to encode that scene again with *INTERLACED turned of and see if its still there? My experience is it is better to use a de-interlace filter in Avisynth and then just encode it as progressive.
If you set the average bitrate equal to the max. bitrate you will not get the desired filesize. HC handles the max. bitrate in the next way: max. bitrate is controlled per GOP, if the actual bitrate > max. bitrate the GOP is recycled with higher quantization values until the actual bitrate <= max. bitrate. For low action scenes bitrate will be lower but it will try to catch up to reach the target but will never reach it.
Ebobtron
26th January 2005, 21:43
HC just writes the max. value for the VBV in the video file to be on the safe side. Should be OK.
Thought that was the case.
--------------------------------------------
I have a Intel Celeron @ 2.80GHz. It looked faster when CPU set to SSE2 than Auto. I'll check again with same source.
If you choose a wrong extension, one your CPU can't handle, the encoder will crash or it will produce absolute rubbish. BTW, what CPU do you have?
Your right it crashes.
-----------------------------
I'll try some deinterlaced stuff.
------------------------
I was comparing other encoders with the 8000 8000. Some encoders spike over, yours doesn't.
Ebob
hank315
26th January 2005, 22:38
@NicIf you really don't fancy making a GUI for it...Could you not make a DLL out of your Encoder, so that it could be fed the parameters and YV12 frames? That way I could plug it into QuEnc ;)I think that could be done fairly easily, but call it masochistic behaviour, I just want to give it a try and write such a :devil:GUI-thing. And maybe after a while, when I'm totally frustrated banging my head against the Windows GUI wall, I will beg you on my knees to implement it in QuEnc:)
Anyway, thanks for the offer but let's not be too hasty, I'll wait for the tests people will do and first resolve the most bugs.
PS. I really like your latest (0.59) build, great quality, used it to do some comparisons with HC.
Ebobtron
27th January 2005, 08:48
Flashing pink or sometimes green horizontal line in bottom right of displayed video. Bad lines are in odd fields only even fields look great..
Originally posted by hank315
That's a hard one, I'll try and reproduce this error. Would you try to encode that scene again with *INTERLACED turned of and see if its still there? My experience is it is better to use a de-interlace filter in Avisynth and then just encode it as progressive.
If I encode a PAL clip no lines. If you change your source resolution to 720x480 I think you will see the lines. Non interlaced clips have the llne each frame if 720x480 used.
-------------
Let me show you how new to this hobby I am by asking this question.
Why would I want a DVD compliant video stream that is progressive?
I never encode film and all my stuff is intended to be burned as a DVD for viewing on my television or my mom's TV.
Am I not going to be able to tell the difference?
Off to see if I can break your new toy.
Thanks,
Ebob
Amnon82
28th January 2005, 16:40
@hank315: Your Encoder looks great! It has all features a MPEG2Encoder should have.
So You don't like Guis. If You want I can code a GUI for You. I'm coding in Delphi.
The Support of CQ-Values is great. I'm thinking to code AutoCQ for HC.
I did the program for CCE. It finds the right Q-Value for onepass-encoding.
I play a little with Your encoder and code a little GUI. I write You a PM.
... when do You release a non-limited test-version?
hank315
28th January 2005, 21:19
@Amnon82
Nice you like it, and I realize a GUI would be a good thing too.
But I'm also trying to program one (in Fortran).
I know when people hear about Fortran some of them still think we are carrying boxes of punchcards:)
The Fortran I'm using is Compaq Visual Fortran 6.6c which is totally integrated in Visual Studio 6.0.
The GUI I have in mind will look like: http://hank315.dyndns.org/GUI_template.jpg
It's not finished yet but some of the logic already works and it is also nice to cleanup the input part which has become a mess...
A full version will be posted soon, maybe even tonight.
And ofcourse feedback which might improve the encoder is always welcome.
@mean
I'm pretty much a complete Linux NOOB and don't have a Fortran95 compiler for Linux. There's an experimental compiler ( http://www.g95.org ) but the speed of it isn't optimal yet.
But if the GUI-Windows version is up and running I will give it a try.
hank315
28th January 2005, 22:23
Just put a version online without the 30000 frame limit.
No GUI yet, still working on it.
There are still some limitations, the max. nr. of GOPS is 64000 so you will run into a trouble if your movie is over 8 hours...
get it at http://hank315.dyndns.org/HC.zip
Have fun with it:)
Amnon82
28th January 2005, 22:36
I didn't looked at Your JPG.
Here is my Design-Sample #1. Hope You like it:
Go to the HC.GUI Thread (http://forum.doom9.org/showthread.php?s=&threadid=89101)
I started a new thread to keep this clear.
@Hank: did You add the AutoEncode and AutoClose Feature I asked for?
I'll need it to start my project AutoCQ for HC. It will get the right CQ-Value for the 1Pass VBR-Encode. I did some good results with the AutoQ for CCE Version.
Its good to see that You code it also in GUI. So Beginners will have it easier.
Keep the INI-Files. They are like ECL-Files for CCE.
I stay tuned for Your project. You have me 100%!
Lets play with Your last release.
... still missing the 2 functions ...
I can do the first <Enter>-Button request, but not the second. So the AutoEncode and AutoClose Functions are needed to code addons or external GUIs for Your encoder.
I'm working now on a little workaround. I call the little app 'BatchHC'. It do the 2 Enter-Commands.
unixfs
29th January 2005, 12:39
Hank315,
I just tried a 30 minutes encode of a full frame 720x576 dvb capture.
Simply put, it seems HC is absolutely the best mpeg2 encoder
I've seen so far!
Image quality (at 1600 kbps) is simply excellent, and you seem to
have found the way to avoid the most common artefact that all
other common encoders produce: blockyness in uniform or dark areas.
I really hope you will release your source code with an opensource license,
so that it can be used with other encoders like mencoder.
open source - probably not, most people will not understand or can compile the Fortran sources
There is a fortran compiler for *nix, released with gcc sources
(although it doesn't have a good fame).
Thanks a lot!
Hemmo
29th January 2005, 13:02
Hank315:
I just tried HC with one chapter from Matrix and I very happy to the result !
I hope HC will stay freeware ?
Amnon82
29th January 2005, 13:42
New Version Released: http://hank315.dyndns.org/HC_0.01.zip
Hank315 adds the *BATCH - Parameter.
How it works? Take a look into AutoCQ 0.2.0
Mug Funky
29th January 2005, 15:45
wow, now i know never to skip the mpeg-2 forum for more than a couple of days :)
open source - probably not, most people will not understand or can compile the Fortran sources
i don't know about that... my brother still uses fortran77 (he was born in 1980, go figure). he's never at a loss for a compiler in 'nix. does most of it for RISC processors though.
i can't code to save myself though.
but anyway, another opensource encoder can't possibly be a bad thing, especially if the quality is what people are saying it is (haven't had a chance to test yet).
of course it's most definitely your call, and freeware would be fine too.
k, now i'm going to test this baby :)
thanks heaps for your work.
[edit]
hmm.. what's a reasonable amount of time it should be on "intermediate pass" for an 823 frame clip? it's been on it for nearly 10 minutes now.
running a p3 733 (SSE1, MMX)
freelock7
29th January 2005, 19:18
Great results at the beginning of its development.
Tested 2pass.
Great quality up 3000kbs.
A little bit slow (7Fps).
Good job Hank315.
unixfs
29th January 2005, 19:41
wow, it's even working with avisynth under wine, and without slowdown
hank315
30th January 2005, 00:59
@Mug Funky
hmm.. what's a reasonable amount of time it should be on "intermediate pass" for an 823 frame clip? it's been on it for nearly 10 minutes now.That should be done in no time, with normal settings it should do the intermediate pass in just a few seconds for a 2 hour movie.
For very high or very low bitrates it might take longer but not that long.
Could you post your HC.ini file please.
freelock7
30th January 2005, 11:07
Sorry!
Here my script:
*PROFILE GOOD
*INFILE C:\Documents and Settings\Pierre\Mes documents\DVD.avs
*OUTFILE C:\Documents and Settings\Pierre\Mes documents\out.m2v
*LOGFILE C:\Documents and Settings\Pierre\Mes documents\out.log
*FRAMES 1 219715
*BITRATE 2500000
*MAXBITRATE 8500000
*ASPECT 16:9
*CQ 4
*MATRIX C:\Program Files\AutoCQ\matrices\AutoQ1.aqm
*RESTART
*NOSCD
*CLOSEDGOPS
*GOP 15 2
*CPU SSE
*SCANMETHOD ZZ
*PROGRESSIVE
First pass between 7-12 fps
second pass about 22 fps
The average prediction is correct with a global Quantizer Factor=11.05
Many blocs in picture- like a grainy movie.
QuEnc has a better texture quality at 2500 than HC because it uses for the same bitrate average a global Q factor of 6.5.
That makes the difference!
You should work in this way to decrease the quantization at low bitrate.
Hemmo
30th January 2005, 11:21
Originally posted by freelock7
...Many blocs in picture- like a grainy movie...
Have you try with:
*PROFILE BEST
*INFILE C:\Documents and Settings\Pierre\Mes documents\DVD.avs
*OUTFILE C:\Documents and Settings\Pierre\Mes documents\out.m2v
*LOGFILE C:\Documents and Settings\Pierre\Mes documents\out.log
*FRAMES 1 219715
*BITRATE 3500000
*MAXBITRATE 8500000
*ASPECT 9:16
*DC_PREC 10
so, replace HC.INI with that text and start HC.exe
freelock7
30th January 2005, 11:47
It doesn't change the quantization problem.
Too much compression at low bitrate with a quant=11 decreases quality.Test with 2Pass default HC encoding
--------------------------------
Bitrate Avg:3000kbs
Results:
max bitrate=6200
min bitrate=1200
Avg quant=9
----------------------
Bitrate Avg:4000kbs
Results:
max bitrate=8200
min bitrate=2100
Avg quant=7
----------------------
QuEnc0.59Beta2
Bitrate Avg:4000kbs
Results:
max bitrate=8500
min bitrate=2100
Avg quant=3.56
As you see, the global quantization remains high at 3000kbs even at 4000.
QuEnc have the best level balance between Bitrate and quantization.
The HC file is completely DVD compliant with Ifoedit0.976.
Amnon82
30th January 2005, 15:42
I coded a 1Pass Prediction-Tool for HC. So here is my first result of a 1Pass encode with HC Version 0.01:
HC.INI
*INFILE C:\Programme\AutoCQ\temp\AQFULLENC.avs
*OUTFILE F:\AutoQWork\OUT\AUTOCQ031_HC001.m2v
*LOGFILE F:\AutoQWork\OUT\AUTOCQ031_HC001.log
*CPU AUTO
*PROFILE GOOD
*SCANMETHOD ZIGZAG
*ASPECT 9:16
*BITRATE 8500000
*MAXBITRATE 9800000
*CQ 3
*DC_PREC 10
*GOP 12 2
*BATCH
*INTRAMATRIX
8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 35
19 22 26 27 29 34 35 38
22 22 26 27 29 34 35 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 50
26 27 29 35 40 48 50 60
27 29 35 40 48 50 60 62
*NONINTRAMATRIX
16 20 24 28 32 36 40 44
20 24 28 32 36 40 44 48
24 28 32 36 40 44 48 52
28 32 36 40 44 48 52 56
32 36 40 44 48 52 56 58
36 40 44 48 52 56 58 60
40 44 48 52 56 58 60 62
44 48 52 56 58 60 62 62
HC.LOG
-----------------------------------------------------------
------------------> HC - MPEG2 encoder <-------------------
-----------------------------------------------------------
release: beta 0.01
-----------------------------------------------------------
---------------------> parsing stats <---------------------
-----------------------------------------------------------
input: C:\PROGRAMME\AUTOCQ\TEMP\AQFULLENC.AVS
output: F:\AutoQWork\OUT\AUTOCQ031_HC001.m2v
output: F:\AutoQWork\OUT\AUTOCQ031_HC001.log
frames: 1 - end
aspect ratio: 9:16
bitrate: 8500000
max. bitrate: 9500000
constant Q: 3
interlaced: no
goplen,B-pic: 12 2
dc_precision: 10
scan method: ZIGZAG
intramatrix: 64 values read
non-intramatrix: 64 values read
-----------------------------------------------------------
--------------------> encoder settings <-------------------
-----------------------------------------------------------
input: C:\PROGRAMME\AUTOCQ\TEMP\AQFULLENC.AVS
output: F:\AutoQWork\OUT\AUTOCQ031_HC001.m2v
output: F:\AutoQWork\OUT\AUTOCQ031_HC001.log
profile: NORMAL
frames: 1- end
framerate: 25.00
aspect ratio: 9:16
bitrate: 8500000
max. bitrate: 9500000
pass: 1 (Constant Quant)
constant Q: 3
restart: no
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: no
goplen,B-pic: 12 2
dc_precision: 10
scan method: ZIGZAG
CPU: AUTO
intramatrix: 64 values read
non-intramatrix: 64 values read
-----------------------------------------------------------
---------------------> source stats <----------------------
-----------------------------------------------------------
nr. of frames in source: 135984
width*height: 720*576
fps: 25.00
nr. of frames to encode: 135984
frames to encode: 1 - 135984
movie length to encode: 5439.36 s
est. outfile length: ?????
-----------------------------------------------------------
-------------------> encoding - pass 1 <-------------------
-----------------------------------------------------------
pass 1 encoding time: 6566.7 s
average fps: 20.7
-----------------------------------------------------------
-------------------> encoding finished <-------------------
-----------------------------------------------------------
total encoding time: 6567.1 s
-----------------------------------------------------------
--------------------> encoding stats <---------------------
-----------------------------------------------------------
intra matrix used
8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 35
19 22 26 27 29 34 35 38
22 22 26 27 29 34 35 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 50
26 27 29 35 40 48 50 60
27 29 35 40 48 50 60 62
non-intra matrix used
16 20 24 28 32 36 40 44
20 24 28 32 36 40 44 48
24 28 32 36 40 44 48 52
28 32 36 40 44 48 52 56
32 36 40 44 48 52 56 58
36 40 44 48 52 56 58 60
40 44 48 52 56 58 60 62
44 48 52 56 58 60 62 62
nr. of gops: 11884
nr. of frames: 135984
nr. of I-frames: 11884
nr. of P-frames: 35021
nr. of B-frames: 89079
average quant: 3.000 (non-linear scale)
VBV underflows detected: disabled
VBV underflows fixed: disabled
AUTOCQ 0.3.1 LOG:
AutoCQ-Log
___________________________________________________________________________
21:02:06 - 29.01.2005 >> AutoCQ Version 0.3.1 (Build 03100) started...
21:02:09 - 29.01.2005 >> AVS loaded from: G:\AutoCQWork\avs.avs
21:02:14 - 29.01.2005 >>
21:02:14 - 29.01.2005 >> _________________________________________
21:02:14 - 29.01.2005 >> Project-Info:
21:02:14 - 29.01.2005 >> _________________________________________
21:02:14 - 29.01.2005 >>
21:02:14 - 29.01.2005 >> Desired Target: DVD 720x576
21:02:14 - 29.01.2005 >> Entered Bitrate: min. 8500 max. 9500
21:02:14 - 29.01.2005 >> Entered wanted size in MB: 4476
21:02:14 - 29.01.2005 >> Entered Audio size(s) in MB: 1000
21:02:14 - 29.01.2005 >> Entered Extras size in MB: 0
21:02:14 - 29.01.2005 >> Authoring and ISO overhead in MB: 117
21:02:14 - 29.01.2005 >> % of Movie will be used: 4
21:02:14 - 29.01.2005 >> Your desired final encoded sample in MB: 134
21:02:14 - 29.01.2005 >> Your desired final encoded file in MB: 3350
21:02:14 - 29.01.2005 >> Safe Mode disabled
21:02:14 - 29.01.2005 >> Encode after Prediction enabled
21:02:14 - 29.01.2005 >> _________________________________________
21:02:14 - 29.01.2005 >>
21:02:14 - 29.01.2005 >> _________________________________________
21:02:14 - 29.01.2005 >> Start Prediction-Run #1
21:02:15 - 29.01.2005 >> First Q-Value: 6 [1|18]
21:02:15 - 29.01.2005 >> First Frameoffset: 00
21:07:57 - 29.01.2005 >> Results of Prediction-Run #1
21:07:57 - 29.01.2005 >> Encoded Sample in MB: 68
21:07:57 - 29.01.2005 >> Wanted Samplesize in MB: 134
21:07:57 - 29.01.2005 >> Precalculated Finalsize in MB: 1700
21:07:57 - 29.01.2005 >> Wanted Finalsize in MB: 3350
21:07:57 - 29.01.2005 >> _________________________________________
21:07:57 - 29.01.2005 >> Start Prediction-Run #2
21:07:57 - 29.01.2005 >> Q-Value of this pass: 4 [1|6]
21:07:57 - 29.01.2005 >> Frameoffset of this pass: 12
21:13:47 - 29.01.2005 >> Results of Prediction-Run #2
21:13:47 - 29.01.2005 >> Encoded Sample in MB: 99
21:13:47 - 29.01.2005 >> Wanted Samplesize in MB: 134
21:13:47 - 29.01.2005 >> Precalculated Finalsize in MB: 2475
21:13:47 - 29.01.2005 >> Wanted Finalsize in MB: 3350
21:13:48 - 29.01.2005 >> _________________________________________
21:13:48 - 29.01.2005 >> Start Prediction-Run #3
21:13:48 - 29.01.2005 >> Q-Value of this pass: 2 [1|4]
21:13:48 - 29.01.2005 >> Frameoffset of this pass: 00
21:19:46 - 29.01.2005 >> Results of Prediction-Run #3
21:19:46 - 29.01.2005 >> Encoded Sample in MB: 184
21:19:46 - 29.01.2005 >> Wanted Samplesize in MB: 134
21:19:46 - 29.01.2005 >> Precalculated Finalsize in MB: 4600
21:19:46 - 29.01.2005 >> Wanted Finalsize in MB: 3350
21:19:46 - 29.01.2005 >> _________________________________________
21:19:46 - 29.01.2005 >> Start Prediction-Run #4
21:19:46 - 29.01.2005 >> Q-Value of this pass: 3 [2|4]
21:19:46 - 29.01.2005 >> Frameoffset of this pass: 12
21:25:33 - 29.01.2005 >> Results of Prediction-Run #4
21:25:33 - 29.01.2005 >> Encoded Sample in MB: 125
21:25:33 - 29.01.2005 >> Wanted Samplesize in MB: 134
21:25:33 - 29.01.2005 >> Precalculated Finalsize in MB: 3125
21:25:33 - 29.01.2005 >> Wanted Finalsize in MB: 3350
21:25:33 - 29.01.2005 >> _________________________________________
21:25:33 - 29.01.2005 >> Encoding Final-Sample [E < W]
21:25:33 - 29.01.2005 >> Final Frameoffset: 00
21:25:33 - 29.01.2005 >> Final Q-Value: 3 [2|3]
21:31:15 - 29.01.2005 >> Encoded Final-Sample in MB: 121,97
21:31:15 - 29.01.2005 >> Wanted Samplesize in MB: 134
21:31:15 - 29.01.2005 >> Precalculated Finalsize in MB: 3049
21:31:15 - 29.01.2005 >> Wanted Finalsize in MB: 3350
21:31:15 - 29.01.2005 >> Calculated Finalsize in MB: 3087
21:31:15 - 29.01.2005 >> Renamed final Sample to: F:\AutoQWork\OUT\AUTOCQ031_HC001.sample
21:31:44 - 29.01.2005 >> _________________________________________
21:31:44 - 29.01.2005 >> Start Fullencode
21:31:44 - 29.01.2005 >> Final Q-Value: 3
23:30:32 - 29.01.2005 >> Results of Fullencode-Run:
23:30:32 - 29.01.2005 >> Your desired final encoded file: 3350
23:30:32 - 29.01.2005 >> Final encoded filesize: 3106
Now my Compiletests:
DVDLabPro: After 30% muxing the M2V with AC3(2Streams)DTS(1Stream) Error: Not DVD compliant.
IFOEdit0.96: After 2 Sec Error: Bufferunderruns
Rejig0.56: Compiled the full DVD.
Then I watched the whole movie in WinDVD6. It was sync but jumps on every VOB-Change (I mean the 1GB-Files. Maybe a matter of Rejigs DVD-Author.).
Now I'm encoding the same movie in 2Pass with this INI:
*INFILE G:\AutoCQWork\avs.avs
*OUTFILE F:\AutoQWork\OUT\2PASS_HC001.m2v
*LOGFILE F:\AutoQWork\OUT\2PASS_HC001.log
*CPU Auto
*PROFILE Good
*SCANMETHOD ZIGZAG
*ASPECT 9:16
*BITRATE 5045000
*MAXBITRATE 9800000
*DC_PREC 10
*GOP 12 2
*INTRAMATRIX
8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 35
19 22 26 27 29 34 35 38
22 22 26 27 29 34 35 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 50
26 27 29 35 40 48 50 60
27 29 35 40 48 50 60 62
*NONINTRAMATRIX
16 20 24 28 32 36 40 44
20 24 28 32 36 40 44 48
24 28 32 36 40 44 48 52
28 32 36 40 44 48 52 56
32 36 40 44 48 52 56 58
36 40 44 48 52 56 58 60
40 44 48 52 56 58 60 62
44 48 52 56 58 60 62 62
dragongodz
30th January 2005, 17:15
Error: Not DVD compliant.
yep it isnt.
MAXBITRATE 9800000
muxing the M2V with AC3(2Streams)DTS(1Stream)
and thats why.
the 9.8Mb/s is max video bitrate for dvd specs but thats also if there is no audio or subs etc. add the total bitrates of the audio streams and minus them from the video max bitrate.
wait i hear you say, what about the 10.8Mb/s maximum ? that is the maximum of all streams muxxed together so includes muxxing overheads. easier to simply decrease the 9.8Mb/s by the extra streams bitrates. infact probably best to go slightly lower than that because the more streams the more overhead required aswell. :)
Rejig0.56: Compiled the full DVD.
yes Rejig isnt overly fussing compiling. mplex(which its based on) is generally over fussy and can complain about streams that are in spec so Rejig was made a little more forgiving. :)
Mug Funky
30th January 2005, 17:21
arch. never mind my post above - i had bitrate in kbps instead of bps. it's encoding now :)
Amnon82
30th January 2005, 19:14
@dragongodz: DVDLabPro show me the Bitrate as 4791 kbps of the 1pass CQ encode. and 5025 in the 2pass VBR encode.
The 2Pass VBR encode is DVD compliant.
hank315
31st January 2005, 01:12
Hi all,
ATM I'm very busy coding the GUI for HC which will be ready in about a week I think.
Maybe I should have waited to make the encoder public after writing a GUI but I wanted to know if the "community" liked the quality of the encoder.
After reading most messages some remarks:
- Please read the doc file and use only the commands in it.
- The *CQ command means a 1 pass encoding using Constant Quantization which may be not DVD compliant.
- Quantization used is nonlinear and can't be compared with QuEnc which uses linear q. scale code.
When the GUI is finished I think a lot of the problems will be solved so please be patient.
For the Linux guys:
With gcc I can compile Fortran77 stuff, it's converted into C and than compiled, not the best way to do it.
But HC is written in Fortran95 which gcc can't handle.
When the Windows GUI version is up and running I will try to create a version using the (experimental) g95 compiler, but I also read it runs using wine so all problems are already solved :D (nah, that's not the real thing).
About encoding speed:
I tweaked the settings in such a way that a (DVD backup) 2 hour movie should be done in 4 hours using the best settings and VBR 2 pass on my PC. I'm getting 15-20 fps in the first pass and about 50 fps in the second pass.
system: P4 3.2 Ghz Prescott which can use SSE3
But encoding interlaced DV stuff may take much longer especially in the first pass.
@Amnon82
I was wrong when I told you I hated GUI programming, I even start to like it, actually it's great fun;)
About the chapters, I tried that in previous versions but could not get it to work properly but it is certainly something worth to be implemented.
And this version will always be freeware (including the GUI version) but not open source.
marcellus
31st January 2005, 01:31
Hi hank,
I just 2 pass encoded a fragment and the result is very pleasant to watch.
Your encoder is pretty amazing. The quality is very high for a 0.01 release. For almost a year I use for my mpeg2 encodings only libavcodec based encoders because IMHO libavcodec have more quality than CCE especially at low bitrates (and my standalone is very forgiving with non compliant streams). Today I've seen a good competitor for libavcodec (with better and worse features). The most noticeable good feature for HC is, I don't know how to say, the "dithering", or "noising" of the areas in the picture where are blocks, making them less visible and less annoying. A good thing over libavcodec is, I think, the non-linear quantization.
On the other side why the HC encode has (acording to bitrate viewer) an average q of 8.87 with a peak of 11.92 and the one I made with ffdshow have 2.92 average q with a peak of 6.08? And I used the same q-matrix and of course, the same bitrate.
Still, HC is slower but not horribly slow.
Well done and I'm watching closely HC evolution.
Thanks for your hard work!
hank315
31st January 2005, 01:54
@Marcellus
Libavcodec encoders use a linear q scale, HC uses a non-linear scale.
That makes the difference in Bitrateviewer.
But ofcourse, a lot can be improved. At first the GUI should be completed which should it make easier for people to run HC.
After that I'll try to improve speed and quality.
It seems that HC runs pretty fast on CPU's which support SSE3 and have a large cache.
And about libavcodec, it is a very good encoder, I also used a lot but some older versions wouldn't run on my system or weren't stable. Also bitrate control (bitrate spikes) is still not optimal.
NuEnc does a good job but is IMHO very slow.
Macanudo
31st January 2005, 03:10
Does HC support High Definition resolutions?
As far as I know the only commercial mpeg2 encoder that supports HD is the newest version of MainConcept Mpeg Pro.
If HC doesn't already support HD and you are open to feature requests, this capability would be a great addition to your excellent encoder.
Thanks for the HC!!!
Macanudo
dragongodz
31st January 2005, 03:39
DVDLabPro show me the Bitrate as 4791 kbps of the 1pass CQ encode. and 5025 in the 2pass VBR encode.
Amnon82 - and i bet thats the average bitrate its reporting. this has nothing to do with what i was saying. its the peaks going over dvd spec thats causing underflows. when they go over the 10.08Mb/s (muxxed) they are out of dvd spec. some players(especially modern ones) will still play them by the way but thats not the point.
it is possible to do 1 pass VBV but its trickier. methods i have seen and read about include per MB rate control, per GOP(read and encode whole GOP in memory, if breaks VBV redo GOP in memory until it doesnt, then write that) etc. however doing a 1 pass constant quant doesnt do them.
And this version will always be freeware (including the GUI version) but not open source.
hank315 - it would still be nice to see a dll version though. ;)
Also bitrate control (bitrate spikes) is still not optimal.
understatement. its not not optimal, its plain bad. :)
NuEnc does a good job but is IMHO very slow.
and its a pity that Peter has found a home(it appears from comments made about his posting all the latest info there) on the kvcd forum. a closed forum most of us have no interest in paying to join.
Amnon82
31st January 2005, 03:59
I released a guied version of HC 0.01
Here is the screenshot:
http://www.brckomania.net/HCGUI/img/hcgui001.png
grap it here:
http://forum.doom9.org/showthread.php?s=&threadid=89101
I did some Logos:
Grap them here (http://www.brckomania.net/HCGUI/files/HC.Logos.rar)
Mug Funky
31st January 2005, 09:08
one question: is there a way to set field order?
TEB
31st January 2005, 11:02
@Macanudo: Procoder supports HD in mpeg2, all profiles.. even HDV.
Ebobtron
31st January 2005, 16:18
Originally posted by Mug Funky
one question: is there a way to set field order?
Why?
The Edge
31st January 2005, 18:19
I tried beta 0.01 on an AMD 1400 t-bird and it's says:
"No MMX/SSE detected"
"Enter to close program"
I'll give it a go later on my P4 laptop. Sounds promising hank315 :)
Amnon82
31st January 2005, 18:38
Did You enter MMX and SSE manually? Tryout my gui.
The Edge
31st January 2005, 19:23
Originally posted by Amnon82
Did You enter MMX and SSE manually? Tryout my gui.
I did...no joy.
This (http://members.boards.ie/the_edde/HC_Output.GIF) is the screen I get.
Originally posted by Amnon82
Tryout my gui.
Found it difficult to download....timeouts etc.
Anyway, exactly the same thing happens with GUI I'm afraid.
hank315
31st January 2005, 19:45
Add the next command:
*CPU MMX
This will force the CPU to use MMX and SSE, it will run (or crash if it is not supported;))
The Edge
31st January 2005, 23:15
I already tried that mate, like Amnon82 suggested.
It seems the default is already *CPU MMX when unzipped.
I've tried *CPU MMX & *CPU AUTO and the error still appears hank.
Also tried without an .ini too....same.
Is there anything else you would like me to try?
btw WinXP SP2 here.
hank315
31st January 2005, 23:38
@The Edge
Did some "googling" and found this:
http://www.hothardware.com/viewarticle.cfm?articleid=207&catid=1
It seems the Athlon Thunderbird has MMX support but no SSE support, SSE was available with the introduction of the Palomino core.
But I'm not a hardware expert, maybe there's someone who knows...
Just try it on your P4 laptop, should certainly run on that one.
The Edge
31st January 2005, 23:52
Your spot on Hank....T-Bird only has MMX & 3DNow!
Not to worry mate. Maybe it can be looked at some other time. ;)
*Fires up P4 lappy* :D
Amnon82
1st February 2005, 00:57
Maybe You must have MMX+SSE as minimum. Or I'm wrong, hank?
dragongodz
1st February 2005, 03:15
It seems the Athlon Thunderbird has MMX support but no SSE support, SSE was available with the introduction of the Palomino core.
Your spot on Hank....T-Bird only has MMX & 3DNow!
well close enough anyway. :)
all athlons and durons support ISSE but not full SSE until palomino(athlon) and morgan(duron) cores.
some ISSE information here
http://www.avisynth.org/IntegerSSE
hank315
1st February 2005, 10:48
Then it could work because the MMX routines only use MMX and integer SSE, only my CPU testing is clearly too severe.
I'm testing bit 23 (MMX) and bit 25 (SSE), is there somebody who knows how to test for the MMX / ISSE combination?
ARDA
1st February 2005, 12:56
Look in cpuaccel.cpp in avisynth sources.
But if I'm not wrong ISSE is an MMX extension of some Amd machines.
from:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22466.pdf
"This chapter describes 19 new instructions added to the MMX
instruction set defined in the AMD-K6® MMX™ Enhanced
Processor Multimedia Technology Manual, order# 20726. Twelve
of the instructions improve multimedia-enhanced integer math
calculations used in such applications as speech recognition
and high-quality video processing. Seven instructions are
dedicated to efficiently moving multimedia data into and out of
the processor.
Programmers should check bit 22 of the Extended Feature
Flags in the EDX register after executing extended function
8000_0001h of the CPUID instruction. If bit 22 is set, the AMD
processor supports these 19 instructions. See the AMD Processor
Recognition Application Note, order# 20734 for more
information.
Instruction definitions are in alphabetical order according to
the instruction mnemonics."
http://www.amd.com/epd/processors/6.32bitproc/8.amdk6fami/x23913/23913a.pdf
If an AMD machine MMX-SSE Bit 22
If a Cyrix machine MMX-SSE Bit 24
What means that a SSE machine has also this extended feature.
I hope this can be usefull.
ARDA
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.