Who wants to test a new MPEG2 encoder

[Mug Funky]

anyone with BFF videos, you can get around it somewhat with doubleweave().selectodd(), or if your source is RGB or yuy2, you can shift it up 1 pixel to make it TFF.

there's also reStream available to change the flag manually (you just need enough disk space for another copy of your encode).

[hank315]

Does HC expect TFF clips?It just encodes what Avisynth serves...

anyone with BFF videos, you can get around it somewhat with doubleweave().selectodd(), or if your source is RGB or yuy2, you can shift it up 1 pixel to make it TFF.

there's also reStream available to change the flag manually (you just need enough disk space for another copy of your encode).Will add some buttons so it can simply be set. Will be in the upcoming release.

[Paazabel]

Someone should package this with MuxMan ...

*acts casual*

It seems that it needs TFF to look right. Any time I sent BFF to it, it got all herky jerky. I used ...

DoubleWeave().SelectOdd()
DelayAudio(-0.0167) #Adjust audio one field NTSC

... and everything came out fine. Looks outstanding at 5 meg ...

[Amnon82]

Next version of HC will come soon. Maybe at the beginning of the coming week.

[Xeno86]

Hi hank315!

I'm new to this forum, although not quite a newbie in MPEG encoding.
I've tried your HC GUI 0.1 encoder and I think that it gives excellent output (comparing to libavcodec and tmpegenc) although some things could be improved:

1. When I run 1-pass encode based on quant value it doesn't preserve the maximum bitrate setting, so it's quite useless - even for DVD's, because there are spikes of 18.5 Mbit/s which are far too high :).

It would be excellent if you could add possibility to set maximum bitrate and vbv checking for 1-pass encoding.

2. Why is the nominal bitrate of each MPEG header always set to 9800000 bps? Output stream IS SVCD compatible but I have to use ReStream and change this setting to 2500000 bps in order to be able to read it on my DVD player. Could it be set according to "max. bitrate Kb/s" option as it is in most encoders?

3. Small bug: 2000 Kbit/s is not 2048000 bit/s. (Correct me if I'm wrong :) ).

4. In the docs you've written "Bit rate will never go below 0.4 Mb/s for DVD creation.". How does it know that I'm encoding a DVD? Anyway I'm encoding mainly SVCD so it would be better to let the user decide about the lowest bitrate - I prefer 64 Kbit/s :)

5. The rate control is not very accurate. I encoded my 50 minute material with this settings
--------------------
| encoder settings |
--------------------

profile: BEST
frames: 1 72299
framerate: 23.98
aspect ratio: 3:4
bitrate Kb/s: 2000
max. bitrate Kb/s: 2500
restart: no
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: no
goplen,B-pic: 24 2
dc_precision: 9
scan method: ZIGZAG
time code: 0 0 0 0
CPU: MMX/SSE
matrix: NOTCH

but the size of the output is much lower than expected (Average bitrate = 1167 Kbit/s, Average Quant = 5.533).

Could this issues be fixed in the nearest version (especially 1., 2., 3. and 4.)?

Keep up the good work.

Btw. Sorry for my english, but it is not my native language.

[dragongodz]

1. When I run 1-pass encode based on quant value it doesn't preserve the maximum bitrate setting, so it's quite useless
then it wouldnt be constant quant would it. a 1 pass VBR would be good but consider this is version 0.1 and consider the difficulty in writing 1 pass VBR from scratch. you do know how hard that is right ?

2. Why is the nominal bitrate of each MPEG header always set to 9800000 bps?
because hank315 has just concentrated on dvd for it. i am sure he will change that in upcoming versions.

3. Small bug: 2000 Kbit/s is not 2048000 bit/s.
that is correct.

4. In the docs you've written "Bit rate will never go below 0.4 Mb/s for DVD creation.". How does it know that I'm encoding a DVD? Anyway I'm encoding mainly SVCD so it would be better to let the user decide about the lowest bitrate - I prefer 64 Kbit/s
nitpicking. yes changing the min bitrate would be nice aswell but prefering 64 Kbit/s ? ye thats going to make a huge difference. :rolleyes:

5. The rate control is not very accurate
goplen,B-pic: 24 2
matrix: NOTCH
ah, a follower of the kvcd hype. try using a normal matrix and GOP length and you will probably get closer to your target bitrate. and i have to add that hank315 is still working on rate control and for a version 0.1 it is looking pretty good.

[hank315]

Dragongodz, thanks for the reply :)

Just some short remarks:

1) Constant Quantization is just meant for high quality backup's and testing and is certainly not DVD compliant.

2) Will be set to Max. bitrate in the next version.

3) Just a matter of definition, using the old ones, 1Kbit = 1024 bits, 1 kbit = 1000 bits. A couple of years ago a new standard was set: 1 kBit = 1000 bits, 1 KiBit = 1024. If the majority thinks it should be 1000 bit I will set it.

4) Don't know if you want to create a DVD but ATM the settings are:
if width >= 704 and height >= 480 the minimum bitrate will be 400 otherwise it can go as low as possible...

5) I know, and especially it the difference between max and average is small it just means you want to do CBR and ATM it just can't do it. After the release of the next GUI version (which is almost finished) the bitrate is the first issue on a long list of wishes :D

[dragongodz]

3) Just a matter of definition, using the old ones, 1Kbit = 1024 bits, 1 kbit = 1000 bits. A couple of years ago a new standard was set: 1 kBit = 1000 bits, 1 KiBit = 1024. If the majority thinks it should be 1000 bit I will set it.
yes the Kibi is for binary definition. Kbit for video is 1000. you can confirm that in the mpeg specs by looking at the profile levels. ;)

[hank315]

You're right, think it's better to set it at 1000.

There are just 10 kinds of people, those who can do binary and those who can't, might even get used to it: 2^10 = 1000 :D

[Xeno86]

Thanks for quick replies.

@dragongodz
then it wouldnt be constant quant would it. a 1 pass VBR would be good but consider this is version 0.1 and consider the difficulty in writing 1 pass VBR from scratch. you do know how hard that is right ?
I know that HC is in a very early state and that it still needs lot of work. I really appreciate the work that hank315 does. I only wanted to share with my experience with the encoder :)

ah, a follower of the kvcd hype. try using a normal matrix and GOP length and you will probably get closer to your target bitrate.
I've tried some configurations and kvcd matrix gives me lower bitrate with same quality comparing to standard matrix. If you could recommend me a matrix that does better job at bitrates 1500-2000 I will give it a try (I've also tried QLB but with worse results).
I'll try 'normal' matrix and post the results.


@hank315
4) Don't know if you want to create a DVD but ATM the settings are:
if width >= 704 and height >= 480 the minimum bitrate will be 400 otherwise it can go as low as possible...
I use 528x480(576) so that's ok for me :D
5) I know, and especially it the difference between max and average is small it just means you want to do CBR and ATM it just can't do it.
I know that the difference is small but 2500 is the maximum value that I can use for SVCD and I want to put 50 minutes of movie with highest possible quality so that it would fill whole CD. CBR is not really what I want. I'll try to write it more clearly.

The situation looks as follows:
The output is 458884 kB, the desired is 700000-750000 kB.
Average quant is 5.533 BUT it hardly ever goes below 5.3: bitrate=400 => quant=5.3 (as you can see on the screenshots).
http://img150.exs.cx/img150/2954/14en.png
http://img230.exs.cx/img230/6838/26ln.png

I hope it will help you to find the problem.

[dragongodz]

I've tried some configurations and kvcd matrix gives me lower bitrate with same quality comparing to standard matrix. If you could recommend me a matrix that does better job at bitrates 1500-2000 I will give it a try (I've also tried QLB but with worse results).
what i want to know is if the size increases closer to the target.
as for prefering different matrrices...each to their own. ;)

actually lokking that you are doing svcd(except for out of spec GOP length and frame size) you shouldnt really need a very low bitrate matrix. a target of 2000 is practically equivilent to around 4000 for dvd so more mid range than low. so most matrices should look atleast ok. you are not doing any filtering or anything before the encoder are you ?

no i am not saying thats causing the problem of not hitting your target, as i said the rate control does need more work.

[dragongodz]

Xeno86 - i have come across an interesting anomoly. i did some tests with HC with a target bitrate of 2000. all were slightly under the target bitrate (closest was 1964) according to the HC gui information. now i loaded 1 in to bitrate viewer and it said the average was 1564. hmm thats strange i thought. so i loaded the same m2v in to mpeg stream eye and it said the real average was 1954. so we have 2 programs(1 being the encoder itself) saying the bitrate is only slightly under the target and bitrate viewer saying it well under. strange huh ?

[mean]

Bitrate viewer (last time i checked) takes 23.976 pulldowned stream as 29.96
Hence
1924*23.976/29.96=1539

[dragongodz]

except my test was done with PAL/25fps so pulldown not relevant.

[gizmau]

Originally posted by dragongodz
..real average was 1954. so we have 2 programs(1 being the encoder itself) saying the bitrate is only slightly under the target and bitrate viewer saying it well under. strange huh ?

could the reason be the old problem of Kbit (capital) and kbit (small), because 1954*1,024=2000,896 - which exactly hits the desired bitrate.

[Xeno86]

@dragongodz:
actually lokking that you are doing svcd(except for out of spec GOP length and frame size)
That's right! How did you know? ;)
you are not doing any filtering or anything before the encoder are you ?
I only use deblocking filter, lanczos4resize and blockbuster, but these only improve sharpness and shouldn't lower the bitrate...
under the target bitrate (closest was 1964) according to the HC gui information
I can't see where HC_GUI displays bitrate information. Are we using the same version (v0.1, size 634880 B)?
what i want to know is if the size increases closer to the target.
Yeah the size increased :)
Same source, all the options same (bitrate=2000, max=2500, 2pass), except:

kvcd matrix, gop 24 2:
avg.bitrate=1167
avg.quant=5.54
mpeg matrix, gop 15 2:
avg.bitrate=1250
avg.quant=5.73
Encode time ~4H
(info according to Bitrate Viewer)

So it is 7% bigger :D

Now let's see if it shows bitrate correctly:
469 897 135 B * 8 bit = 3 759 177 080 bit / 1000 bit = 3 759 177 kbit / 3015 sec = 1247 kbit
So it seems that Bitrate Viewer is right (3015 sec is real play time @ 23.976 fps, total num of frames 72299). I didn't do any pulldown.

It seems that min quant value is somehow locked. It hardly ever goes below 5.00. It looks as if it was hardcoded :confused:

[Amnon82]

A little update for the Guys reading this thread:

The Betatesters started to test the new version 0.11.

New Features of the new version:

Preview of the Source and the Encode
Interlaced fields are added now
Some changes to the encoderengine
Some fixes on the GUI

When Hank releases this version to the public I can't tell.

@Hank: Keep on the good work. ;) You got mail from me ...

[hank315]

It seems that min quant value is somehow locked. It hardly ever goes below 5.00. It looks as if it was hardcodedIt's not hardcoded but I know quants are not able to go low enough.
The bitrate control as it is implemented was meant to create DVD content with a normal DVD GOP structure and bitrate.
So doing KVCD stuff will not give optimal results ATM.

After finishing the new GUI version I will do a complete workover of the bitrate control, the next version might already improve things but these are just minor changes.

@Xeno86
Also did some testing with 2000/2500 average/maximum bitrate but couldn't reproduce the large difference you got.
Did a test with a 6 min. Matrix2 (PAL) source, settings: matrix: NOTCH, profile: BEST, scene change: ON
With GOP 24-2: bitrate HC: 1899, Bitrateviewer: 1899, MPEG Stream Eye: 1899
With AUTOGOP: bitrate HC: 1920, Bitrateviewer: 1910, MPEG Stream Eye: 1910
Both too low but not that low you got...

My goal was to create a thing what would do descent quality, runs stable and would give no problems with max bitrate and underflows, now the problem seems to be at the other end of the bitrate spectrum :( , think this one can easier be solved :)

The next version will be ready in a couple of days if all goes well, ATM I'm implementing the last changes from the beta test feedback I got (thanks for that guys!!).

[dragongodz]

I only use deblocking filter, lanczos4resize and blockbuster, but these only improve sharpness and shouldn't lower the bitrate...
actually deblocking can smooth aswell. ;)

I can't see where HC_GUI displays bitrate information. Are we using the same version (v0.1, size 634880 B)?
umm no, sorry, i was using 0.11 beta. :)

469 897 135 B * 8 bit = 3 759 177 080 bit / 1000 bit = 3 759 177 kbit / 3015 sec = 1247 kbit
i did the same calculation for my 25fps and it came out 1953 which tallies with HC and mpeg stream eye but not bitrate viewer. so atleast for this clip bitrate viewer is getting it wrong.

Did a test with a 6 min. Matrix2 (PAL) source, settings: matrix: NOTCH, profile: BEST, scene change: ON
i tested several different matrices, also normal and best settings with scene change turned off for all.
hank315 if you want a small sample clip that shows much lower in bitrate viewer but near target bitrate in HC and mpegh stream eye let me know.

[Ebobtron]

Originally posted by Amnon82
A little update for the Guys reading this thread:

The Betatesters started to test the new version 0.11.

New Features of the new version:

Interlaced fields are added now
"The Beta testers", guess I'll have to figure out what I have been doing with my spare time the last couple of weeks.
----------------
"Interlaced fields are added now",don't you mean a TFF or BFF check box to select the flag setting to match your source? Last time I used HC interlaced fields worked just fine. I'm not sure what the BFF guys do, but I use ReStream.
-----------------
I don't mean to be pissy. Sorry everyone, yes I do.
--------------
@Hank315
I have been away for the last week popping in from time to time to follow along. I'll post my findings tomorrow.

Sir, your public awaits you.

[dragongodz]

hmm i just did a test encoding with QuEnc 0.59 and bitrate viewer says thats well under the bitrate aswell while mpeg stream eys says its slightly over. what the ????

"Interlaced fields are added now",don't you mean a TFF or BFF check box to select the flag setting to match your source?
yes thats what he means.

"The Beta testers", guess I'll have to figure out what I have been doing with my spare time the last couple of weeks.
I don't mean to be pissy. Sorry everyone, yes I do.
dont be so ungreatful. so a couple of people got to check for last minute problems etc a matter of days before you are due to see it, get over it.

[Axed]

Originally posted by Ebobtron
"The Beta testers", guess I'll have to figure out what I have been doing with my spare time the last couple of weeks.

Theres a very good reason for other people to be checking it before its released to the major public. When the problems pop up, people more knowledgeable in how the encoders work, and also programers, are alot more useful to iron out major bugs then the public who cant properly describe their problems.

When the rest of us get our grubby fingers on it, im sure we'll find those annoying little random bugs that cant be found by a few people testing.

Thanks for the great work Hank.

[Ebobtron]

Originally posted by dragongodz
dont be so ungreatful. so a couple of people got to check for last minute problems etc a matter of days before you are due to see it, get over it. Didn't mean to pick a scab. I just thought that everyone working this thread was beta testing. I either stand corrected or not. Ungrateful is a little harsh, I could be wrong. But you have read much more into my statement than I meant.

For that I am truly sorry.

[Amnon82]

Hank recruted some of the HC user to betatesters. I'm one of them, for example. I know that some guys here tests HC for hours and weeks, but some are only user. They can only tell the programmer, that there is a problem when he did this and that.

I'm coding programs my self. So does dragongodz too, who is also one of the betatesters of HC. We're talking daily via email with hank and helping him so. We do a hard job to find all the bugs and codingmistakes hank did in the last build.

If we don't do this before hank releases it public, the most user here will post "man this program isn't finished yet. I can't encode my movies. etc ..." without knowing what the problem realy is.

In version 0.11 hank changed the core. But with this changes we lost quality. So hank need more time to change it to the quality we already know form HC 0.01.

The GUI has now more features. For example, hank added a preview. So You can switch between the source and the encode to see the quality. Via a zoom-function You can zoom into the picture during the preview.
Also the stats are now displayed in the right way.

Some reader here know that it is the first GUI for Hank. 0.01 was a commandline-tool. I coded the first GUI for it. Hank felt in love with it and started a GUI by him self. So 0.1 was the next release and the first with a GUI by Hank. So some features came and some are gone.

To get the features of my GUI, the commandline version of HC and the new guied version of HC into one program it will take a long time to get it done, but we're working hard to reach the goal soon.

When the next release will be released I only can tell You this:

When it's done! ;)
(a cool statement btw, so think I (thx goes to iD))

[Ebobtron]

Revisiting my bug report concerning the flashing pink and sometimes green lines at the bottom of the frame when using NTSC sources 720x480, 704x480, 352x480, 352x240, interlaced or progressive.

--------------------------------
++++++++++++++++++
++++++++++++++++++
++++++++++++++++++
++++++++++++++++++
+++++++++++xxxxxxxxx
------------------------------------ The xxxxx show where the lines appear in the video.

Roughly the last third of lines 476, 478 & 480 from pixels 464 to 720.

The following is a list of those encoder settings that have no noticeable effect on the aberrant lines.

Source --- avs or d2v: see source content below
Encoder profile:
Bit-rate:
Frames:
GOP Structure:
Matrix:
DC Precision:
CPU:
Interlaced:
Aspect Ratio:
Scan method:
Time Code:
Do I need to add VRB check:

That leaves us with source content, closed gops, scene detection, constant quantization.

Constant Quantization or CQ

“Using CQ”, @ 4,5,6 or 7 (other values not tested) the anomalous lines appear in every frame, are a solid green residing in lines 476, 478 & 480 from pixels 464 to 720. Feed “HC” PAL content of 576 or 288 vertical lines and the green lines do not appear. With NTSC content 480 and 240 vertical lines green lines are displayed. Horizontal size has no apparent effect on the unwanted lines. Interlaced or progressive encoding, no difference. Source content has no effect with the exception of vertical size.

“No CQ” -- “Open GOPs” -- “No Scene Detection”

Now is gets interesting. The lines are pink and they flash or they appear to flash. Our unwelcome guests show up only in the two frames displayed prior to an I frame. The pink lines are not solid but spread along the space between pixels 464 and 720 (as dots and dashes) again on lines 476,478 and 480. The little pink dots and dashes are never in the same position unless the frame lacks motion.

Source content has an effect if the scene is black or has no motion. Source content with large black borders at top and bottom of the frame produce no unwanted pink lines. So I ran a script to increase the borders around a frame in increments of one. As border size increased pink lines decreased until gone at eight pixels, border color had no effect. My conclusion is that if there is a change between frames in the lower 8 lines we get pink lines. But only in the two frames that proceed an I frame. So they appear to flash.

“No CQ” -- “Closed GOPs”
This one is easy, no pink lines. Remember that GOPs closed or open have no effect if CQ is used.
CQ and NTSC equals solid green lines in every frame.

“No CQ” -- “Open GOPs” -- “Scene Detection enabled”
The little pink flashes are here too but not in the two frames displayed prior to the inserted I frame for the detected scene of course that GOP is closed.


The following is meant not to show a GOP but to clarify the frames containing the misbehaved lines.
In displayed order viewing with VirtualDub-Mpeg2 1.5.10 (build 18294):

B B P B B P B B I <----This I frame must the beginning of an open GOP for the two B frames to flash pinkly.

Source effects
I use AviSynth 2.55 Build Sept. 1, 2004 (I have omitted the build time). DGIndex's d2v or AviSynth, the only thing that effects the behavior is vertical resolution. PAL source equals no green or pink lines however the encoder is configured. I have toyed with fps and field frames and TFF and BFF. Vertical frame size seems to trigger the behavior

My source doesn't have the unwanted lines, I tested with rips, camera clips, and still frames.

That’s all I have on this. I can’t even offer a guess.

I’m using XP Home SP1 on a Compact with 512 Mbytes of ram with a 2.8 GHz Celeron Processor.

I suppose it could be my set up here, stranger things have happened. I hope someone can duplicate my observations.

My time is up for today.

[Xeno86]

@hank315

The bitrate control as it is implemented was meant to create DVD content with a normal DVD GOP structure and bitrate.
But I have also tried it with standard gop and matrix and the differences were really small:
kvcd matrix, gop 24 2:
avg.bitrate=1167
avg.quant=5.54
mpeg matrix, gop 15 2:
avg.bitrate=1250
avg.quant=5.73

Anyway I've done few more tests with same settings but other source (Gladiator DVD PAL, 2 minutes) here are the results:
Avg.bitrate=1856
avg.quant=5.78

This time quantizers went much lower - the lowest is 3.20

It looks like the "too low bitrate problem" is related to my previous source. But I don't now why quant was locked to 5.3 and now it went much lower. Strange, isn't it? I'lldo more tests later.

[((( atom )))]

@hank315: your encoder looks very promising. some free tool like that with high quality was missing for a very long time now. thx for it!

there are a couple of questions i have. i read through the manual, not this entire thread, so i might ask questions that have been discussed, but every user might have these questions after having read the manual, so i dare.. ;)

- does your encoder support hd-resolutions?

- why can i only input .d2v or .avs files?
especially for dv, avi-input could easy things up for many people. others might want to reencode mpeg-files. is it because the app couldn't make use of other files atm or is it a restriction you wanted?

regards,

[Koepi]

Maybe because it's so simple to just write

AviSource("MyDVfile.avi")

into an avs file instead of dealing with missing codecs, framrates,...?

But if avs is supported, avi support shouldn't be that hard to do either. Btw., it's usual for the most recent encoders to just use avs input (QuEnc, avs2avi,...)

Just a wild guess though :)

Cheers
Koepi

[hank315]

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.

[Amnon82]

@Hank: You're always welcome ;)

[hank315]

- does your encoder support hd-resolutions?No but maybe in the far future

- why can i only input .d2v or .avs files?
especially for dv, avi-input could easy things up for many people. others might want to reencode mpeg-files. is it because the app couldn't make use of other files atm or is it a restriction you wanted?Koepi already gave the answer, it's easier this way.
For Avisynth people can also use their favorite filters etc. and just the idea to write a descent avi reader... :scared:
The avs input is based on AVS2YUV by Loren Merritt and the mpeg input uses DGIndex/DGDecode by Donald Graft, so I just did it the easy way :)

[TEB]

Lovely encoder. Will u add some kind of SMP support in the encoder pipeline? and yuv2 (4:2:2) support?

keep up the good work.

teb

[Backwoods]

Originally posted by hank315
No but maybe in the far future

Concerning HD res, there is alot more to it besides being able to include different profiles? Obviously I have no idea, just curious.

[Ebobtron]

@Hank: Two questions.

1) I have been assuming that HC is self contained. And we know what happens when I assume:). So, is it? Is there anything HC needs from my system that could cause version conflicts?

2) Encoder profile: What is fast, normal, good, best? It is difficult to see any subjective quality difference between normal and good.

The output is as good as I can measure.

It’s great work just as it is. It’s hard to imagine the encoding being much better for high rate dvd source creation.

Congratulations,

Ebob

[Pasqui]

Hi hank315 !
First of all, thanks for your work !
Do you plan to reintegrate command line support ? It is sad that your encoder cannot be used by DVD-RB.

Regards,

Pasqui.

[dragongodz]

2) Encoder profile: What is fast, normal, good, best? It is difficult to see any subjective quality difference between normal and good.
i assume(:)) they use different motion search precision/range etc.

[hank315]

I have been assuming that HC is self contained. And we know what happens when I assume. So, is it? Is there anything HC needs from my system that could cause version conflicts?The exe file contains all the code but because it's now a "real" windows program it needs more windows DLL's but nothing special.
The first command prompt version only needed one windows DLL, now it needs more, so more fun :)
And ofcourse Avisynth and/or DGDecode.dll.


Encoder profile: What is fast, normal, good, best? It is difficult to see any subjective quality difference between normal and good.The way the motion search works is mostly influenced by the encoding profile. If the bitrate can be high enough the (visual) difference will be small but if you want to do a backup of a 2.5 - 3 hour movie you should use the best profile.

EDIT:i assume() they use different motion search precision/range etc.That was just a little bit faster :D

[manolito]

Originally posted by hank315
Nothing really changed in the encoding engine except for bitrates < 2000 which should give a slightly better result.
As long as the GUI version has no INI file / batch support, is there any chance you could update the non-GUI version with the updated encoding engine?

Cheers
manolito

[hank315]

As long as the GUI version has no INI file / batch support, is there any chance you could update the non-GUI version with the updated encoding engine?Will do that, it's just a small change, will let you know here when it's done...

[DK]

could please you take a look at this, hank?

http://forum.doom9.org/showthread.php?s=&threadid=89440

[hank315]

could please you take a look at this, hank?

http://forum.doom9.org/showthread.php?s=&threadid=89440Hey, that's nice, never saw this thread but I like DVD Rebuilder a lot, very nice program.
Will certainly read all of it and see if I can help but first I think I'm going to sleep for a week or so :D

[dragongodz]

hank315 - i see the gui is still in "monster" mode. :D

[hank315]

i see the gui is still in "monster" mode. :DYep, but the next one will be smaller :)
So people with EGA resolutions and 286's can also use it :D :D

[Amnon82]

Yeah. I'm running a 486 with a Rage128 and 20 GB harddrive. My monitor has 15" so I can't use Your guied version. So I coded one my self ;) Also I tried HC on my new PDA. It crashed. When do plan to write it for WinCE?

... just kidding :D

[dragongodz]

HAHAHA funny guys.

seriously though i do have freinds with 15" monitors who use 800x600 resolution. try the gui on that some time. ;)

[video_magic]

^That's what I'm using right now and I also know a couple of other people stuck with the same. Sometimes I do switch to 1024x768 but that's not very pleasant to use on a 15"

I do have a 19" at home though :)

That aside, congrats and thanks on the new HC Hank

[Amnon82]

@Dragongodz: Kost jetzt boarisch? Freinde! Des is ja da Wahnsinn!

Translation: Can You bavarian too? Friends! Wow this is amazing!

;) ;)

Yeah it should fit for 800x600 ...

[freelock7]

HC0.11 gives a really good picture.
Movie tested yesterday with great quality (VBR=5000-max bitrate=8500).
Global quant=4.5
bitrate peak=8920
Muxing with IfoEdit correct
Still needs a temporal filter to correct grain (convolution3D).
Deblocking is a good idea too (thanks Dragongodz).
So, for the next release, can you give us, Hank, some advanced settings to adjust?
Is it possible to do that with HC?

[zettai]

Everytime I try to load an avs file into HC it just hangs. No crash error message, just no response. The avs file works fine in vdub.

I have an old fashioed althon xp, using win2k. Suggestions?

[buzzqw]

@zettai

even with a simple avs as

colorbars(720,576)
converttoyv12()

BHH