Who wants to test a new MPEG2 encoder

[Koepi]

If you want to speedup encoding like you describe, you need to store your filtered output with a lossless codec and use that as source - else the filtering is _of course_ done on 2nd pass again.

During the first pass only statistical data gets collected (frame sizes, size of motion data, size of texture data, frame type and so on).

You could do a search for "two pass encoding" and go to posts back in i.e. 2002 or earlier, there the basics for 2pass encoding are explained.

Cheers
Koepi

[onesoul]

@ jeanl

I don't think there's nothing wrong comparing 2 interlaced frames, that's what I did on my test, using original and encoded ones. Like it is described, I used avscompare, very nice features including able to zoom and frame stepping (crashes sometimes but it's very good although).

[jeanl]

Originally posted by onesoul
@ jeanl

I don't think there's nothing wrong comparing 2 interlaced frames, that's what I did on my test, using original and encoded ones. Like it is described, I used avscompare, very nice features including able to zoom and frame stepping (crashes sometimes but it's very good although).
Have you tried to do that with moving frames? I noticed that in your tests, you seemed to have mostly steady shots (I couldn't detect any combing). If you compare 2 interlaced frames where the two fields have just been combined, the combing artifacts (the mouse teeth) are so obvious that it becomes really hard to see encoding artifacts... What de-interlacing technique does avscompare use to show you a full image from 2 consecutive interlaced fields?
jeanl

[onesoul]

@ jeanl

Th initial logo of HBO I agree that there isn't combing lines because it is originally progressive encoded as interlaced.

But the rest of the frames (from 375 forward in the test) all have combing lines and all are interlaced. And I repeat myself but if you wrongly use some spatial or temporal filter you can ruin the interlaced image. Currently I choose not to use any filtering on interlaced source unless I really need to.

Avscompare doesn't do any deinterlacing :), it displays just like it is or like you told it to do, no mistakes there. edit: it displays the full frame.

Here (http://forum.doom9.org/showthread.php?s=&threadid=40675) is the link for original thread and here (http://aquaplaning.20m.com/) is official page of avscompare, be sure to get the 2.5 avs version.

[jeanl]

Originally posted by onesoul

Avscompare doesn't do any deinterlacing :), it displays just like it is or like you told it to do, no mistakes there. edit: it displays the full frame.
So it simply combines the two fields. I will try to see if I can modify the script to make it show only 1 of the two fields (at half the vertical size). This of course won't show any combing/mouse-teeth, and should allow me to clearly see macroblocks caused by the encoding (at least I hope so!). I'll keep you posted! Thanks for the links.
jeanl

[onesoul]

separatefields() or verticalreduceby2() will do the trick, but imo it isn't necessary to look for macroblocks. And be sure to turn brightness really high to see more details, (don't forget to turn back brightness after testing or you will lose your eyesight ;))

[jeanl]

Originally posted by onesoul
separatefields() or verticalreduceby2() will do the trick, but imo it isn't necessary to look for macroblocks. And be sure to turn brightness really high to see more details, (don't forget to turn back brightness after testing or you will lose your eyesight ;))
I'll show you a couple frames where you can't see any detail because of the combing (I have to get back home for that). Thanks for the avisynth commands!
jeanl

[jeanl]

I found that using an avs script in vdubmod to separate the fiels was a very unreliable when the source is an mpeg file (lots of frames are dropped, etc). Instead, I'm inserting a de-interlacing filter (drop top field for example) which allows me to only visualize one of the two fields. This makes it much easier to compare the original and the encoded versions. I'm finding that HC gives very excellent results, even at bitrates down to 5Mb/s. The quality is as good (in my opinion) as CCE, although it appears that CCE does some spatial smoothing (even though I turned that off in the gui) so the outputs look slightly different in that respect.
So HC really rules. Thanks a million to the author.
jeanl

[onesoul]

Why not say better? eheh. It surely does rule :).
Originally posted by jeanl
I found that using an avs script in vdubmod to separate the fiels was a very unreliable when the source is an mpeg file (lots of frames are dropped, etc). Did you use DGIndex to create a d2v file of the mpeg file? I use that method to load it in avscompare, no dropped frames whatsoever, it can be used on virtualdub also.
Using the verticalreduceby2() avisynth command will drop a field also (unlike separatefields() which displays every field separated).

[jeanl]

Originally posted by onesoul
Why not say better? eheh. It surely does rule :).
Did you use DGIndex to create a d2v file of the mpeg file? I use that method to load it in avscompare, no dropped frames whatsoever, it can be used on virtualdub also.
Using the verticalreduceby2() avisynth command will drop a field also (unlike separatefields() which displays every field separated).
I want to use avscompare next, since having the two videos in a single app will simplify things for me. I'll keep you posted. But no I didn't use DGIndex. I used DShowSource() (or something like that) in my avs script. Maybe that was the problem.
jeanl

[onesoul]

Originally posted by jeanl
I want to use avscompare next, since having the two videos in a single app will simplify things for me. I'll keep you posted. But no I didn't use DGIndex. I used DShowSource() (or something like that) in my avs script. Maybe that was the problem.
jeanl Directshowsource, yes, that was the problem, but there's another one, you can't load multiple mpeg's with directshowsource, with the created .d2v files you can do it.

Maybe I didn't mention before, but the best feature of avscompare is that you can load up to 4 streams in different windows, which is awesome for you toggle bewtween them, zoom, etc, you can really see differences that you wouldn't be able before between encoded ones and original.

Have fun ;)

[hank315]

New release: HC013

- GUI and batch version updated
- faster encoding
- bitrate control updated
- encoding profiles updated: FAST - NORMAL - BEST
- QLB matrix updated
- added *NOSEQ_ENDCODE command to suppress output of the sequence endcode
- some other minor bugs fixed

This is a major update, alot of new code so there may be some (new) bugs :)
Will be in the download section soon.

But also at: http://hank315.dyndns.org/HC_013.zip

[dragongodz]

did a quick test using the gui version. not last frame missed like the last beta version did. will try CLI version to confirm shortly. :)

EDIT:
yep HC 0.13 CLI/batch working fine aswell. HC 0.12 is still getting stuck on the last frame however but hey 0.13 is here now so doesnt matter. :D

[onesoul]

@ dragongodz

See the quenc thread please.

@ hank315

From my ongoing tests, the new hc .13 is doing great, (even) better quality. I will try again the interlaced source.

[dragongodz]

See the quenc thread please.
onesoul - back at you. ;)

hank315 - may i suggest you actually start a new thread with this release since this one is 24 pages long already ? also a better title ,such as HC 0.13, would be an idea. :D

[ernstblaauw]

Originally posted by hank315
[B]New release: HC013
- bitrate control updated


Is it possible now to use one pass for DVD encoding (so HC will stay under a certain maximum bitrate, specified before encoding)?

[freelock7]

-Hank (about the 013 release)
The 'grain' effect in the picture is less perceptible while a lot of macroblocs are present now at low bitrate-like in QuEnc. :)
The constant Q could be changed as constant bitrate more useful-for me- and the quantization level is once again too high under 4000kbs. Damage because the bitrate control is perfect.

[vio_man]

Which should be the best matrix for XviD/DivX source? I've previously used the Mpeg matrix and I got undersized mpeg2.

[zettai]

I'm with freelock - I'd love to see some sort of combination of constant Q and max bitrate where the encoder encodes at a certain quant unless the bitrate is exceeded and a lower quant is used for that section.

[DoctorRad]

Originally posted by hank315
New release: HC013

Is this the same as the 0.13beta you sent me?

Thanks,

Matt...
--

[johnnyquid]

@hank315

Was just trying out the new batch13 version. It is working fine most of the time but it did go into an infinte loop when trying to fix a VBV buffer underflow. The finding and fixing counters just keep on going up with no progress in the number of frames processed. The same video encoded without any trouble using batch12a version.

[onesoul]

@ johnnyquid

Maybe posting your log would help.

Cheers

[johnnyquid]

I went back and tried to duplicate the problem but was not able to. It occurred during a DVD Rebuilder run so to try to duplicate the problem I edited the rebuilder.inf file to restart the encode on the file which I saw the problem. This time the encode completed without a problem. Go figure. If I can get the problem to repeat I will repost.

[lithoc]

Just a quick test. Really impress with speed of HC.
Thanks.

Bug:
1.) KVCD-NOTCH matrix didn't work.
2.) Didn't save settings when quit. Everything is load to default. (May be add extra button to load to dafult settings)

[ffreese]

[QUOTE]Originally posted by lithoc
[B]Just a quick test. Really impress with speed of HC.
Thanks.

How fast is HCenc013 compared to CCE or to HCEnc012?

[dragongodz]

Didn't save settings when quit. Everything is load to default.
yes hank315 knows this. we have discussed it so several times. i think,rightly, he was more interested in improving speed and rate control however for this release.

How fast is HCenc013 compared to CCE or to HCEnc012?
slower than CCE and faster than HC 0.12. speed increase seems to scale with the profile, that is BEST has the largest speed increase while FAST has the smallest. also hank315's P4 gained more increase than my Athlon XP 2400+ proportinatly. try it for yourself and see.

hey i just noticed another little bonus. me mentioned in the thanks.txt. nice. ;)

[alfixdvd]

Really impress with speed of HC 0.13 in the first pass : 25.6 fps against 12.6 of 0.12 version. The time cuts by half.

The size of m2v file is now more acurate with the bitrate specified.

Thanks hank315, good job

[lamster]

I tried running it on an older machine, and got a crash with an "illegal instruction" error when it tried to execute the following:

00402973 psadbw mm1,mm2

The computer has the following:
Processor Type: x86 Family 6 Model 6 Stepping 5

Might be nice to check for any hardware requirements up-front...

The other crash was running on a different computer, using Rebuilder. This one isn't an unsupported processor, since the crash occurred while processing the 3rd segment; the first 2 completed OK.004722FF FF 15 F0 31 47 00 call dword ptr ds:[4731F0h]
00472305 8B 48 0C mov ecx,dword ptr [eax+0Ch] ; EAX == NULL
It's reproducible; the first time I had Rebuilder set to its default of Quality = Normal; the second time I set it to "Best".

Just reproduced it with 0.12. I was watching it, and the exception occurred after the encoding was completed. Here's a screen shot:

[lamster]

@hank315 - A couple of questions...

Since the crash is occurring after the countdown showing "(n) encoding finished", is it safe to assume that the resulting M2V file is good? And, is that countdown really necessary? If I'm calling HCbatch from Rebuilder, and not looking at your GUI screen, it seems to be just a waste of time.

One more question - I'm letting it chug away (hoping that the answer to my first question is Yes ;) ) and I've seen only a few segments crash this way - it's on the eleventh, and only 3 have run into this. Is there any info I can provide to help you debug this? After it completes, I'll try seeing if there's any commonality amongst the ones that had a problem.