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? :confused: 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. :D

[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 (http://www.divxhouse.com/pedazito.avi)

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. :D

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. :D
then again i also thought it was an interesting idea here
http://forum.doom9.org/showthread.php?threadid=84479&perpage=20&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. :eek:

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. :D :D

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

[PatchWorKs]

Any chance to have a FairUse (http://www.fairusewizard.com/Release/fu-src.zip)-like features version (i mean direct DVD encoding, 4:3 auto-crop feature, etc) ?

[Nic]

@PatchWorks: No, that would be for another app.

@all: Just a progress report on ratecontrol:
The ratecontrol only works for 2 pass encodes. Which is cool, because the 1 pass encoding is ok with QuEnc. I've got the code working. Not definitely sure i'm pumping in the right numbers. But most of the time it's looking very promising.

I don't think it will be perfect, there's a tradeoff between always getting the exact size and getting no buffer overflows (Especially when encoding where the avg bitrate will be close to the maximum).

Exciting hey?

-Nic

[video_magic]

very! :D Really looking forward to playing with a new version, thanks a lot Nic :)

[dragongodz]

Never done enough testing to see if 2 pass helps quality enough to be worth it. It definitely doesn't work as it should.
the problem with libavcodecs 2 pass is that it doesnt make enough effort to do what its meant to. that is bitrate constraints and distribution. both are done so in theory should be better than 1 pass BUT for example max bitrate can be exceeded(spiking) because the RC basically makes 1 go at altering it and then if its still not right doesnt recheck and try again. so as Nic said it doesnt work as fully as it should. 2 pass CBR appears better than 1 pass CBR in the couple of small tests i did though but this shows how 1 pass mode isnt working 100% either since 1 pass CBR should be easier, encode frame -check size - if not right encode again until it is, thats not being done. oh and setting a min bitrate, which should really be done for some hardware dvd players, throws the RC off aswell. are people starting to see how flawed libavcodecs RC is now ? :D

Motherf**king computer crashed and now I can't load AVS Files. Grr.
NIC!!!!! i dont think i have heard such language from you before. ;)

The ratecontrol only works for 2 pass encodes. Which is cool, because the 1 pass encoding is ok with QuEnc.
cool. maybe replace 1 pass in the future aswell if this goes well , even if just CBR ?

I don't think it will be perfect, there's a tradeoff between always getting the exact size and getting no buffer overflows (Especially when encoding where the avg bitrate will be close to the maximum).
well once you have this working that sort of thing can be looked at more if need be. still should be better than current RC.

Exciting hey?
indeed, indeed. :D

[Fishman0919]

Nice, Nice....very nice!

[kitsaros2000]

yep i also did an vcd test and works well !
Well done nic !!!
Thx !:cool:

[mean]

There is also a couple of patchs to lavcodec itself that may be of interest :
- 3:2 pulldown

- better enforce vbv with "native" 2 pass libacodec rc code. It is not as good as the external ratecontrol as lavcodec does not try to see there is a intra coming and let the buffer underflow but at least it tries to keep it whereas with unpatched code it does not try at all.

- separate actual bitrate/vbv buffer size from the one in the mpeg header vs the one used

The big advantage of using the external ratecontrol is that you can have several ratecontrol the api (if you kept the interface) is very simple.

[dragongodz]

mean - nice to see you dude.

The big advantage of using the external ratecontrol is that you can have several ratecontrol the api (if you kept the interface) is very simple.
which would mean in theory Nic could use x264 rate control ,or whatever, instead then.

also looking at the cvs date avidemux\ADM_xvidratectl\ was last updated 3 months ago and just says things like "began adding constrained ratecontrol to xvid rc" and "smarter rc" so not totally up to date or complete ?

[Nic]

@Mean: Thanks for posting. Do you have any links to those patches? Or are they part of avidemux? (and if so are they marked in the source?). I'm on the ffmpeg-dev mailing list and haven't noticed those patches.

I kept the interface. Very nice and easy to use. Although it's hardcoded to use a min quant of 2. Which causes problems with high bitrate (DVD style) Encoding. You may want to lower that for avidemux.
One question; When using setVBVInfo, i'm currently using: setVBVInfo(9800000/8, 0, 224) Does that look right to you for DVD encoding (max bitrate 9.8MBits, 224 buffer size?)

What's your current opinion of avidemux's XviD VBV ratecontrol?
Also, what do you think is better for compliant DVD Encoding, ADM_newXvidRc or ADM_newXvidRcVBV? They both seem to have VBV code.

Cheers,
-Nic

[mean]

They have been posted & rejected.

The 3:2 pulldown appears from time to time, Mans did an updated patch toward cvs not long ago.

The min quant of 2 is to avoid qz overflow when using quant=1 with libavcodec. it might not be needed anymore.

224 is ok for DVD.

The ratecontrol/VBV is performing ok most of the time.

The anticipation of intra is not working in all cases, a big
intra coming in might cause a underflow from time to time, but it is rare (like 5 time on a whole movie).

All patches in adm_libavcodec has a //MEANX in it to easily spot them/merge them.

[mean]

You might also be interested in looking into the ADM_mplex directory
which offers a simple interface to use libmplex as output muxer which works better (in my experience) than lavformat mpeg muxer.

[Nic]

@Mean:

"They have been posted & rejected."
Michael can be picky.... ;)

"The 3:2 pulldown appears from time to time, Mans did an updated patch toward cvs not long ago."
I found the pulldown patch (dated: 29/11/04). I'll look into adding that. Thanks.

"The min quant of 2 is to avoid qz overflow"
It definitely causes problems, although quant 1 has always been bad for ratecontrol (still is with XviD), it is often necessary for high bitrates.

Thanks again, I'll look through avidemux's code. Nice app.

-Nic

[dragongodz]

although quant 1 has always been bad for ratecontrol
and it really should not be. does mpeg2enc's 2 pass use quant 1 ? i ask since that is meant to never exceed max bitrate etc.


DVD encoding (max bitrate 9.8MBits
9.8Mb/s is max for video only of course. if you intend to have any audio and/or subs etc then they need to be subtracted. so say you have 1 224Kb/s audio stream aswell you would need to reduce the 9.8Mb/s by 224Kb/s + a small extra small amount for muxxing overhead.

[Nocturno]

i did some testing with this version and RC doesn't seem to work correctly for 1-pass either

running with:

Quenc.exe -i "E:\avi2dvdtest\Movie0.avs" -o "E:\avi2dvdtest\Movie0.m2v" -maxbitrate 8000 -b 5650 -1 -aspectratio 16:9 -gopsize 12 -mpeg2 -vbr -hq -scene -priority 3 -nointerlaced -cmatrix "C:\Program Files\avi2dvd\matrix\Standard.txt" -mpeg2mux noaudio -auto -close

gave peaks above 10000 (10542 highest)
and multiple above 8000

the file won't multiplex with dvdauthor's mplex (to many framedrops)


Num. of picture read: 157728
Stream type: MPEG-2 MP@ML VBR
Resolution: 720*576
Aspect ratio: 16:9 Generic
Framerate: 25.00
Nom. bitrate: 8000000 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 8
Pic. structure: Frame
Field topfirst: No
DCT type: Frame
Quantscale: Linear
Scan type: ZigZag
Frame type: Progressive
Notes:


can't wait to see the new RC :p

[dragongodz]

i will be continueing discussions with Nic by PM so dont expect to see too much more indepth discussion here, though Nic does tend to want to tell people what he is doing. really most people either wont fully understand what we are talking about or want to start asking for more. just the bits we have discussed already has started "cant wait" responses and got people excited when there is no saying when this will be ready etc. knowing Nic it could be any time. :D

[Nic]

@dgz: :) I like kicking up a bit of excitement and interest. It motivates/reminds me to continue. 1 pass may have been effected by the lmin = 1 change.

@Nocturno: Thanks for the feedback. Next version will probably be 0.60 which will have Beta 3's 1st Pass RC and XviD's 2 pass RC.

-Nic

[freelock7]

Great job guys!
Hope to use the v.060 soon!

[dragongodz]

1 pass may have been effected by the lmin = 1 change.
had a quick look and you disabled the lambda for 1 pass mode aswell and then comment "Seems to work well for 1 pass, so keep it seeing it is "correct" ". so you should have moved that down to the if ( nPass == 0) section and added the lmin = 1 to the else. you do use lambda in the low bitrate part however which would be fine for either type.

see thats an example of what i thought doesnt need to be discussed here, internal workings. most people will have absolutly no idea what i am talking about. :D

[Koepi]

Well, I for one like to know that. It helps me to see if you talk about peanuts :p

;)

Cheers
Koepi

[Nic]

@dgz:
"thats an example of what i thought doesnt need to be discussed here"
But if I don't talk about it, how will others learn? Also, the main reason I do it is because it's a nice record for me to look back on when I forget the info. Which is inevitable ;)

[dragongodz]

uh-oh, i think i am being ganged up on here...or atleast out voted. ;)

ok then let me make a comment here that i already said by PM.

go back to the thread where i originally said using Xvids rate control would be an interesting idea(link posted already). peter cheat makes an interesting remark about how Xvids RC could still underflow and how another check is needed to help insure it shouldnt. very relevant for using quant 1 because the simple fact is quant 1 should not be a problem for rate control at all. there are plenty of encoders that use quant 1 fine. :D

[Nic]

@dgz:
I'm not sure how relevant Peter's post was in that instance (he wasn't looking at avidemux's current RC), but I can see what he's saying. It can still underflow. Although I think it will be very rare. I think my best current solution is something that Peter tried, and that is if underflow is detected, re-encode the frame again with a different Quant until there is no underflow...
...However, I need to have a clip that causes underflow to test.

EDIT: Hmmm, not sure if this will work.

-Nic

[dragongodz]

he wasn't looking at avidemux's current RC
no he looked at Xvid 1.1 branch RC where VBV was introduced so is relevant somewhat.

if underflow is detected, re-encode the frame again with a different Quant until there is no underflow...
well actually it would be re-encode GOP until no underflow or max quant limit reached(if not using skipped MB for P and B frames). so you would have to buffer the frames , do the VBV check, redo if not correct, write once all ok. from what i understand HC does it similar to this for example. :)
if writing every frame as read then the last frame is the only place you could try and adjust so then you couldnt insure VBV 100% of the time, though you could also reduce the risk if you actually slightly underdid early frames in the GOP i guess.

Hmmm, not sure if this will work.
which part ?

[Nic]

The re-encoding the frame. Re-Encoding the GOP would work. Real Pain though. I'll put out a version without this. It reports on what it detects as overflows. People can then report how good/bad it is. While it's out i'll work on the re-encode GOP. It may also just happen with big I-Frames as mean suggested. In which case, it might be easy to fix with just one frame.

i'll PM you now with an early release. So you can look.
(I'll PM Koepi as well)

-Nic

[dragongodz]

actually since you should be able to get the achieved bitrate from the first pass and then able to scale each GOP and frame to the target bitrate you would just have to also account for VBV and max limits. if the GOP exceeds then reduce more so it doesnt. store undersize amount and give it back to the next GOP that can have it (or even a part) without exceeding, that way also trying to maintain target bitrate.

well i should be back in maybe 6 hours give or take. so plenty of time for others to think about it and make of my ramblings what they will. :D

[hank315]

so you would have to buffer the frames , do the VBV check, redo if not correct, write once all ok. from what i understand HC does it similar to this for example.Yes, something like it.
Just check which needed frames should fit into the VBV buffer at each moment.
If they overshoot just adjust quants for these frames and check the VBV again.

[dragongodz]

ok some tests ran with 0.6 early bird special version. ;)

max bitrate. 1 example target 2000, max 2400, 0.59B4 peaked 2700 while 0.60 peaked at 2408. so it may not be perfect but is pretty good and much better than 0.59B4.

i did notice the occasional large P frame poking up aswell. anyway i will do a longer encode tonight and try to author it with a few different programs and see if any complain. :)

hmm why is 0.60 starting with IIIPPBB (or decoded order IIIPBBP) ? much better IPPBB(decoded IPBBP) for first GOP i would think.

hmmm now on to some funny business.
2 pass with 0.59B4 - encodes fine
1 pass with 0.60 - encodes fine
2 pass with 0.60 - 2 frames short and quits or sometimes freezes ????

now before blaming QuEnc i have to say HC has now started being funny too. that is 0.12 and early 0.13 betas all encode correct number of frames but tend to freeze up at the end. the latest 0.13 beta however ends fine but encodes 1 frame short (and that means 1 frame less than it says in its gui aswell).

WHAT THE ?????

so i tried uninstalling Avisynth 2.55 and reinstalling it etc and the same result. tested with avisource(), directshowsource() and mpeg2source() (dgindex etc) even using different clips etc. nothing made any difference.
so i will download Avisynth 2.56 pre-release later and see what that does, not holding my breath though.

[Koepi]

I didn't look deeper into the spec-compliancy of the bitrate control (I encode at 950kbps with max bitrate at 8000 so that would be quite useless ;) ).

After the second pass I get a crash now ("Access violation at 0x0000048"). The resulting mp2 file works fine though. I didn't check the file for DVD compliancy. The image quality is fine.

(I do a two pass of a video with audio, resized to "half" ntsc resolution [352x480]. The sound is encoded as ac3 with 192 kbps. MUXing is done into "DVD". GOP size is 18. 2bframes max.)

One suggestion: as it is possible to produce muxed a+v output, on the save file-dialog the extension mpg would be useful.

Thanks a million again,

cheers
Koepi

[Nic]

You know the moral of this story? Nic shouldn't test his QuEnc with B-Frames turned off. D'oh! I get the crash too now, easily fixed.

I'll add .mpg as an extenstion.

Back to testing...

-Nic

ps
It's also b-frames causing the weird 3 I frame start. I'll try to compensate.

EDIT: @Dgz & Koepi: Download from the same link again for the updated version. Make sure it states it's RC2, so you don't download the same file again due to cacheing.

[dragongodz]

Nic shouldn't test his QuEnc with B-Frames turned off. D'oh! I get the crash too now, easily fixed.
cool. atleast QuEnc will be back working.

still doesnt explain what the hell has happened with HC though, thats really strange. as i said old versions encode correct amount of frames but dont close(hitting exit button does work) while the latest beta closes but is 1 frame short and hank315 cant reproduce it.

i installed Avisynth 2.56, i uninstalled any programs from the last week, i cleaned the registry, i even restored back a week and nothing made any difference. so as you may guess i had no time to test authoring the produced files.

[onesoul]

@dragongodz

Maybe the missing frames could be related not to the encoder as jdobbs says in the following quote (which can be found here (http://forum.doom9.org/showthread.php?s=&postid=639885#post639885)) :
Actually I gave it some thought last night and realized there are instances -- usually at the end of a segment -- in which bad cuts might make it impossible to decode and present a frame (or even two) to the encoder. The frame would show in the overall frame count -- because that is created by counting picture start codes, but would be dropped. The only alternative in those circumstances would be to present and encode garbage. An example might be a B-FRAME when a cut point was made at an open GOP. I've also seen other examples of forward references against which there are no forward frames.

In those instances the drop of a single frame isn't significant -- and the PTS is reset at the start of the next segment. So what I'm going to do to cover these possibilities is to, instead of aborting, make a note in the status box and continue. If the difference gets above two frames I will continue to stop the encode.

The reason I added that sanity check in v0.83 was because CCE v2.70 appears to be bombing fairly consistently due to changes in the way it handles high-demand frames and balances them against the maximum bitrate. This "catch" code is there to make sure I'm not passing over segments that might be a thousand frames short because of the crash.

I'll modify the code for v0.85.

[dragongodz]

ok just tested new RC version. all good. no crash and all frames encoded. :D
oh and no more III either. :cool:

Maybe the missing frames could be related not to the encoder
nope this was Nics fault. :devil: ;)

i just tested the release version of HC 0.13 aswell. for results of that and download link go to the "who wants to try a new mpeg encoder" thread. hmm may suggest he start a new thread with that version with a better title. :)

[onesoul]

I had understood that dragongodz, just was trying to point some situations (like the early hc) when the encoder couldn't decode a frame, not being his fault, which apparently can be solved, (maybe the way jdobbs described).

But then again I am just passing information, I am not really in the field :).

[dragongodz]

ah but thats the thing. the last frame with HC 0.12 is decoded and encoded, its just the quitting that no longer works since i got that beta. doesnt matter now since 0.13 release version is working fine. so enough talk of HC here methinks. :)

[Nic]

Well, if I don't hear anything bad about QuEnc from you two, RC2 will probably become the released 0.60.

-Nic

[Koepi]

Gimme an hour to test please :-)

Cheers
Koepi

[dragongodz]

i would have liked a chance to test with authoring aswell(after wasting all that time) but since the peaks are lower etc i am easy. definatly is an improvement to RC by my books.

things like tighter control (maybe foxers strict scaling would help with this too) etc can be looked at later anyway.

so i am easy. :D

[Nic]

@dgz & Koepi: Take as long as you want. No rush. Just adding Mean's pulldown patch now, so got to test that first anyway. Keep testing, if you can, there's no rush to get this out of the door.

[dragongodz]

cool. i have some spare time tommorow morning (currently very late night here) so i will do some more tests then and let you know.

[Koepi]

Ok, works fine as it should! :)

No crashes, nice constant quality from a short visible test. IMO you can put it out :)

Cheers
Koepi

[freelock7]

-Nic & Dragongodz
Any chance to test a beta5(?) with the new RC2-last- version before the official 0.6?

[Nic]

@freelock: Looks like I can't PM you. So a bit tricky to send you the link.

[freelock7]

Sorry! It is corrected now!;)
Before all, THX again to let me try the RC2!
The main change comes from the bitrate distribution. It moves much more with a linear quant.
The fast scenes encoding gives better and better results but it could affect some quite scenes with a lower bitrate to compensate the high bitrate distribution.
Some scenes are encoded with a min_bitrate of 700! It is too low (macroblocs).
Maybe you could correct it with a min_bitrate setting?
Settings: VBR=3000/High quality/GOP=15/Dct=10

[guada 2]

Hello NIC,

I have make a particular test with quenc4.
Would be without fear, these parameters are special GUADA 2.
Look at:

Test1:
mpeg2(svcd) /bitrate:180 kbps /vbr hq /treillis quant /2 pass /gop:12, max bframe:2 /dc:9


Test2
mpeg2(svcd) /cq:14 /vbr hq /treillis quant /gop:12, max bframe:2 /dc:9

Note:
Test 2, is 4 times faster than the test 1.un favours certain for a pass.
its size is identical to test 1 but -1. (Test2:4.75 mo, Test1:4.76 mo).
The quality of image is better than test 1. the macroblocs are almost not perceptible.


Interrogation:
The CQ would not be it preferable with mode 2pass, more rapid and more precis with this bitrate.
It is not a honourable test, but I took this example because the time of encoding is of primary importance for all one each one, quality and the final size is the business of all.

Which is your opinion on this kind of test?

[dragongodz]

The main change comes from the bitrate distribution. It moves much more with a linear quant.
yes. strict scaling would reduce this somewhat aswell and generally provide a more consistant distribution i would say. 1 thing at a time though, remember this is a pretty major change Nic has done.

Some scenes are encoded with a min_bitrate of 700! It is too low (macroblocs).
no it depends on the footage etc. you will see most encoders will use or reccomend a min bitrate of around 500 anyway. as i said above though, the distribution needs some tweaking/changing but that can come later. in my opinion this RC is working better since it is not spiking anything like the old RC can do.

ok Nic i did some tests including authoring. no complaints from other programs, results play fine, all looks good. :D

[guada 2]

Hello,

If I have make this test, it was to test the mode One pass VBR of NIC.
(ah! I forgot scene detection and max bitrate 180 kbps).
What I can say it, it is "as" effective as CCE.


In a word it is good work.
Remain, that this bitrate is not a working tool.
But my tecnique rests on low bitrate, in order to find precision adjustments for the high bitrate.

Bye

[Nic]

@All: My computer's proper dead now. :( So that will delay the next release somewhat. Also, got to get the source off the harddrive....

[dragongodz]

My computer's proper dead now
now that sucks. so what part died ?

[Nic]

Just had it up on the bench in engineering at work. Appears to be the motherboard. Or at least that bit is definitely not working, if another faulty bit caused it, I can't detect it (CPU & Memory in another machine worked fine).

Don't know how long it will be before I'm up and running again....
....Isn't this what roughly happened to Peter Cheat? Maybe it's the "RateControl Curse"

-Nic

[dragongodz]

Isn't this what roughly happened to Peter Cheat?
his cpu blew up.

Maybe it's the "RateControl Curse"
dont say that. look at what most of the work i have done with both Rejig and QuEnc have been to do with. :scared:

Don't know how long it will be before I'm up and running again...
ok, please try and keep us informed. :)

[video_magic]

Sorry to hear of your PC troubles Nic - not just because of Quenc development being temporarily halted, but generally ;)

couple of things I wanted to ask. I had almost forgotten about 'Closed GOP', and wandered what the status was and if it is yet implemented in a 'proper' full spec-compliant way suitable for authoring DVDs - I don't know if that is a libavcodec thing - I'm not very technical knowledgeable about all this sorry :(, I just read about it on here a few times and wondered about the current status.
Do we need Closed GOP for DVD-spec compliancy anyway? I can't remember that I ever made out a definitive answer from reading around

Second question - how do you work so damned fast!? :D This rate Control seems to have been a big problem for a lot of people for ages, will your solution be taken up by the team that uses libavcodec (ffmpeg?), I'm not clear on these projects but I do often try out Mencoder and it seems to be a related project also. Last I read in the Mencoder dosc it said Closed Gop not yet implemented.

[dragongodz]

'Closed GOP', and wandered what the status was and if it is yet implemented in a 'proper' full spec-compliant way suitable for authoring DVDs
not something i have looked in to so i wont comment.

Do we need Closed GOP for DVD-spec compliancy anyway?
it is required for things like multi-angle encoding but no not for something like a plain movie.

will your solution be taken up by the team that uses libavcodec (ffmpeg?)
chances are practically nil. they will want a LGPL rate while Xvids is GPL. if they wanted to add a second GPL only rate control which was only avalaible when compuiled as GPL they could have added/used Mpeg2Encs(for example) along time ago as that is meant to be ok. infact Michael said a long time ago he had half written a new/better rate control but has not got around to finishing it. when i say he said it long ago i mean LONG AGO, so dont hold your breath waiting for that either. ;)

[Nic]

@video_magic: I hate hardware troubles..grr. Although my computer has never been 100% stable, and it isn't due to overheating or overclocking (I never managed to track the problem down). So maybe it's been the motherboard all along. Got to go through Abit's RMA process. I'll see how successful that is....

Closed GOP is needed in the DVD spec, AFAIK. However, I believe it is only really needed on Chapter points, so the DVD player can seek to the exact point (LBA) and not worry about the GOPs before it. However, with Closed GOP on, I believe all GOPs QuEnc creates will be closed. Not really too bad a thing. (Also, scene detection gets turned off, not that bad a thing either, stops having multiple I-Frames one after another, etc)

Ratecontrol has been a big problem, but I never considered tackling it like this, the credit really goes to Mean and his avidemux (he should really changed the name of that App, it's a bit misleading). The 2pass ratecontrol is good now in the 0.60 Release Candidates, not perfect, but IMO libavcodec's 2pass ratecontrol is pretty worthless.

@freelock7: Considering the bitrate was 3000, it's not too surprising that it could go as low as 700. But maybe a minimum bitrate setting wouldn't be too bad...I wouldn't recommend it, but it might help. I'll test it when my computer's back up. If you have any more test results, let me know.

One of the longest posts I've ever written here...

-Nic

[video_magic]

Thanks for your answers :)

This is an exciting time for me that has been getting into DVD authoring and other things related to DVD back up and video editing, it seems like everything is happening here!

It is a hard area to become involved in because of so much information to intake and try and remember and make sense of, so many facts! I realise that many of you have a lot longer experience (so use of your time) and I'm very grateful for the help- and the brilliant programs too, maybe Nics computer (and Peter Cheats') died because of all the work being done on them :p

I think I dipped my toes into an area of politics with asking about different projects that might or might not want to integrate - sorry. I can see that there are individual visions of how peoples work wants to develop; I have a few times tried to get into coding and I realise it's a lot of hard work and dedication so I will step back from queries like that in future :devil:
Anyway, I think Quenc is aimed at people like me because of having a GUI, I would like still to be in some control so I think pop up help descriptions that briefly explain what the options mean would be nice for the user - it would also keep the user informed and help them gain knowledge and more appreciation for what they are trying to be involved in :)

[Nic]

"I think pop up help descriptions that briefly explain what the options mean"
They've already been added and will be in the next released version :)

[dragongodz]

maybe a minimum bitrate setting wouldn't be too bad...I wouldn't recommend it, but it might help.
it would be good for some hardware players that are meant to have problems playing if the bitrate drops below 500 or so(i think on a few it was below 300).

as for closed gops well i have never seen closed gop being required for chapter points, just that they need to start on an I frame(the chapter points that is).
my undertsanding is the same as what Arky says here
http://forum.doom9.org/showthread.php?threadid=85836
not that i would use closed gops all the time but when they are required and when not. :)

[Nic]

May well be correct, but I remember at least one DVD where closed_gop was only set on chapter points. I remember it from doing ReJig and trying to set chapter points correctly with authoring.

Got my old computer up and running. AMD 1800 XP, ATI Radeon 9500 pro. It's like 1999 all over again. I'll get my source code off my drive tomorrow (this old beast doesn't have SATA) and probably release QuEnc soon.

-Nic

[dragongodz]

I remember at least one DVD where closed_gop was only set on chapter points.
unless you see it consistantly it could be just the way it was authored or produced. for example ,from memory, most other encoders close the first GOP even when you encode open Gop. now imagine if for some strange reason they encoded each chapter seperatly, that would give you a closed GOP at each chapter, but it would not mean it was needed.

Got my old computer up and running. AMD 1800 XP, ATI Radeon 9500 pro. It's like 1999 all over again. I'll get my source code off my drive tomorrow (this old beast doesn't have SATA) and probably release QuEnc soon.
good news. :D

[freelock7]

Frame extracted from a slow scene

Bitrate/quant
__________________________________
B3 frame | 1301-2.48
RC2 frame | 707-4.40
NU0.01(min_bitrate=1004)| 1255-3.40
NU0.01(min_bitrate=4) | 889-3.20
HC013 1350-4.58
Inconclusive indeed but even though, it shows the compression level too high with RC2.
It wouldn't be a problem if the quantizer could go down but it stays far above.
Naturally, the best encoding comes from B3 and NU with a min_bitrate=1004!
Surprised to see that B3 and NU0.01 (min=1004) have the same settings!
It means the 059 versions have a min_bitrate fixed?

[dragongodz]

freelock7 - but how do they look playing ? numbers alone dont say what effect it has on your viewing pleasure. if it is hardly noticable and you have to really look for it to see a difference then it is not really a problem.

if you read back you will see i have said though that RC will still need a bit of refinement/tuning. in general though it seems to me to be better because it is not spiking like old RC can do and i didnt notice any real quality difference in playback of the clips i tested with.

It means the 059 versions have a min_bitrate fixed?
no. min bitrate is 0 as it always has been. using anything else with libavcodec can throw the RC for loops and totally stuff your bitrate target.

[video_magic]

I apologise in advance for the lack of my technical knowledge in this area but I want to understand how I,P & B-Frames and Closed Gop works. So, it's all to do with I, P and B Frames right?

I think (at the moment) that I-Frames are encoded directly from the source frame.
P-Frames use information both from source-frames and from I-Frames both preceding and after it.
B-Frames only use information from P-Frames - before and after? so can be bad quality.

So when a Gop is closed does this generally mean that scene detection is forced off and an I frame is inserted at the beginning of the next GOP that will not reference any previous frames - from the previous GOP I mean - I am not clear on this because I read somewhere that MPEG does not see frames as linear in order (is that just within each GOP?).

An easy to understand answer for a guy that is trying to begin to understand these matters would be appreciated :scared: :)

[gigaset2004]

@ video

Hi,

I am not am expert for mpeg , but your understanding of I,p and b frames is not correct.

So an I frame is the basic for the p and B frames and the I Frames includes the hole informations for the pictures. - like jpeg -

The p and B frames are only including the differences between the actually I and the following I frame.

That´s it in short words.

The big problem in the degenaration is that no encoder uses the information from the source.

The transcoder use all the info from the source.

An encoder is like a camera and do not care about the original I, P or B frames from the source.
This effect makes the degenarion from copy to copy.

Each encoder have to analyze the bitrates from the source to make a decision for the copy at your rage for Gop lenght ,bitrate decisions
and movements for the resolutions.

tempgenc has a small option to force I,p and B frames from the source but it is not possible to force that option for a hole movie.

The goal would be to take these info´s from the source to give it to the encoder.
If this would be possible we had no more Problems at all.

so i am no crack but i think the goal wold be to combine a program like rempeg2 with an encoder.

Sorry for my english - hope it helps

[Nic]

@video:
So when a Gop is closed does this generally mean that scene detection is forced off and an I frame is inserted at the beginning of the next GOP that will not reference any previous frames
Generally correct yes. Scene detection doesn't have to be turned off, but currently libavcodec does not support Scene Detection AND Closed GOP.
from the previous GOP I mean - I am not clear on this because I read somewhere that MPEG does not see frames as linear in order (is that just within each GOP?).
Yes that's just within the GOP (or at least a closed GOP)

AFAIK

-Nic

[freelock7]

freelock7 - but how do they look playing ?

LGX-Zeppelin crash-clip of 120sec
The Johnson Family vacation-full movie encoding

I chose the lowest scene (frame) and compared between each encoder.

[dragongodz]

video_magic - for a little understanding of the different frame types and what they do etc have a read here
http://www.faqs.org/faqs/compression-faq/part2/section-2.html

I chose the lowest scene (frame) and compared between each encoder.
yes i understand that but a single frame does not say what it looks like when playing. i have analysed a stream produced with the new RC and yes it does some large variance in frames but on playback i could hardly tell any difference comparing it to the old RC. i will try some different scenes again later and see if i can.
my question though was could you see any difference PLAYING and not just a still frame ?

[Trahald]

frames are stored out of temporal sequence.. they are stored in the sequence needed to decode them. usually i(1)p(4)b(2)b(3)p(6)b(5) etc.. (the numbers represent temporal playback) the i is the jpg..its needed first. the first b is next but cant be decoded with out the p so the p is stored next. then the b's. gops are stored with the i frame first (open or closed) the difference is on a open gop the temporal first frame is the b.. it needs the info from the last p from the gop before and the first I in the new gop i(2)b(1)p(5)b(3)b(4)p(8) etc..

[freelock7]

could you see any difference PLAYING and not just a still frame ?
Yes, of course (macroblocs). Compare withHC013. it's a good test.[

[dragongodz]

Yes, of course (macroblocs)
so the new RC showed more macroblocks than the old RC. ok will look at that as i said with some more very slow scenes later.

Compare withHC013. it's a good test.
i already know the types of GOPs HC is outputting and indeed the new RC is not as even a distribution yet, hence the need for tweaking etc. i dont need to look at another encoder to tell me that. :)
look in the thanks.txt that comes with HC 0.13 , dgz is me. ;)

[Nic]

Sounds like the RC is over-compensating a little on the low motion scenes. I'll look into that. Soon as I get the data off the HD i'll post you source code too dgz. It's pretty easy to get to grips with. (compared to the mess that's libavcodec RC)

Thanks for all the feedback guys. My motherboard is being RMA'd, but my old computer should be able to cope for now.

-Nic

[dragongodz]

ok did some tests with some low motion/near static scenes. yep new RC showed blocks worse than beta4, note beta4 had the blocks aswell just lighter. when there was some motion aswell, such as a person moving their hand however the reverse was true. that is beta4 showed more blocks and the new RC had less. which all confirms what freelock7 said basically. note though that i did have to look for these as they lasted a fraction of a second so would be hardly noticable if just normally watching. thanks for the concise reporting freelock7, made it easier to find. :)

koepi - if you are reading, where can Nic and i get the source for foxers strict scaling since searching for "foxer strict scaling" and "xvid strict scaling" doent really help. ;)

i'll post you source code too dgz. It's pretty easy to get to grips with. (compared to the mess that's libavcodec RC)
cool. :D

[Koepi]

Tomorrow i have a day off and then can send/upload the strict scaling code.

Cheers
Koepi

[dragongodz]

cool. :D

[freelock7]

-Dragongodz
Glad to know you validate my findings.:)

[EpheMeroN]

I'm gonna be encoding an XviD AVI using the latest QuEnc beta and wanted to know if I should do the levels correction (going from 0-255 to 16-235 for dvd output) in the AviSynth script, or if it's handled automatically in QuEnc?

[mikeytown2]

Awesome work on QuEnc, i have a couple of requests...

I have a dual AMD 2000+ computer (its a 4U server box i got for free :)) and when i use 0.59 Beta 4 it crashes when ever it starts the second pass, doing 2 vids at once. I'm encoding one video on each CPU (ctrl-alt-del, set process to CPU). I have not tried 1 pass and it looks like with this current ver it doesn't really matter, lol, seeing how 2 pass doesn't do too much according to the posts.

So I'll wait for 0.60 when the RC is working right and then I'll nag u guys some more, unless u would know why it would crash on the second pass. I have the .exe in 2 different dirs and the .avs files are in the same dir.

In case you guys are wondering what I'm encoding, I'm making a x-men cartoon dvd set. the 92-97 one. I'm using DVDStyler to author it.

My other questing I think is answered, I need to set the max bitrate lower. the vids where crashing on my dvd player, and would act odd on VLC.

thanks
-Mike

[dragongodz]

I have a dual AMD 2000+ computer
then i would wait until i have looked at adding some sort of threading and just do 1 encode at a time for now if you are constantly getting a crash running 2 QuEncs at once.

seeing how 2 pass doesn't do too much according to the posts.
well thats not quite true. all of libavcodecs rate control is not good. we have had to put certain contraints on it to behave a bit better but it still wont be perfect.

unless u would know why it would crash on the second pass.
bit hard to replicate and track without having a dual cpu system aswell. ;)

[communist]

I got the same thing yesterday when I tried to encode 4 svcds over night when running 4 QuEncs:
- running 2 (or more) QuEncs with both (or all) doing 2pass encoding -> every instance CRASHES when starting 2nd pass
- running 2 QuEncs with one doing 1pass and the other 2pass -> no CRASH

I'm running on:
XP SP2 / 1x AMD Athlon 2600+ / 768 RAM / no overclocking / properly cooled ;)

Other than that - keep up the great work on QuEnc :)

[Nic]

@communist & mikeytown2: This is because QuEnc has a fixed filename that it writes the 2pass log file to (inside your TEMP directory). I didn't ever consider people running two QuEncs at once. I'll make the next version randomly generate the 2pass file name, that'll fix it. Thanks for the feedback :)

On another note, should get my motherboard back today, I'm away all weekend, but come tuesday should be developing QuEnc again.

-Nic

[lark]

perhaps you could use the process id as a postfix for the log file...

regards
t :)

[communist]

Ah glad that its easy to fix. One suggestion: wouldn it be better to place the log file in the same directory as 'my_source.avs' and have it named 'my_source_pass.log'? That way one could easily recognize the log files and rerun 2nd pass when needed (for ex. bitrate change) easier :)
That would of course need a "run 1st pass" or "2nd pass"-only mode.

The other thing I noticed similar to the pass log file problem is that you can run 2 QuEncs (or more) and have them encode the same source.avs to the same source.mpg at the same time. Shouldn there be some protection saying "Hey that file is already in use!".

[Nic]

@Communist:
"Shouldn there be some protection saying "Hey that file is already in use!"."
In the latest unreleased version there is.... :)

"it be better to place the log file in the same directory as 'my_source.avs'"
Maybe, But I always think it starts to make the directory a bit messy. I'll think about it.

@Lark: Not a bad idea at all :) I may well just do that.

-Nic

[mikeytown2]

Originally posted by communist
Ah glad that its easy to fix. One suggestion: wouldn it be better to place the log file in the same directory as 'my_source.avs' and have it named 'my_source_pass.log'? That way one could easily recognize the log files and rerun 2nd pass when needed (for ex. bitrate change) easier :)
That would of course need a "run 1st pass" or "2nd pass"-only mode.

Excellent idea, this would be very helpfull...
Originally posted by communist
The other thing I noticed similar to the pass log file problem is that you can run 2 QuEncs (or more) and have them encode the same source.avs to the same source.mpg at the same time. Shouldn there be some protection saying "Hey that file is already in use!".
This idea I'm not so sure. I like to encode the same file at the same time at different bitrates to try and find the right bitrate. I've only ever done this once so far for my video project (the opening thats the same on all the xmen's). so it doesn't matter too much seeing how i can just copy & rename the avs file. But i'll guess that the way communist is proposing is a lot easier to do ('my_source_pass.log').

[communist]

What I meant is you can have several encoders running encoding to the exact same mpeg file on the hard disk - which should not be possible Imho.

But as I read Nic has fixed that aswell :D

[hoenes]

NIC:
@communist & mikeytown2: This is because QuEnc has a fixed filename that it writes the 2pass log file to (inside your TEMP directory). I didn't ever consider people running two QuEncs at once.

Last week I did seven 2-pass encodes with QuEnc .59 b4 at the same time with out any problem! So how is this possible?

[compwiz312]

I'm not sure if you would consider this a bug or not, but shouldn't all the buttons and checkboxes be disabled when something is actively encoding as they don't change anything during the encode.

[Nic]

For the testers that are interested hopefully freelock) a new private version is out.(The new private build's at the same address as last time.)

If you want the source code, add "_src.zip" to the normal filename. also http://nic.dnsalias.com/ffmpeg.zip for the ffmpeg used source code.

-Nic

ps
My new motherboard is working fine :D

[guada 2]

Hello Nic,

I appreciate the last version of Queenc a lot.
For 2 reasons:

- its stability
- And the aspect of material which produces your software during the encoding.
I haven't seen it on Freeenc and HC yet.

[freelock7]

-Nic
What I can say about the R4 test (VBR=3000/HQ/2Pass):

1-RC2 is more versatile in high bitrate and give better results than RC4
2-At low bitrate, I don't see a real advantage of R4 (macroblocs still there)
3-Beta4 gives the best picture in slow scenes (no macroblocs)

If the RC2 could work like the beta4 in slow scenes...

[dragongodz]

a new private version is out.
Nic - does this contain and use the strict scaling ?

My new motherboard is working fine
cool. :)

well sorry i havent been about, very busy week. hopefully next week will return to a more normal state. so then i will get to look at this properly. :D

[Mug Funky]

little feature request:

would it be possible to apply timecode to the output? this would be handy for segment re-encodes, as doing it timecode based is much much easier than plonking it in the middle of a stream (DVDMaestro is quite user unfriendly in this regard, though it's good that it has that capability at all).

i don't mind quenc's bitrate spikes if i have the ability to re-encode just those bits :)

this would possibly kludge up the GUI a little, but it could always be put in the advanced section.

btw, i haven't done a full test of the new RC... sorry

[edit] also, there was a little talk before about closed gop, multiangle, etc.

closed-GOP isn't necessary for DVD at all AFAIK, but it is necessary in some streaming systems (satellite etc). the only real practical difference is GOP "blinking" at low bitrates where the final b-frame is too different from the next I-frame in closed-GOP and makes a visible "blink" of the backgroud.

multiangle requires the exact same GOP structure for both streams (easiest to just turn autogop and scenechange off), and a strict max bitrate (per video stream, not combined) of 8.0 mbps minus ALL your audio/subtitles. this is why a lot of multiangle discs look quite bad, especially where they were stupid enough to put DTS audio on the disc... this could also be the cause of the frame-loss issues on DBZ discs, as funimation do most of their stuff with multiangled openings and closings.

min bitrates are a good idea, especially on episodic stuff with fade-outs and a few seconds of black between parts (padding is needed here).

[freelock7]

-Nic
The bad quality of RC4 (maybe) comes from these findings:

1-The RC4 min_bitrate seems to be set=2000kbs!
So, the bitrate distribution doesn't correct enough the high bitrate compensation (contrary to RC2).
2-The quantiser is working like in constant mode=5 during the slow motion.
Very strange because these moments suffer from the high compression.

Hope this words can help you.

[video_magic]

Thankyou very much for the information and also for the links all of you, in answer to my query. This stuff's super hard to get in to!, I find myself whimpering like a frightened puppy at times but I feel better for learning. I have also read around the mailing lists and forums of some projects that are related to Quenc or what Quenc does.

I have been using the excellent cutteraman for editing mpeg2, and I had a problem with muxing to do with underflows. I noticed that it was using mplex, and so I replaced that version of mplex with Peter Cheats' Modified Mplex 2.0, and those problems were solved. I have contacted the Cutteraman guy about this to see if he thinks it could be worth changing to this improved mplex. So what does Quenc use to do with muxing, is it the common Mplex, or something different and new, or a modified Mplex? I have read on MPucoders' website of Muxman having a superior multiplexing solution to Mplex, I don't know if this means feature-wise or whether it means more compliant to DVD specs in some ways. I do always have future-proof worries to do with when I archive various materials onto DVD and so I just wondered what QUenc used, and so also what this means for it's DVD-Standards-Compliancy?

Another thing I wondered about is DC Precision. I read that a DC value of 11 would not be compliant for DVD, values of 8, 9 or 10 are, but in Quenc 0.59b4 11 is a choice, I guess that is from Libavcodec. I don't know much about intra and inter DC precision and so on, so please excuse me I just noticed and thought I should mention it.

As always, I thank you and look forward to the next Quenc release with excitement :cool:

[Nic]

@Freelock: Thanks for your testing, sounds like my little tweak didn't work. Had a feeling it might not, but was worth the try. I think I'll release 0.60 with RC2's rate control. It's not perfect, but it's a step in the right direction. (Unless I can think of anything between now and then)

@dgz: No it doesn't use the strict scaling, Koepi PM'd me, but I haven't had time to look at it and implement it.

@video_magic: QuEnc uses libavcodec's muxing. Should be quite good. A few guys on the ffmpeg mailing list did a lot of work to ensure it was compatible. Muxman probably is the most compatible, just because I know mpucoder would have it no other way :)

DC precision can pretty much always be left at 8. 11 is selectable, because it's supported, but as you say it's not DVD compatible and holds little use when encoding a 4:2:0 low bitrate encode anyway. (I may as well remove it)

@MugFunky: What do you mean timecode? Are the GOPs not having correct timecode written to them? I'm still undecided on min bitrates...

Thanks for all the feedback guys :)

-Nic

[dragongodz]

I think I'll release 0.60 with RC2's rate control. It's not perfect, but it's a step in the right direction. (Unless I can think of anything between now and then)
*COUGH* *COUGH* strict scaling *COUGH* *COUGH* ;)

11 is selectable, because it's supported, but as you say it's not DVD compatible and holds little use when encoding a 4:2:0 low bitrate encode anyway. (I may as well remove it)
11 is used for HIGH PROFILE meaning things like 15Mb/s and up encoding. so no not any good for dvd etc. hmm i seem to remember suggesting dropping 11 quite some time ago because a person or 2 tried to use it for dvd not knowing it wasnt compatible and got terrible playback. :D

I'm still undecided on min bitrates...
its been reported many times that some dvd players, specifically high end like sony and panasonics, dont like the min bitrate to fall below about 300Kb/s and have playback problems if it does. hardwiring a low min bitrate such as that would be a good idea IMHO and save a headaches later.

EDIT:
closed-GOP isn't necessary for DVD at all AFAIK
it is actually. specifically it is required for multi-angles etc. but not for a 1 angle compilation.

[communist]

Leave DC-Precision up to 11 in. Like with any other tool - its better to have options than not :)
Maybe you can grey it out if for muxing profile you have DVD selected. Or the easiest (?) solution would be to show a message : "Will not play on DVD-Players!".

[dragongodz]

couple of quick tests done.

RC2 seemed to like fades better.
RC4 handled some static areas slightly better.
RC4 GOP pattern looked a little better, not so much in-GOP variance, but i would need to test this more for anything conclusive.

[jpl]

dragongodz

its been reported many times that some dvd players, specifically high end like sony and panasonics, dont like the min bitrate to fall below about 300Kb/s and have playback problems if it does. hardwiring a low min bitrate such as that would be a good idea IMHO and save a headaches later.

A min bitrate of 300kb/s would waste bits for everyone else when not necessary. Especially for VCD or SVCD encodes when you don't have that much bitrate to start with.

[dragongodz]

A min bitrate of 300kb/s would waste bits for everyone else when not necessary. Especially for VCD or SVCD encodes when you don't have that much bitrate to start with.
well VCD is CBR anyway so the min rate = target rate = max rate, so irrelivant. :)
as for SVCD well it could just as easily be only set for if dvd muxing is turned on or dvd resolution etc etc etc. theres plenty of way to do it that wouldnt effect SVCD.

[Mug Funky]

300 kbps wouldn't waste much at all.

how often does the stream dip below this? i've only ever observed it getting anywhere near this low on sections of pure digital black (even analog black will go above 300 for a DVD encoding).

also, it's worth it for the compatibility. an option to turn it off would be good of course, but that means cluttering up the GUI which i know nic doesn't want to do (though soon it may become inevitable).

[Nic]

@MugFunky: I'm am leaning towards adding a minimum bitrate, i've already got a max bitrate so having a minimum can't harm too much (hopefully).

-Nic

[onesoul]

I think being able to set a minimum bitrate is a good option.

About improving fade-in/fade-out, transition scenes specially from low to high bitrate, low bitrate sequences (like with flat background): imo the best way to improve these would be adding a parameter to define the VBR curve compression (similar to Bias setting at CCE which varies between 0-100 being 0 full vbr and 100 full cbr). From my experience with cce it's the only way to "stabilize" quality throughout a clip delivering a much better result.
I have made a test where cce (bias=0) would perform very similar as hc and quenc which all had the flaws in the same sequences described above, but when using cce with bias=40, a much better output was obtained in those same scenes with no harm to rest of the encode.

You can read here about a comparison (http://forum.doom9.org/showthread.php?s=&postid=648816#post648816) I made about cce with bias=40 and bias=25 with notorious differences.

How hard would it be to implement such a parameter?

[Mug Funky]

@MugFunky: What do you mean timecode? Are the GOPs not having correct timecode written to them? I'm still undecided on min bitrates...


sorry, missed that part of your post. before..

i mean the option to add a timecode offset, rather than starting at 00:00:00:00.

for example, there's a problem starting at 00:32:45:12, and i want to re-encode just that bit. right now QuEnc will re-encode the chunk just fine, but the timecode in the file will start at zero, where it would be handy for it to start at 00:32:45:12, so it can be placed over the top of the main encode there.

QuEnc's ratecontrol doesn't fail often (maybe once per 20 minutes of stuff?), but when it does the simplest fix is to just re-encode where the bitrate spiked out - it's a 10 second encode versus a 2 hour one...

HC has this feature, though i haven't actually tried it yet (i don't get home enough these days to do much avisynthing nowadays... but embedded tape timecode is something i use at work a lot, but miss on my own projects).

[dragongodz]

imo the best way to improve these would be adding a parameter to define the VBR curve compression (similar to Bias setting at CCE which varies between 0-100 being 0 full vbr and 100 full cbr)
personally not a fan of this. to be more specific i am not a fan of the huge amount of values you can set, seems overkill..like the ability to do 99 passes in the latest version of CCE.
maybe something more along the lines of loose scaling and strict scaling selectable, similar to one of the version of Xvid that Koepi released had would give a similar effect.

[onesoul]

Originally posted by dragongodz
personally not a fan of this. to be more specific i am not a fan of the huge amount of values you can set, seems overkill..like the ability to do 99 passes in the latest version of CCE.
maybe something more along the lines of loose scaling and strict scaling selectable, similar to one of the version of Xvid that Koepi released had would give a similar effect. I understand what you mean, but anyway the point I was trying to make is that the vbr compression curve shouldn't be max (or bias=0 at cce) which I believe currently quenc and hc are doing, or close anyway.

Regarding which scale to use, I think these will be very subjective, as you can see in the other thread, bias=40 isn't considered good default by some, well I think it is...
What would you consider strict setting (using bias again) bias=0? and loose scaling bias=40? Regarding this setting I wouldn't mind being able to set it at 0-100 scale.

[dragongodz]

What would you consider strict setting (using bias again) bias=0? and loose scaling bias=40?
more the other way around. its not a strict analogy but a similar concept.

Regarding this setting I wouldn't mind being able to set it at 0-100 scale.
thats what i consider overkill. why would it need 100 settings ? you can not tell me people are going to go through them 1 at a time and try to pick which appears better for a particular source. looking at this discussed in other threads people seem to stick to a few small ranges or values so just having the choice of a couple should be more than sufficient.

[onesoul]

Originally posted by dragongodz
more the other way around. its not a strict analogy but a similar concept. Could you be more explicit?
thats what i consider overkill. why would it need 100 settings ? you can not tell me people are going to go through them 1 at a time and try to pick which appears better for a particular source. looking at this discussed in other threads people seem to stick to a few small ranges or values so just having the choice of a couple should be more than sufficient. For testing purpose maybe someone would choose 0 or 100 or even going through 1 at a time, but for choosing "the right" setting you'd try in range of 5-10, starting from a default like 30 (which is cce's default).
There are people choosing bias=0 in their encodes also..., of course I don't recommend extreme settings but why not be able to choose them? We are all grown ups (mostly I think) :)

[dragongodz]

Could you be more explicit?
loose scaling is like bias= 0. strict scaling is like bias=30 or 40 or whatever, cant tell you exactly because its probably not exactly the same as a particular setting, in that it doesnt allow as wild swings. so its similar.

For testing purpose maybe someone would choose 0 or 100 or even going through 1 at a time,
i think it was Fishman0919 that ONCE tested 99 passes with CCE 2.70 just to see if there was any difference at all compared to 2 or 3 passes. he knew what the result would be and was right, bugger all difference. so whats the point in having that many settings ? overkill and pointless.
same applies for the bias in my opinion. having that avalaible for testing doesnt make it good for real use.

for choosing "the right" setting you'd try in range of 5-10, starting from a default like 30 (which is cce's default).
so you would start at 30 and then increase or decrease by 5 or 10 ? but that then proves my point that 100 settings is overkill. Cinemacraft would have been better off doing something like making it 0 to 5 with each value equivilent to 10 of the current values, so 0=0 and 1=10 and 2=20 etc. which would have made it more straight forward for people. does anyone actually use over 50 ? not that i have ever read and high up values such as the 90's and 100 where it becomes CBR is again pointless. if people wanted CBR then they would choose the CBR setting, thats what its for.

of course I don't recommend extreme settings but why not be able to choose them? We are all grown ups (mostly I think)
you would be surprised if you read some of the things i have. :D
but seriously, that goes against the concept of QuEnc being relativly easy to use and harder to go wrong with. thats why a lot of setting which we could easily add have not been, too easy for people to stuff up with.
as i said i am not against having a couple of settings, maybe just 2 - loose scaling and strict scaling - to test, i am just against an overkill of them.

[onesoul]

loose scaling is like bias= 0. strict scaling is like bias=30 or 40 or whatever, cant tell you exactly because its probably not exactly the same as a particular setting, in that it doesnt allow as wild swings. so its similar. OK, I understand you now :)
But personally I consider a bias=0 an extreme setting and not recommendable at all. Maybe loose setting should lay in 20-25 and strict setting in 40-45, at least in what I tested so far.
i think it was Fishman0919 that ONCE tested 99 passes with CCE 2.70 just to see if there was any difference at all compared to 2 or 3 passes. he knew what the result would be and was right, bugger all difference. so whats the point in having that many settings ? overkill and pointless. It wasn't me that started talking about 99 passes remember? :sly: ;)
The way hc and quenc work is fine, I rarely use more than 2 passes in cce also, maybe 3 sometimes but anything beyond that is pointless imo.
Anyway I wouldn't compare, in terms of overkill, having a bias in 0-100 scale to having the 0-99 passes setting.
so you would start at 30 and then increase or decrease by 5 or 10 ? but that then proves my point that 100 settings is overkill. Cinemacraft would have been better off doing something like making it 0 to 5 with each value equivilent to 10 of the current values, so 0=0 and 1=10 and 2=20 etc. which would have made it more straight forward for people. does anyone actually use over 50 ? not that i have ever read and high up values such as the 90's and 100 where it becomes CBR is again pointless. if people wanted CBR then they would choose the CBR setting, thats what its for. Ok :) I agree that a scale 0-100 is too much. you would be surprised if you read some of the things i have.
but seriously, that goes against the concept of QuEnc being relativly easy to use and harder to go wrong with. thats why a lot of setting which we could easily add have not been, too easy for people to stuff up with.
as i said i am not against having a couple of settings, maybe just 2 - loose scaling and strict scaling - to test, i am just against an overkill of them. Let's try find 2 good default settings then :)

[dragongodz]

But personally I consider a bias=0 an extreme setting and not recommendable at all. Maybe loose setting should lay in 20-25 and strict setting in 40-45, at least in what I tested so far.
CCE uses its own rate control however so is not the same. thats why i said i cant give a figure thats an equel to a particular bias, it simply doesnt work that way.

Anyway I wouldn't compare, in terms of overkill, having a bias in 0-100 scale to having the 0-99 passes setting.
but i was ,especially in regard to them even being useful for testing purposes. they are not IMHO even worth it for that was what i was trying to illustrate. :)

Ok :) I agree that a scale 0-100 is too much.
good. ;)

Let's try find 2 good default settings then
well first step would be convincing Nic to try and see if he can hack strict scaling in as an option. Koepi may even be able to help there since he added it as an option in a previous Xvid. then we could do some tests, get some feedback, etc etc etc and make adjustments to try and improve them if needed.

thoughts Nic ? :D

[ginoboy]

one question: all the possible configurations of the QuEnc are not visible in the graphical interface of the advance configurations, right?

exists a TXT or something where I can see all the configurations to be done in the command line?

thanks in advance!

[]'s

[Mug Funky]

@ ginoboy: probably better to just use ffmpeg or mencoder if you're doing that kind of stuff.

nic's design philosophy is to expose only the options that are meaningful, because otherwise people will choose outlandish options, make a crap encode, and blame the encoder for it... the LAME mp3 encoder suffered from this for years.

however, i like to tinker as well, and there is a place for it. ffmpeg and mencoder have the exact same encoder core in them as QuEnc, and they allow everything imaginable to be played with.

[edit]

quenc's CLI only has options accessible from the GUI. a list can be accessed with quenc.exe -h IIRC. it's very good for batch operation :)

[Nic]

@all: sorry for the delay. For some reason Michael at ffmpeg changed the way frame rate was handled in the ffmpeg and now nothing works when it comes to muxing from QuEnc. Grrr.....

[dragongodz]

For some reason Michael at ffmpeg changed the way frame rate was handled in the ffmpeg and now nothing works when it comes to muxing from QuEnc. Grrr.....
ye that sucks. its like when they changed doing the aspect ratio and my pre 0.54 builds were wrong. scratch head and go "it bloody worked with the earlier cvs checkout".

[Nic]

It does annoy me...How they won't add some very useful patches that work fine, but will break the CVS without a second thought. Even output_example doesn't run...
...(You now have to specify the colorspace before initialisation)

-Nic

ps
Ok think I've got it sorted.
Instead of a:
pkt.pts= c->coded_frame->pts;
I need to do a:
pkt.pts= av_rescale_q(c->coded_frame->pts, c->time_base, video_st->time_base);
(so not quite a CVS break, but I've been copying the output_example and the changes breaks that)

@dgz: I have a funny feeling I uploaded the wrong ffmpeg directory last time, no wonder it didn't work for you. D'oh!

[ginoboy]

@ Mug Funky

hum...I understood, it was what I imagined...

quenc.exe -h is nice! of this I not wise person, perfect!

Thank you ! ;)

[vlada]

Hi,
I have a suggestion for future QuEnc version.
1) If I want to make a DVD in a few steps, I usually author it in Muxman. So I use QuEnc to create .m2v video and then use QuEnc or BeSweet to create an AC3 sound. I need to have the 2 elementary streams, because Muxman doesen't support MPEG container. I hoped that the selescion :Separate passes" will do AC3 and M2V, but unfortunatelly it creates MPEG and AC3. I think it is useless to create a video-only MPEG.
Also if I switch in the "Advanced options" to "no audio" or "no video", I believe QuEnc should automatically change the extension for the output file to M2V or AC3.

2) I like the idea, that QuEnc can open AVI files and automatically create an AVS file. But I would also add 2 options to the main screen - "PAL DVD" and "NTSC DVD" profiles, which would add following lines

LanczosResize (720,576)
ResampleAudio (48000)

if needed. This should wok for most AVI files. FPS correction need to be coordinated with sound, so it can't be implemented easy.

What do you think about this suggestions?

Vlada

P.S. Sorry for my weak english, but I hope you understand what I wanted to say.

[dragongodz]

@dgz: I have a funny feeling I uploaded the wrong ffmpeg directory last time, no wonder it didn't work for you. D'oh!
and i was going to paste it over the cvs tommorow aswell, think i will wait now. let me know where/when to get the right one. :)

[Nic]

@vlada: When you do separate passes the .mpg file, is actually a .m2v file. It isn't a MPEG PS stream with only a m2v video stream in it.
I don't assume extensions, because that can cause problems. But I can understand the confusion. So muxman should cope with the two files fine. Let me know if it doesn't.

I don't want to add anything to AVS Files created, that's the job of another app. I've written another (unreleased) app called AVSCreator which has DGIndex indexing built in and used DGDecode & NicAudio to create an AVS file for anything dropped on to it. It's handy. Maybe I should release that.

@dgz:
Uploaded new private build again along with the source, same addresses as last time.
Might try fiddling around with curve compression, to see if there are some numbers that might help the problem freelock is seeing. Want to release soon.

-Nic

[vlada]

@Nic: Thank you for the reply. Before I posted it here, I tried to rename the created file to .m2v and load it in Muxman, but Muxman rejected it. So I thought it is because the video is muxed in MPEG. But the reason was, that the file didn't have a standard DVD resolution. I tried to resize it to 720x576 and now it works fine.

[dragongodz]

Might try fiddling around with curve compression, to see if there are some numbers that might help the problem freelock is seeing.
cool.

Want to release soon.
understood. it doesnt matter if not everything makes it in to this release of course.

[starship]

I´ve been encoding lately cartoon into mpeg1 with quenc beta4 and results are very bad. Bitrate is 1150 constant, and with trellis, high and close gop activated. Watching video carefully it seems to me that "I" frame is good but following frames "B and P" get very bad looking.

I´ve been using beta2 with success for this work, so I wanted to warn you about it because it seems to me that it has not been said in this thread.

[Mug Funky]

couple questions:

what kind of source? cartoon, yes, but old? new? noisy? clean? sharp? blurry?

have you tried it without trellis?

i must confess i've never tried mpeg-1 encoding with QuEnc (haven't done any mpeg-1 at all for a good long time...)

[starship]

Source is clean and sharp.

Other encoders do the job well so is a quenc beta4 issue. I like very much old quenc mpeg1 encoding, because was fast and good. It is a pity if we loose this funcionalty, will backup previous versions anyway :)

[Nic]

@Dragongodz: Can you remember what I changed between those versions settings wise? So we can help starship. You know what my memory is like..... ;)

[dragongodz]

Can you remember what I changed between those versions settings wise?
the main change is
lmin = 1 * FF_QP2LAMBDA;
became
lmin = 1;
because of the problem reaching higher rates.
actually i later thought about it and wondered if
lmin = 0.6 * FF_QP2LAMBDA;
would have helped with the higher rates aswell, probably. didnt really worry about it though since you are implamenting the Xvid RC.

also you stopped using different factors for 1 pass and 2 pass encoding but that didnt work that well for 2 pass ,from memory, so you went back to my dual settings. though i did also reccomend they could be tweaked up a bit aswell such as I factor bump up 0.1. would have reduced I frame size a small amount and spread a little more to P frames, atleast in theory. :)

You know what my memory is like..... ;)
hey its not easy for me to remember all these small things either. dont forget i am even older than you. :D

starship - was that doing 1 pass or 2 pass. yes you can do CBR 2 pass and it does spread the bitrate closer to CBR.
also make sure you are only using DC of 8 for mpeg1 and you may want to try dropping using trellis to test aswell.

[starship]

Dragongodz- I was doing 1 pass only

This way I have always encoded well cartoon with mpeg1 Quenc, at least for my own taste, but now with last version movements get very bad picture, and video results low quality. With static video like Japan or Chinese cartoons may be OK but not with american high quality animation.

[dragongodz]

I was doing 1 pass only
ok then the factor change should not be a problem, that hasnt changed for 1 pass.

please try doing a 2 pass encode aswell and see if that makes any difference for you. also as i said try it with trellis turned off and make sure DC is 8.

With static video like Japan or Chinese cartoons may be OK but not with american high quality animation.
*thinks* i will not reply to this, i will not burst his bubble, mouth firmly shut mode on. ;)

[starship]

2 pass does the job. Now quality picture is better than ever.

Thanks dragongodz

[Nic]

Ok, new private build up for the people that have the link, this should the last private build before release. Anyone that wants to test the private build before I release it can PM me.

(Fixes "green blocks" bug, slight RC change)

-Nic

[video_magic]

:D Isn't this the greatest time? I'm raising a beer for the next release, I have a batch of James Randi lecture videos which I will convert and encode and look forward to putting 'em through a new Quenc :)
So who are you guys collaberating from different projects, this is going to use Rate Control from XViD? I wonder if you know about a 'Rock Family Tree' - this is where you can see a Chart that shows how people are connected through the bands they were in. Perhaps it would be nice to see this for Quenc and related video projects :) Either way thanks a lot for all your work guys (& testers). I think it's great to have this open discussions thread so people like me have a glimpse into what goes on.

[Mug Funky]

that rock family tree is a good idea...

i suspect if you do one for any opensource project, you'd end up with a gigantic family tree that includes all opensource projects (plus a few closed-ones). it'd be fun to see this though. like a big interactive credits page.

btw, the new ratecontrol seems to be rock solid. needs more testing though.

[freelock7]

Wow, it's amazing!
Very good job here Nic with this final update.
As Mug funky, I confirm the great performance of this new RC.:)

[dragongodz]

ok just downloading now though i probably wont be able to try it until tommorow. my wifes bother and his girlfreind just had another baby late last night. so we are off to see them today etc. :)

the new ratecontrol seems to be rock solid. needs more testing though.
I confirm the great performance of this new RC.
Nic - sounding good so you dont have to wait to hear from me anyway. :)

slight RC change
care to elucidate a little ?

[Nic]

"care to elucidate a little?"
;) I didn't do much, just changed the curve compression slightly for low motion scenes. Probably could do with a lot more tweaking, but it definitely appeared to help on my test clips. I'm sure we'll both have fun tweaking the code....(And eventually adding XviD's strict code)

"sounding good so you dont have to wait to hear from me anyway"
No, massive rush, probably will release on Sunday (at work now, out tonight, with gf saturday so sunday is the next day i'm free)

"my wifes bother"
Freudian slip? ;)

-Nic

ps
Revenge of the sith is really quite good....

[dragongodz]

well did a couple of quick tests. results looked ok to me.

I'm sure we'll both have fun tweaking the code....(And eventually adding XviD's strict code)
no doubt. just a matter of finding enough time to properly devote to it and still do other things, you know what i am talking about. :)

Freudian slip?
no a wifes job description. :d
wait, i am sure you will find out one day. ;)