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