View Full Version : QuEnc 0.59 Beta 3
QuEnc 0.59 Beta 3
http://nic.dnsalias.com
And here I go again, trying to get another stable Beta before making a proper 0.60 release.
Changes:
Better stability (In theory)
Always encodes the selected AR for MPEG-2
Can now automatically do two passes to create both a separate audio and video file
Now creates Muxed MPEG files with compliant PTS/DTS/SCR Values
Has updated DragonGodz QLB 1.2 Matrix
Has new mini DVD Authoring Mode
Fixed irritating bug when doing a 2pass low frame count and low bitrate encode (again!)
General fixes for things like audio encoding, etc
Let me know how you get on with this version. Rate control has seemed OK in my tests. Which I don't quite understand :confused: So let me know if it still does stupid things in that respect.
Cheers,
-Nic
Koepi
7th April 2005, 11:41
Very nice Nic, thanks for the new version!
Can't test it yet but will sure do so when I'm back home - let's see if I find something interesting to encode :)
Keep up the good work,
Cheers
Koepi
guada 2
7th April 2005, 21:59
Hello NIC,
It is a good news but I think that you intend to go beyond. ;)
See you again.
nDman
7th April 2005, 23:51
thanks, nice update ;)
Chainmax
8th April 2005, 02:10
Would it be possible for Doom9 to make an MPEG2 comparison between QuEnc, HC-12 and CCE SP/Basic?
TheCreamCrackerBoy
8th April 2005, 02:19
If we're talking about a codec shoot-out, i suggest trying Canopus Procoder 2. The MPEG-2 encoding results, IMHO, are better than CCE-SP (less blocking).
[]'s
The Cream Cracker Boy.
video_magic
8th April 2005, 02:26
Interesting cryptic comment about the rate-control, would you explain it please Nic? :)
I guess it could mean that you had worked on putting some rate-control code in - which is the main thing I at least wanted :)
Is it from Peter Cheat & your comments meant that the code works but you don't quite know how it is working?
Thanks as always Nic.
dragongodz
8th April 2005, 05:05
I guess it could mean that you had worked on putting some rate-control code in
well i know he changed the rate control settings a bit based on other changes i had made in earlier versions. so that part is simply settings change and not "in code". other than that Nic will have to answer.
your comments meant that the code works but you don't quite know how it is working?
there have been people that have encoded with DVD-Rebuilder, for example, using QuEnc that have got largeish undersizing. Nic has not experienced this with his tests so doesnt know why they do. so maybe these changes could help them....or not. :)
shirohamada
8th April 2005, 08:19
i've encountered large undersizing many times.
i mainly encodes anime, once a tv series, ad that turn outperfectly sized.
mostly are 480x480 svcd, and 704x480 letterboxed material.
my temporary solution is using 6of9 matrix. well, quality, its better than the undersized ones, less ringing and mosquito noise for 2 episode 24 minutes each.
when you go for a 3 episode,it starts to block on fast scenes, well pretty much expected.
so its easily compressed.
question,
is it possible capped the bitrate for constant quant encoding, like forcing it to a lower quant when its over the limit ?
reason, svcd playback on my machine will only works perfectly below 6400kbps.
though getting a dvd burner is the better option.
@video_magic: Normally, when I do tests with QuEnc, it's pretty obvious to see that sometimes the bitrate spikes horribly about the max bitrate, or grows in a strange way, etc. I didn't spot any of that in my tests, even though I haven't really changed anything :confused: So, I'm not sure if it still has those problems or not.
So if you get horrible bitrate spikes or real bad undersizes with this latest version let me know. (Or any other bugs).
Cheers,
-Nic
freelock7
8th April 2005, 23:24
So if you get horrible bitrate spikes or real bad undersizes with this latest version let me know. (Or any other bugs).
I noticed that a VBR2Pass encoding above 5000kbs with a max bitrate=8000 create a lot of bitrate spike not controled by QuEnc (10.500kbs). The quantizer doesn't fluctuate enough and stay at 2.
This bug is not present in first pass (correct high bitrate).
When you encode a VBR2Pass at 3000 or 4000, the quantizer works better and you don't see any more bitrate spike.
(tested on RE_2_Apocalypse, QuEnc059b3).
kitsaros2000
9th April 2005, 02:29
quenc beta 3 has serius problems with vcd - mpeg1 stuff ! Quenc produces m1v that will not play with vcd players . Beta 2 worked perfectly !
Thx ;)
Nocturno
9th April 2005, 11:20
i just finished a test with a PAL source:
source is an xvid upsize to dvd
Quenc.exe -i "D:\avi2dvdtemp\Movie0.avs" -o "D:\avi2dvdtemp\Movie0.m2v" -maxbitrate 8000 -b 3836 -2 -aspectratio 16:9 -gopsize 12 -mpeg2 -vbr -hq -scene -priority 3 -nointerlaced -cmatrix "C:\Program Files\avi2dvd\matrix\Standard.txt" -mpeg2mux noaudio -auto -close
2-pass, avg bitrate @ 3836 max @ 8000
bitrate viewer told me:
Peak: 8836
avg: 3746
some peaks above 8000 (8196)
one at 8710
Num. of picture read: 112213
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:
i don't have the dvdauthor log, cause i automated my process.
so still some peaks, althoug in this case to few(low) to trip up dvd authoring. as the audio is mp2 @ 192 it's not above dvd spec i guess.
will try with bitrate set higher to see if spikes go above 10000 like last time i tried an encode with avg around 6200.
@Nocturno & FreeLock: do you get the same bitrate spikes if you just do a simple 1 pass? I think it might be two pass that's causing the errors.
@kitsaros2000: Weird?! Can't think what's changed. I'll look into that (dgz: Got any ideas?) I've changed something when making a VCD MPEG (video and audio combined), but not a VCD m1v.
timeismoney
9th April 2005, 14:32
A friend of mine use this latest version to compress a clip (Source: DV), with Q5 and Max bitrate at 9800, but the target clip is highly oversized, the grab is attached here.
http://www.wxxf.net/upload/file/0230/20fb25a625a37361bd93ae796555e30d_01.jpg
This problem exist in almost all of the recent versions.
Fishman0919
9th April 2005, 17:13
Is any one else getting undersizing with .59 b3. I'm in the middle of doing an encoder test with CCE SP 2.70, Procoder 1.5, HC Encoder and QuEnc ##... I was using QuEnc .54 because it was hitting the target size perfectly but any ver of QuEnc .59### undersizes.
Ex. of one clip undersizing, first 2500 frames of Elektra @3500k
CCE Sp 2.70.02 - 44,430
Procoder 1.5 - 44,546
HC Encoder - 44,648
QuEnc .59b3 - 39,725
5 other clips are about the same undersizing
with DVD-RB .82 pro, whole movie of Elektra
CCE Sp 2.70.02 - 4.35
Procoder 1.5 - 4.34
HC Encoder - 4.29
QuEnc .59b3 - 3.98
freelock7
9th April 2005, 18:33
do you get the same bitrate spikes if you just do a simple 1 pass? I think it might be two pass that's causing the errors.
No. First pass is correct.
Especialy with this movie (the original RE_2 is encoded in CBR =6400 with a constant_quant=2), QuEnc is unable to process some complex scenes with the quantizer which stay too linear.
Is any one else getting undersizing with .59 b3.
The undersizing prediction is still there caused by the quant=2.
dragongodz
10th April 2005, 02:14
dgz: Got any ideas?
did some .m1v encode using 0.59beta and 0.59beta 3. hmm 0.59b plays fine and loads in mpeg stream eye fine. 0.59b3 wont play(picture window of MPC doesnt open, not using internal mpeg1 decoder) and mpeg stream eye crashes when trying to load.
compared them bitwise and using 1 pass there is a constant difference meaning at regular intervals. 2 pass shows massive change so no good for comparison.
loaded in to bitrateviewer does show something interesting. aspect ratio, 0.59b says "1:1" while 0.59b3 says "unkown 0" so i would say this is the likly cause.
with Q5 and Max bitrate at 9800, but the target clip is highly oversized, the grab is attached here.
Constant Quant encoding does not respect max bitrate as it would have to lower quants sometimes to do so. then it wouldnt be constant quant.
for those with undersizing, how does 0.59beta3 compare to 0.59beta2 ? since Nic made some changes to the rate control settings its important to know if the undersizing became worse or not.
kitsaros2000
10th April 2005, 02:20
Nic the m1v dont work even on pc (only the video). The same avs with quenc beta 2 works fine . I m pretty sure that something is going wrong...
Take a look here :
Quenc Beta 2
http://www.trustfm.net/helpfiles/quencbeta2.jpg
Quenc Beta 3
http://www.trustfm.net/helpfiles/quencbeta3.jpg
Hope that this helps ... :rolleyes:
Thx for your effort !
hank315
10th April 2005, 02:58
@Nic,
Did a quick scan of the bitstream for MPEG1, seems the aspect ratio is written as 0 (bit 57-60, sequence header), hope this helps you solving it...
dragongodz
10th April 2005, 03:15
Nic the m1v dont work even on pc (only the video). The same avs with quenc beta 2 works fine . I m pretty sure that something is going wrong...
MPEG1, seems the aspect ratio is written as 0 (bit 57-60, sequence header), hope this helps you solving it...
hmm it seems my posts must be in invisible mode. :sly:
freelock7
10th April 2005, 10:06
for those with undersizing, how does 0.59beta3 compare to 0.59beta2 ? since Nic made some changes to the rate control settings its important to know if the undersizing became worse or not.
I encoded a movie (90min) with a VBR=6200 :3200Mb(B3)-3500Mb(B2).
Frame out of bitrate limit from the same movie (max set=8000-VBR=6200):
| QLevel (frame) | Bitrate (frame) | Average (clip of 24sec)
_____________________________________________________________________
QuEnc059B3 | 4.68 | 9.054 | 5.222
QuEnc059B2 | 4.32 | 9.599 | 5.618
NuEnc0.1b | 7.88 | 7.129 | 3.838 (Min_quant=2-Max_quant=31)
NuEnc0.1b | 6.40 | 8.823 | 5.899 (Min_quant=1-Max_quant=31)
Conclusion:
1-Interesting: the B3 version is better than the B2 but with a worse undersizing prediction!
2-The best prediction comes from NuEnc0.1b with a min_quant=1 but...out of the limit too.
Only NuEnc0.1b with a min_quant=2 is able to encode the sequence correctly but the quantizer is in constant mode (=2) most of the time. That's why the prediction is wrong in this case-for QuEnc too!
It would be nice Nic -or Dragongodz- to add in the advanced options the quantisation level. It could correct the undersizing prediction.
kitsaros2000
10th April 2005, 17:42
dragongodz sorry i didnt see your post ! I hope that all these infomations will help nic
Thx !
Nic
10th April 2005, 20:23
Ok, my changes to the aspect ratio fixed it for MPEG-2, but broke it for MPEG-1. So VCD probably isn't working because of that. Sorry about that. Will release a new version tomorrow (hopefully).
Seeing that QuEnc 0.54 is seen as being good, I've downloaded the source from dgz's website (yup, I wasn't smart enough to keep old copies ;) ) and will try and set the encoding parameters the same.
I'll look into the min quant thing too.
-Nic
drcl
10th April 2005, 20:57
@Nic
Does that mean you will be using the old libavcodec?
dragongodz
11th April 2005, 07:51
It would be nice Nic -or Dragongodz- to add in the advanced options the quantisation level. It could correct the undersizing prediction.
it shouldnt be needed. its a better rate control thats needed IMHO. Nic and i are talking and trying some different things with the current RC though(even though we dont say it here) to try and get this better. :)
Does that mean you will be using the old libavcodec?
no he means the settings going to libavcodec.
video_magic
11th April 2005, 09:21
Originally posted by dragongodz
...Nic and i are talking and trying some different things with the current RC though(even though we dont say it here) to try and get this better. :)
:D Yay! You guys are my heroes :) Thanks Nic and dragongodz and everyone else that works on this.
Nocturno
11th April 2005, 12:30
do you get the same bitrate spikes if you just do a simple 1 pass? I think it might be two pass that's causing the errors
i can confirm that.
running with the same settings in 1-pass mode gave a max peak at 7999 , while max was set at 8000.
on the same source ofcourse.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.