QuEnc 0.59 Beta 4

[Nic]

http://nic.dnsalias.com

Minor update:
Slight change to rate control settings to help with undersize with 2-Pass (I'm not sure if 2-pass is really worth the effort with current libavcodec).
Should have fixed MPEG-1 file creation. (i.e. now writes the AR correctly)

It's now been compiled with MinGW/MSYS for the first time. Cygwin doesn't like my machine anymore. I'm not sure if they'll be a speed or stability difference. But it seems ok to me.

Cheers,
-Nic

[dragongodz]

Should have fixed MPEG-1 file creation. (i.e. now writes the AR correctly)

did a quick 352x288 mpeg1 cbr and bitrate viewer and gspot both say 4:3(as i had selected in QuEnc) and it plays fine on pc. 1 bizarre thing is if you go in to properties in MediaPlayerClassic it says AR 176:135 for video size. as i said though plays fine on pc but dont know if that would make any difference on hardware players.

I'm not sure if 2-pass is really worth the effort with current libavcodec

or to be more exact the rate control that if you use 1 setting cant make high bitrates and if you use another wont always keep below max bitrate.

[lithoc]

352x288 mpeg-1 will play just fine with hardware player.
If encoding to VCD, i think concern should be the bitrate.

I don't think there's Aspect Ratio standardise in mpeg-1.
That;s why i'm always get weird Aspect Ratio for mpeg-1 in media player classic but i can play with hardware player once mastered into VCD.

If you play the VCD mastered file in MPC. It will display correct aaspect ration..

Weird....

[video_magic]

^ Does that mean the DAT file which I think you can get off a VCD has extra data for an mpeg1 which means it can properly on the hardware players. I guess this is information like aspect ratio and FPS and other things to do with an MPEG stream? I have renamed DAT to MPG sometimes when I want to play a file on the PC and it plays fine. I wonder if QUENC could write some extra non-standard-mpeg information to the files like this which would be useful but harmless to whatever application or player has to deal with them (harmless to applications & players that wouldn't need it)?

[dragongodz]

well i did a little tests setting it to 16:9 and yes it stretched as it should on playback with MPC. so it is working.

as for VCD well i have doubts AR would be needed anyway in the sense that VCD doesnt support 16:9 playback etc so hardware players should just play it 4:3 anyway. people would have to test that for themselves however.

asi said i just found it funny to see.

[freelock7]

Yes, Nic, it's better about prediction. But be careful about bitrate spikes caused by a low quantizer.
The underflow risk is very high with this version. If I should choose a version among the 059's, the beta3 is the best for its stability and the good work of the quantizer. Now, the undersize prediction appears in VBR high bitrate (>4500kbs). Encoding in CBR high bitrate >5000kbs can resolve the problem and you have a great quality too.

[Nic]

Thanks for the feedback. At present, we're trying to find a nice middle ground. It's tricky.

Apart from bitrate, I think everything's pretty stable now. Probably will go to 0.60 next time and may do something directly to the rate control.

-Nic

[Affar]

Hi

I've got an XviD video that, when converting using avisynth with QuEnc, it is reduced 3 frames in the final video. It doesn't matter if I charge it with directshowsource, avisource or load video direct, the final movie is always the same.
Here there is a sample of the file.

SAMPLE

Thanks. See ya.

[dragongodz]

The underflow risk is very high with this version.

it shouldnt be any riskier than 0.54 was however since thats what it is based on, plus some more tests i ran.
i will do more tests with settings later to keep trying to find a better middle ground until something is done about the RC.

It's tricky.

understatement of the year here folks.

may do something directly to the rate control.

just so people realise this is not as easy as it sounds. the options are
1. add some small in code changes to make RC atleast a bit better
2. major changes in code to make RC work properly or close to it
3. add secondary new rate control, based on another working RC

now even with option 1 Nic would have to either get the changes accepted in FFMpeg or make the changes every single time libavcodec is updated for QuEnc. neither of which is as easy as people may think. ok making the changes every time may not be that hard if they are few but its still a bugger to have to do.

[Koepi]

I encoded a simpsons episode (that one where Homer builds a website, need to show some collegues that one as they always want blinking, flashing things on the company's homepage) which ran yesterday evening to SVCD - once with HC and once with QuEnc 0.59b4.

Average bitrate should be 2500kbps, max set to 2554kbps.

The encode came out just fine, with being visibly better with QuEnc than with HC.

Thanks for the program Nic, it really rocks! (and also thanks to the libavcodec/mpeg2encoder coders of course )

Cheers
Koepi

[Nic]

@Koepi: Glad it went well

@Affar: Dragonball z samples are always welcome Is the 3 frames missing still occuring even when using that short sample? I'll look into it.

@Dgz: I'm hoping I can make it so I can control a frames QP on a frame by frame basis from QuEnc, then i'm going to try and do the ratecontrol from inside QuEnc. I'm hoping to use x264's ratecontrol, because I really like the code (it's easy to adapt). Of course, this could all be an impossible pipe dream that I haven't thought through properly yet, but it's worth a try
(x264 only does encoding on a frame by frame level at present (unless using CBR or non existing adaptive quant) so I should be able to apply it pretty easily)

-Nic

[dragongodz]

I'm hoping I can make it so I can control a frames QP on a frame by frame basis from QuEnc, then i'm going to try and do the ratecontrol from inside QuEnc.

hmm interesting idea. you may want to have a look at Avidemux by Mean sometime and see what that does since it has an option to use Xvid RC from the Xvid.dll with libavcodec if i remember correctly.

Of course, this could all be an impossible pipe dream that I haven't thought through properly yet, but it's worth a try

if anyone can do it i know you can.

[Nic]

"it has an option to use Xvid RC from the Xvid.dll with libavcodec if i remember correctly."

Really?! Jeeze, that would solve all our problems. I'll look into that now. (XviD's ratecontrol code is very good (but a lot more difficult to get to grips with than x264's)

-Nic

ps
Looks interesting, for those interested:
avidemux-2.0.38rc2b\avidemux\ADM_xvidratectl\ADM_xvidratectlVBV.cpp
Is the file to look thru in the source. Even mentions it uses some of Peter Cheat's ideas. Could be promising.

pps
Ripped the XviD rate control out of AviDemux and got it compiling under VC6. Now just got to whack it into QuEnc. This will be interesting. Maybe I could contact Mean, do you speak to him dgz?

[dragongodz]

Really?! Jeeze, that would solve all our problems.

yes i thought it may be easier than reinventing the wheel.
then again i also thought it was an interesting idea here
http://forum.doom9.org/showthread.ph...0&pagenumber=3

Maybe I could contact Mean, do you speak to him dgz?

no only talked to him on here. unfortunatly he doesnt seem to drop in often. you can probably catch him on the avidemux forum however
http://avidemux.berlios.de/forum/
or you could try the contact email on the main avidemux page
http://fixounet.free.fr/avidemux/

[Koepi]

I'm already starting the la ola waves here - looking forward to the beta5 incorporating xvid's ratecontrol. (If it has "strict scaling" I'm even dancing around naked for you! ).

Cheers
Koepi

[dragongodz]

If it has "strict scaling" I'm even dancing around naked for you!

koepi - that is an image i really didnt need before going to bed you know.

i agree strict scaling would be good aswell but even without it should be an improvement on the current RC.

[gigaset2004]

Hi,

Nic wrote :

(I'm not sure if 2-pass is really worth the effort with current libavcodec).

So i wa a little suprised.

Is it recommended to use Quenc in single pass ?

[Nic]

@gigaset2004: I really don't know. Never done enough testing to see if 2 pass helps quality enough to be worth it. It definitely doesn't work as it should.

@all: If you do some tests i'd be happy to hear the results

-Nic

[Koepi]

...do you have a "new" version with the xvid scaling code flying around already? Did I miss something?

(I don't know if 2pass delivers better quality than 1pass currently - I naturally assumed this is the case as the bitrate is distributed more even, and from watching some svcds i made with quenc i _think_ 2pass looks like a close-to-proper quant distribution).

I hope this helps (and is what you wanted to know )

Cheers
Koepi

[Nic]

@Koepi: Close to a new version. Writing it now. Able to control the Quant being used to Encode on a frame by frame basis. Also retrieve the Quant and FrameType after encoding the frame. Now just to hook it up

EDIT: Well, not sure if i'm putting in the right numbers. But just asked it to do a 5mb encode, and a 5mb encode came out.

EDIT2: Motherf**king computer crashed and now I can't load AVS Files. Grr.