QuEnc 0.59 Beta 4

[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.