AutoQMatEnc, another free MPEG2 Encoder
 

Read details here:
http://forum.doom9.org/showthread.php?t=96073
Recently there are too many free mpeg2 encoders :D

Hi Abond :),
Yes indeed but they all come from the same "place":
SAPSTAR doesn't mention if he's done any improovements on the vbv underflows such as Peter Cheat did but I wouldn't bet on it...
Cheers

Avcodec's code is already too "FUBAR" :!:
I agree with you Rui. I think all spikes and glitches will be "inherited" on that encoder too, as it comes from the same "place" :lol:
I also agree with you Abond, that there are too many encoders from the same source tree. Kinda looking like Linix distros, which are all the same dog (kernel), dressed with different collars :hihi:

-kwag

from the same place,from the same tree,the same dog,dressed with different collars... 8O
yes,bad fruits came from bad trees that are in bad terrain mascarade with bad remedy.......let the dog :P (oh poor little dog) out(i'm veterinary)
now i understand what one friend of mine told me about that place! :roll:

can someone answer me? why they love libavcodec? have something using libavcodec working fine? :?

you forgot this part Kwag:
build from the same "people" with the same bugs (or worse)! :lol:

Hi Alexandre :),
Actually I am convinced that (even though I haven't tested it) it must do a good job on MPEG-4.
Otherwise there wouldn't be such a fuss about Mplayer/FFMpeg/LibAVcodec on the internet.
Unfortunately it's still under-developped for what we need in MPEG-1/MPEG2.
Maybe one day...that is, if MPAA or RIAA don't shut them off.
But this is just me guessing because I've never tried MPEG-4 with libavcodec.
Cheers

Well, I tested it with DVD-RB. The output looks fine.

I think you still do not understand the difference between looking good and beeing good.

Can you enlighten me, if you think you know it better than me?
Did you make some test, or only want to point out that you know everything better?

You can read all my comments about mencoder for instance but to have a quick overview : a stream that does not repect the bitrate limitation, that will be refused by a lot of authoring app, that will make to jerk a majority of standalone players is not good.

Nothing that uses libavcodec for the moment* can be considered as good (in word of MPEG2 compliancy) even if it looks good (in word of beauty of the picture).

Note: but perhaps you gave an other meanings to the word 'looks' in your last post ? It can have several meanings.

* I did not check Peter's patch.

Yes. Should be "seems to be fine". Do not forget that DVD-RB will re-author everything as DVD - then at least one authoring tool did not reject it.

As others (DVD-Lab for instance). But the final word is given to the standaloneS. Some suffer with too low bitrates, a lot suffer with too hight peaks (and this can damage the player BTW - even if this is probably a urban legen that I never faced personally).

Edit: just to know, how do you use an other encoder that the ones supported in DVD-RB ?

Download the package and read the readme - it is quite clear. Shortly - for DVD-RB it appears as CCE 2.70(and even use .ecl files as input). So you simply point the DVD-RB to AutoQMatEnc instead to CCE 2.70.

I didn't even read it yet :)

Be carefull BTW : it uses an automatic quant matrix. this should/must not be used when doing KDVD.

Sure. The matrix is changed automatically - then it is not KDVD.
But you must activate this feature - otherwise it will use constant matrix (though I don't know which one)

If it manages all feature of CCE, you can provide a matrix in the ecl. But it's not sure this has been implemented.

A full encodin test with AQE
 

RESULTS FOR A FULL ENCODING

DVD source: Harry Potter and the Chamber of Secrets (4:3 FULLSCREEN)

Project .d2v generated by DVD2AVI 1.77.3 (by LOLI.J)

ECL file generated by ECLCCE 1.81 (by robot at D9)

In ECL file were configurated:

1 - Built-in QMatOp in encoder enabled putting the "adjust_q_matrix=1" "by hand" in ECL file

2 - Min Bitrate: 300 kbits/s

3 - Max Bitrate: 8000 kbits/s

4 - Average Bitrate: 2876 kbits/s (Calculated through Calcumatic by Kwag at kvcd.net)

5 - Mode: 2 passes VBR

Q-Mats gererated by AQE (in "0 - zero - pass", through DCTune by NASA):

Expected video filesize: 3538348 KB (estimated by Calcumatic)

Video filesize generated by AQE in 2 passes VBR : 3846201 KB

Script .avs used:

SCREENSHOTS

A - Video file .m2v generated by AQE

http://www.digitalfaq.com/archives/error.gif

http://www.digitalfaq.com/archives/error.gif

http://www.digitalfaq.com/archives/error.gif

B - Original DVD

http://www.digitalfaq.com/archives/error.gif

http://www.digitalfaq.com/archives/error.gif

http://www.digitalfaq.com/archives/error.gif

(The screenshots were captured with native tool in WinDVD and were compressed im jpg by one itself - I don't do any interference as rezise, compression quality etc)

CYA!

Re: A full encodin test with AQE
 

That's a pretty weird (flat), non optimal matrix :roll:
I can't even begin to imagine all the frequencies that are being lost. ~300MB off :?:
It's WAY off target for a 2-pass encoder :!: :!:

-kwag

That's true that this matrix is really weird. But the encoded snapshot are very good. And the frequency loss acted as a denoiser (very clear on the third frame). Funny...

(OT)
And talk about doom9 preachings, I just read that thread where SAPSTAR is obviously violating GPL, because he really didn't understand the license.
Welcome to the real (GPL) world :D

In his own words:

" - I removed the GPL licence file
- I don't plan to release the sources until a certain time"
http://forum.doom9.org/showthread.php?t=96073

:mrgreen:
He removes the text file, and thinks that's good enough!
Of course if it was Moviestacker, they would all be raising hell.
But I guess as long as it's "produced" at their site, they can all cover that up :roll:
(/OT)

-kwag

Yes indeed!
But that frame is mostly flat surfaces, so I wonder how some sharp details (trees, branches, etc.) will look. Based on those numbers, they will probably suffer heavily.

-kwag

I thought the same that you ! :D

Cheers,

That Matrix is for such (non optimal) sources even vey good IMHO.

As you can see there are almost no "low/mid" details in the movie. Its like youre comparing a photography and a diapositive. So as almost all low/mid areas are almost flat, a quantisation is not necessary.
And the "denoising" comes maybe from the last "71" values.

We mainly do use one generic matrix, but sometimes (if you got time and if youre freaky enough) special individual matrixes are the touch of whipped cream on the encoding ;)

We should have a look at that automatrix (Nasa?) generator.

Interesting.
Would it then be possible to use a bunch of matrices patched with The Notch in an automatic encoder selection?
Cheers

OT
You are right, right, right!!!
Take a look now at the thread and see what happends!!!
End OT

Well, poor guy :!:
He should have read the GPL/LGPL license before doing what he did.
SAPSTAR is obviously violating the license, because after reading that thread and reading his own documents, he has obviously hard coded/linked in avcodec libraries, and that IS a violation to the LGPL license.
So, as I consider now this program to be illegal (for the time being), we will not discuss it here anymore, until the guy straightens it.
I will not let this become another Moviestacker issue, and we will NOT discuss illegal programs on this site. Right now, as it stands, AutoQMatEnc is illegal :!:

End of thread.
Thread will re-open if/when SAPSTAR complies with the license.

(Note: People should be using BSD style licenses. Then none of this would happen, as BSD is truly "FREE", without any "strings" attached :mrgreen: )

-kwag

Also EclCreate is a good GUI to AQE.

http://www.vmesquita.com/forum/index...23482#msg23482

Hi,

I've been playing a bit this week end with OPV, and I ended in encoding a movie at 704x576, with an average bitrate of 1388, which is what I wanted.

With HC, this movie come almost perfect, but with AQE, there is some very ugly artifact is some very bitrate demanding scene (fire, ghosts, ...).
The final size is almost on target, but BV tell me that in this ugly scenes, the Q rise to 29 during almost 1 minute... With this bitrate, I get spike of 6018 (max bitrate is 8000), so it seems compliant.

I've been encoding yesterday in 2pass, and the complicated scenes are correct. The max. bitrate is around 6000 and the max Q is 5.6, so it seems correct.

I'll have to check the output to see if it looks better than hc, or not.

I should also try quenc, as in 2pass mode, the bitrate allocation is done completly in quenc, and not using libavcodec... (Las time I checked, hc was the clear winner! :-) )

Salu2
Fabrice

I believe it will all still boil down to libavcodec, because QuEnc is just a front end to it, so no matter what front end is used (QuEnc, FreeEnc, WhateverEnc), it's all the same thing, which depends on the same library :)
Or, am I wrong :?:

-kwag

Hi,

As far as I understand (and that's the same for AQE), you can drive the way libavcodec allocates the bits, by modifying parameters, and doing yourself the allocation (that is using libavcodec only encode a frame, and not deciding how many bits it will allocate).
In the case of qenc, Nic uses the xvid algorithm.

I think Phil was doing some test with that (posted in doom9?!).

What is clear is that with a 1388 average target, the max is 6000, so it have to be cheched that with higher average bitrates, there is no problem...

Salu2
Fabrice

OPV is not tweaked still as said SAPSTAR.
He says that already get rid of the spikes over DVD compliant.

Wonderful!!!* :o :o :o

And now, the quality of both OPV encoding ? ;)

(with snapshot if possible).

Question to fabrice
 

@fabrice

Hi there!! In your test encoding with AQE, did you turn ON builtin QMatOp or to use a 'custom matrix' like KVCD 'Notch' one ? Because of SAPSTAR's words, the 'low bitrate' mode is optimized for QMatOp turned ON.

BTW, SAPSTAR said me that will work hard on OPV mode using a machine on your work cos he have only 1 machine in your home, which does difficult to do tests on this mode, already he prefers to use your machine for to do multipass development. I hope that more donators come in to do donations and so he gets a new machine to accelerate the development.

Ah, I wanna to report that I found out that AQE works like a charm with RB-Farm in using DVD-Rebuilder for DVD backups. I did a test using my Athlons XP desktop and notebook where I set up a small LAN and all was good. This also was reported at VM.com and D9 boards.

Regards on libavcodec RC: yes, fabrice is correct. Libavcodec is 'the engine' to build a frame. RC and others features are controled by encoder itself and have been tweaked from the beta to beta releases (thanks a several tests done by beta-testers - me one of them ;) )

Ah, and it's great that this topic was re-opened here! Congrats!

Cya!

I only keep the AQE streams, as CCE is well knowed.
I will post snapshots and another info you ask me (avgbtr by birtateviewer, etc., what you say me). But what is the better method to take a shapshot of same frame (avisynth?).

Bitrate analyses.
 

I've encodeded a short clip of a movie (Donnie Darko - 2004 - Region 4). Besides the DVD, I'd done a MPEG4 backup for watch it on my desktop and on my notebook (mainly when I'm working in 24 HOUR Full time :( ). For tests purposes only I used this clip from MPEG4 file. OK, lets go to facts:

1 - I used a custom script for such MPEG4 source (nothing special: a deblocker, a denoiser, resize and a finally a sharpner).

2 - I encoded using AQE in OPV mode and chose Q=40 (the purpose is to do a low bitrate encoding). QMatOP is done ON.

3 - After finished the encoding, I used the MPEG2 stream generated on Bitrate Viewer 1.5.054, DVD-Lab Pro 1.0 (which has a tool for analyse the bitrate of MPEG2 videostream) and VirtualDubMod 1.5.4.1 (for average bitrate information that it returns). Lets go to numbers:

3 - Used the MPEG2 stream without to apply the 'pull down' on it:

3.1.1 - Bitrate Viewer 1.5.054:

Peak: 6341 Kbps
Average Bitrate: 1160 Kbps

So, no bitrate spikes at all and the stream is compliant with DVD specs.

4 - Used the MPEG2 stream which was applied the 'pull down' on it (DGPulldown):

4.1.1 - Bitrate Viewer 1.5.054:

Peak: 8048 Kbps
Average Bitrate: 1472 Kbps

4.1.2 - DVD-Lab Pro 1.0 (used the Bitrate Viewer tool present there):

Peak: 8050 Kbps
Average Bitrate: 1920 Kbps

4.1.3 - VirtualDub 1.5.4.1:

Average Bitrate: 1531 Kbps

So, there aren't bitrate spikes over the maximum and the stream is DVD compliant.

I won't present screenshots because the quality is (of course) no good considering the source and Q used. The aim of test was just to do a bitrate analyse in order to see if the output generated was compliant/no compliant with the specs.

Cya!

Hi all,
How encoding time in 2pass mode can be more 3 time higher that OPV mode?! 8O
in OPV mode, you have to make prediction pass, and 2 pass take 2 time the normal encoding time to encode your movie...

With 9 hours, it last longer than hc in 2pass mode, with a similar/lower quality

I stick to kvcd matrix for all my encodes, as it give me higher quality, with less blocks and details low at low bitrate encode. and with 2 pass, if the auqlity is the same (prefer to spend a full night encodeing with a perfect size, instead of a mid night encode that I have to reencode...)

Salu2
Fabrice

I'm doing it with virtualdub (to copy source frame to clipboard) and mspaint (to paste it and create the jpg file).

Could have a better way, but if you don't compress to much the file, the size is not to much.

Fabrice

This is because the Multipass mode includes a 'zero-pass' where the VAF file is created (as just as happens with CCE). So, the 2-pass VBR implies to 3 pass in truth, so explaining the time left for 2 pass being 3 times the time left for OPV ...

Regard on custom matrix, the encoder hasn't any problem with them. You can use anyone that you want.

Regard on the artifacts that you saw, could you post a snapshot showing them please ? Just for curiosity, are you using the last official release ?

Cheers,

Hi,

So it's more a 3 pass encoding. Wouldn't it be enough to do a 2 real pass (1 for VAF and the other for encoding?)?

About the artifacts: these are the norma artifact that you get when you have a Q of 29, with low bitrate (blocks, and mosquitos).
In bitrate viewer, you can see when the Q becomes crazy.

And my test has been done with last official version (0.31b).

If you really want too, I can post picure and BV screenshot when the Q rise til 29, but as I said before, I'll stick to hc, as AQE don't make better the speed or the quality of hc.

Salu2
Fabrice

I think also than HC is better quality.
Maybe we could compate AQE CQ mode with HC 2PVBR, quality wise.
As CQ mode is a lot quicker than HC.