QuEnc 0.60 Released!

[Zarxrax]

A further report on my bitrate issue:
I've been encoding my stuff with HC now, trying to get my DVD done, and I discovered that with HC at least, my bitrate is fine right after the file is encoded, but after I run DGPulldown on the file, the bitrate will shoot through the roof! Can anyone explain this?? The length of the file remains the same, and the filesize remains the same, but it suddenly reports a way higher bitrate! This could very well mean that QuEnc had no trouble at all keeping the bitrate under control, though I can't confirm that right now.
If anyone could comment on why pulldown is shooting my bitrate through the roof, I'd really appreaciate it. This issue has caused me to waste like a week of my life now trying to get a dvd done against a deadline! I've tried other methods of Adding pulldown besides just DGPulldown, so its not just that program at fault either.

[Mug Funky]

did bitrate increase by 29970/23976? :)

BitrateViewer doesn't take pulldown into account, so bitrates will look way higher than they ought to.

the file itself should not be any bigger.

[dragongodz]

but after I run DGPulldown on the file, the bitrate will shoot through the roof!
ahhh this could indeed be your problem. what you have to remember is that with the pulldown frames or fields are being uesd more than once. so if you add the reused frames/feilds size to the bitrate it can indeed exceed the max bitrate. now you may say these frames/feilds should already be there so should not actually increase anything. sorry but they can with dvd players so that has to be taken in to account. try dropping your max bitrate say another 1000 and giving it a try.

oh and also make sure sequence headers(from memory) are set to interlaced even if you encoded progressive. some players dont handle pulldown well if you dont do that.

BitrateViewer doesn't take pulldown into account, so bitrates will look way higher than they ought to.
real dvd players can do the same thing and choke stuffing the buffer with duplicated frames/feilds aswell so thats not necissarily a bad thing for bitrateviewer to show. ;)

[Guest]

real dvd players can do the same thing and choke stuffing the buffer with duplicated frames/feilds aswell so thats not necissarily a bad thing for bitrateviewer to show. ;) Pulldown does not create video data that is fed to the decoder. It is purely a display process.

[dragongodz]

Pulldown does not create video data that is fed to the decoder. It is purely a display process.
yes that didnt come out/sound exactly as i meant it. i am sure Mug Funky knew what i meant though. :)

[Zarxrax]

Ok this kind of makes sense. But if you are encoding just for dvd, where is the advantage of encoding progressive? If adding pulldown will force you to encode at lower bitrates, then is that really any better than encoding interlaced at a higher bitrate?

[Guest]

If adding pulldown will force you to encode at lower bitrates... I don't think that is a valid thesis.

[Zarxrax]

I don't think that is a valid thesis.

Well, both dvd authoring programs that I tried would not let me use my perfectly within-valid-bitrate-range encodes after I applied pulldown to them, because they would then say that the bitrate was too high. In order to get my files into these authoring programs I would have to severely cut my bitrate (maximum bitrate 7500).

Although, I just now realized, maximum bitrate does not limit the average bitrate that I can use.

[dragongodz]

Although, I just now realized, maximum bitrate does not limit the average bitrate that I can use.
correct, its just the max bitrate that needs to be lowered. consider also that if you were encoding to real 29.97fps at the same average bitrate and higher max bitrate the bits would have to be spread over more frames so the extra you get from the higher max bitrate doesnt mean it will actually look any better.

[Mug Funky]

hmm... superbit encodes i've seen are 100% FILM, and report huge max bitrates in BV. i could only assume these are still DVD compliant though (who'd release a disc that's way out of spec?). maybe the authoring programs are buggy? maybe you could be sneaky and just change the max bitrate flag and leave the stream as is?

the only authoring program i really know is DVDmaestro, and it's got no problem with pulled-down video (although i very very rarely deal with NTSC in spruce).

btw, i thought the wrong bitrate in BV was more because it ignored the flagging and assumed a framerate of 29.97 - but i'm not sure of this (does it report the movie as being shorter?).

[Boulder]

Would be interesting to hear if for example Mpeg Stream Eye shows the same behaviour.

[joho83]

I have a question about bitrate, can some please explain to me briefly what it means? I'm backing up som of my dvd's, and the movies are going to be seen on a TV. How can I calculate my bitrate, and what number should I set as max bitrate? Or should I check Auto Max. Bitrate?

In the main window of Quenc, the bitrate says 2500, should I always use 2500? What is the difference between this bitrate, and the max bitrate in advanced settings?

Regards Newbie :)

[Mug Funky]

simple - bitrate is amount of data over time (usually kilobits per second).

the bitrate will vary, but the encoder will make sure the average is the number you set for bitrate. the max bitrate exists to prevent the encoder using so much data for a complex bit of video that it exceeds the speed a DVD player can read.

if you're making DVDs, a good safe max to set is 8500 kbps. if you think your player can handle more, give it 9000. the absolute maximum that a DVD player is designed to handle is 10080, and this includes all audio tracks plus subtitles. a safe max for all streams is 9800 (10080 is overkill and WILL cause playback problems on almost everything, besides DVD authoring programs will simply not accept these streams).

setting an average bitrate is a little more tricky - aim to fill the disc completely (give a few megs leeway of course). you'll need a little maths for this, or a good bitrate calculator (we've got an almost perfect one here, but i can't share it unfortunately... it wouldn't be cool).

you'll be getting near perfect encodes at around 7000 kbps average, max 8500. quenc will usually undersize at these rates, but don't worry - it does that because it's maxed out the quality and can't fit any more with it's current quant matrix.

[Nic]

Ok, I never have any free time, so I don't have time to do testing, so could someone help me out:
http://nic.dnsalias.com/QuEnc_VeryExperimental.zip

Might have better two pass bitrate control. So turn on VBR and 2 Pass set a max bitrate. See how it goes. Works a little better for me, but ive tested it twice. Got very little time for any more.

-Nic

ps
(The only real change is now I look at the projected next frame and add that to the bitrate of the previous second (minus one frame) then see if that is over the max bitrate set. If so I keep raising the quant till it does fit. Not perfect, but seems more effective than what was previously there)

pps
ignore the possible under/overflow errors that will pop up. That's more debug info then anything else.

ppps
Just re-uploaded it. If you've already downloaded it make sure that it's version 0.6.1.2 when you look at right click->properties->version tab.

[setarip_old]

@Mug Funky

Hi!

A small point...

10080 is overkill and WILL cause playback problems on almost everything, besides DVD authoring programs will simply not accept these streams

If I remember correctly, "TMPGEnc DVD Author" will issue a warning about such excessive bitrate, but WILL allow you to choose to ignore it and proceed to successfully process the DVD...

[Zarxrax]

Pulldown doesnt work for me. I have tried 0.6.1 and the experimental build posted above. Resulting file is reported to be 23.976fps with no pulldown by DVD-Lab.

[Mug Funky]

@ setarip_old: try the same in Spruce or Scenarist... :)

@ nic: test version! cool. that sorta slipped under the radar... trying it out now on some random DV crap. hasn't underflowed yet, but then i had no problems with the last one either.

btw, any reason the last GOP on a 2-pass encode seems to get hit too hard? it's been behaving that way since the xvid RC was implemented. same with certain fade-ins and outs - quants just seem to get quite high.

[edit]

oh, and 2nd pass seems to be faster than the first (24fps vs 32fps on interlaced PAL DV)... is this usual? i was under the impression there was a kind of "fast 1st pass" thing going.

[mean]

It seems you look at it under a bitrate angle instead of VBV fullness (?).

[GoDuke]

It appears that I'm getting bitrate spikes similar to those experienced by Zarxrax and john3voltas.

I'm still a bit of a newbie, but I just tried to author a simple DVD (using DVDStyler) from QuEnc clips and my Philips DVP642 can't handle it (for that matter, neither can my computer, when I try to play from the disc).

Since the symptoms sounded the same, I checked the original clips and the VOBs on the DVD. Sure enough, Bitrate Viewer shows huge bitrate spikes. There are at least 20 points where the bitrate exceeds 10000, and the peak is 15392 at 3:35 into a 23:34 clip.

My QuEnc 0.61 settings:

MPEG2
Bitrate: 6000
Use VBR
High Quality
Use Trellis
2 Pass Encoding
---
Extreme & Slow = no
Force Closed GOP = no
Scene Detection = no
Interlaced Encoding
DC Precision = 10
Top Field First = no
Pulldown = no
Auto Max Bitrate
4:3 Aspect Ratio
Use QLB Matrix
MPEG2 Mux profile = DVD
AC3 Audio Codec
Audio Bitrate = 256kb


Have I messed something up, or is there a greater mystery at work here?

Thanks

[dragongodz]

Auto Max Bitrate
this sets the max bitrate to 3 times the average bitrate....and you wonder why the max bitrate is getting so high ????

set the max bitrate manually.

i am starting to think the auto max bitrate setting is a bad thing.

[Nic]

@Zarxrax: You're probably right. It probably isn't working till I apply means patch to my code again. I'll do that with the next proper release and text that pulldown is added. Thanks for the report.

@GoDuke: Have you tried my latest version (the experimental one). If not, could you please try with that version. I'd very appeciate feedback on the new ratecontrol modification.

@mean: Yes. The code I got from your project seems to take care of the VBV well enough, but it's still causing people problems, and people are blaming the bitrate. So my solution has been a very harsh clamp on bitrate rising over the maximum selected. But it seems to be working better that way. If you have any views/ideas/info please post them as i'd be most interested :)

@Mug Funky: Yes there is a reason the last GOP gets hit hard and I think it's because when we hit the last second some of the functions just stop working as they should. I'll look into it. Should be an easy fix, well spotted though.

So, in conclusion, please keep testing the Experimental QuEnc build posted above and let me know of any bitrate spikes. Thanks everyone :)

Cheers,
-Nic

[mean]

There was some stuff to also take the max bitrate into account, but i'm afraid it will hurt the quality badly if you do both bitrate and Qz clamp at the same time

Here are my thought on the topic; for what it 's worth :

The best way would be to do a mix between gop based ratecontrol and xvid ratecontrol.

i.e. let's concentrate a whole gop as a fake frame.
Let's xvid ratecontrol handle bitrate distribution for these fake frame.

You will end up with a Qz or a size for any whole gop.
you can switch then to a per-gop ratecontrol which is easier because you can take assumptions such as :
- the VBV buffer is full at start up
- it must be ~ full at end
- you reserve X % for the 1st intra

The benefit is any error will be limited to one gop and it would still separate the VBV enformcement issue from the bit distribution issue.

[GoDuke]

Dragongodz: :thanks:

That would certainly explain the problem, wouldn't it? I guess that I assumed "auto max bitrate" wouldn't produce a bitrate out of spec for DVD.

Instead of doing away with the auto max setting, would it make sense to simply cap the max bitrate produced some DVD compliant level? Thus "auto max bitrate" become something like: "the lesser of 3 times the average bitrate setting -or- 9800".


Nic: I'll download the experimental version and try it with my replacement encodes. What feedback information would be helpful?

[Revgen]

Hi Nic,

I believe I've found a problem which I originally thought was a bitrate spike, but now seems to be a problem with Quenc not compressing at all.

I encoded 4 different clips at 2500kbps-15GOP-2 BFrames-DC9. Each clip differed from the other by using Autobitrate or Max Bitrate set 8000Kbps, and QLB ON or OFF.

Each clip gave me "Possible Errors" over 135. The Maxbitrate clip with QLB gave me the most at 149.

So I decided to play them all back using FFDShow's decoder with the OSD ON and Input Bitrate checkbox enabled to see if any spikes existed.

All of the clips had a huge bitrate spike right at the beginning of the clip. The rest of the clip appeared to be fine. So I decided to open up one of the clips in VirtualDubMod to see up close if there was a problem.

It turns out that the first 3 frames (frames 0,1,and 2) don't appear to be compressed at all. I opened up my .AVS file and compared it to the .M2V file and they looked similar to my eyes. Frames 3 and beyond seemed to be compressed properly.

PS

I'll post some screenshots of the .M2V and .AVS files up a little later, I've got to take care of a few errands first.

EDIT1

I forgot to mention that this is for the Experimental Version. Sorry.

[Nic]

@GoDuke: Yes, please test again with the experimental version. Set VBR, 2 pass and max bitrate around 9500 (always good to set it a little below 9800 anyway). It should stay within the limits this time round :) Normal feedback and especially if it hits its expected output fukesize (I'm guessing it might undersize) and if it appears to go over the max bitrate (view with bitrate viewer).

@mean: An interesting idea, will you be implementing it for your application? It's rare that the bitrate spikes, yes it might hurt the picture on those parts but at present it's the best solution I have :)

@Revgen: Hmmm, I find this hard to believe at present because it's hard for ffdshow to show the bitrate for a file from the 0-3 frames because bitrate is bits per second and a second hasn't passed yet. Other apps like bitrateviewer don't show this so far, and I haven't been able to recreate this yet using the latest version of ffdshow. But i'll keep looking. You could be right.
(Could you make sure you are using ffdshow-20050909-MSVC71.exe so we are both using the same filter for testing. For me, that filter doesn't even display a bitrate for the 1st three frames)

-Nic

ps
Found the bug as to why pulldown wasn't working. D'oh. (I should set "flags2" rather than "flags" in the source). Will be fixed next release.

pps
SNOW mode is broken in experimental too. Will be fixed in next release. (strict_compliance needs to be -2 not -1 now). I'm going to add a MP4 mode too, purely selfish, I'm going to use it with the mobilehackerz patch so I can encode video for my PSP & W800 phone.

[Revgen]

Here are my screenshots from my AVS and my encoded file.

Frames 0-2 from the AVS are uncompressed and show the grain in the sky.

http://img219.imageshack.us/img219/2038/goofsavsframe09pt.th.jpg (http://img219.imageshack.us/my.php?image=goofsavsframe09pt.jpg) http://img219.imageshack.us/img219/6354/goofsavsframe12vb.th.jpg (http://img219.imageshack.us/my.php?image=goofsavsframe12vb.jpg) http://img219.imageshack.us/img219/8832/goofsavsframe26ir.th.jpg (http://img219.imageshack.us/my.php?image=goofsavsframe26ir.jpg)

Frames 0-2 from the Quenc encoded file also show grain in the sky.

http://img219.imageshack.us/img219/1629/goofsquencexpframe04xs.th.jpg (http://img219.imageshack.us/my.php?image=goofsquencexpframe04xs.jpg) http://img219.imageshack.us/img219/9240/goofsquencexpframe15hf.th.jpg (http://img219.imageshack.us/my.php?image=goofsquencexpframe15hf.jpg) http://img219.imageshack.us/img219/5449/goofsquencexpframe24wn.th.jpg (http://img219.imageshack.us/my.php?image=goofsquencexpframe24wn.jpg)

Frames 3-5 from the Quenc file do not show grain in the sky.

http://img219.imageshack.us/img219/6123/goofsquencexpframe33ev.th.jpg (http://img219.imageshack.us/my.php?image=goofsquencexpframe33ev.jpg) http://img219.imageshack.us/img219/1175/goofsquencexpframe41mc.th.jpg (http://img219.imageshack.us/my.php?image=goofsquencexpframe41mc.jpg) http://img219.imageshack.us/img219/387/goofsquencexpframe53xr.th.jpg (http://img219.imageshack.us/my.php?image=goofsquencexpframe53xr.jpg)

Frames 3-5 from the AVS do.

http://img219.imageshack.us/img219/2733/goofsavsframe38bm.th.jpg (http://img219.imageshack.us/my.php?image=goofsavsframe38bm.jpg) http://img219.imageshack.us/img219/6213/goofsavsframe45ti.th.jpg (http://img219.imageshack.us/my.php?image=goofsavsframe45ti.jpg) http://img219.imageshack.us/img219/7614/goofsavsframe52xy.th.jpg (http://img219.imageshack.us/my.php?image=goofsavsframe52xy.jpg)


The difference between frames 2 and 3 in the Quenc encode shows a noticeable difference.


My AVS Script in case your interested:

LoadPlugin("E:\LoadPluginEx.dll")
LoadPlugin("E:\DustV5.dll")
LoadPlugin("E:\DGMPGDEC141RC4\DGDecode.dll")
mpeg2source("E:\3s-Goofs and Saddles\goofs.d2v",idct=7)
Trim(4482,5454)
Greyscale()
ConvertToYUY2()
PixieDust()
ConvertToYV12()


I hope this helps.

[Nic]

@revgen: What does bitrate viewer or similar say. Have you tried it with that version of ffdshow i suggested. Is there anyway you could post the first few megabytes of the file?

-Nic

[DarkFoon]

Just got done with a dedicated testing session for the experimental version.

My System:
Windows ME
866MHz P3 Coppermine
512MB PC133 SDRAM
7200RPM ATA100 HDD

I had Winamp playing WAV files and an open Windows Explorer window both in the background. Quenc was the "in-focus" application. (Except when I had to turn on looping in winamp because I forgot)
In the systray was Sygate Personal Firewall Pro, AVG antivirus, and the Turtle Beach Santa Cruz (my soundcard) utility.

I ran all three tests one after another with no rebooting. The computer wasn't even a "clean boot" either: I had already checked my email and been to this forum before I started testing. I did this for "real world" results. (Though I doubt most people do other tasks while encoding; I usually don't myself)

Quenc Settings:
Mpeg-2
Bitrate: 7000
VBR-on
High Quality-on
2 pass-on
Advanced:
DC-10
GOP-18
B-Frames-2
Closed GOP-on
Max Bitrate-8500
Normal Priority
Mux Profile-DVD
Audio-MP2
Audio Bitrate-384
CQM: Bulletproof's High Quality

Video resolution: 704x480
Progressive frames

(I wanted to kill two birds with one stone: test Quenc, and test CQMs.)
I used the same settings for all runs. (Including the QM, I only tested the one)

The Results:
1st Pass, 1st Attempt
Peak FPS: 0.93
Notes: This test did not complete because while I was rocking out to my music, I dropped a pen and it landed on <enter> and cancelled the test
1st Pass, 2nd Attempt
Peak FPS: 0.95
Notes: At the very end the FPS dropped to 0.94 then the timeleft went crazy (something like 1125:30:01. I chalk this up to a WinME bug I've encountered)
Then the second pass started.
2nd Pass, 2nd Attempt
Peak FPS: 0.93
Possible Overflows: 62
Time: ~11:44 (I forgot to take the time of the previous tests)
Notes: the second pass takes longer to reach the peak FPS than the first pass: i.e. it reaches it only within the last minute of encoding.
1st Pass, 3rd Attempt
Peak FPS: 0.93
Time: ~14:38
Notes: At the very end (i.e. when the progress bar reached the end) it had the same behavior as the 1st pass, 2nd attempt.
2nd Pass, 3rd Attempt
Peak FPS: 0.92
Possible Overflows: 62
Time: 14:33 (not a typo, I timed this one exactly)
Notes: Took longer than first pass to reach peak bitrate.
1st Pass, 4th Attempt
Peak FPS: 0.94
Time: ~14:26
Notes: Same end behavior as the other two first passes.
2nd Pass 4th Attempt
Peak FPS: 0.92
Possible Overflows: 62
Time: ~14:25
Notes: Same behavior as other 2nd passes


Bitrate Viewer Report:
BV version 1.5.054


1st Attempt: None, didn't complete

2nd Attempt:
Peak Bitrate: 6696
Average Bitrate: 5036
Peak Q: 7.21
Lowest Q: 1.77
Average Q: 2.85

3rd Attempt:
Peak Bitrate: 6696
Average Bitrate: 5036
Peak Q: 7.21
Lowest Q: 1.77
Average Q: 2.85

4th Attempt:
Peak Bitrate: 6696
Average Bitrate: 5036
Peak Q: 7.21
Lowest Q: 1.77
Average Q: 2.85

At least its consistent. ;)


The AVS:
loadplugin("C:\plugins\dgdecode.dll")
loadplugin("c:\plugins\MPASource.dll")
loadplugin("C:\plugins\mvtools.dll")
loadplugin("C:\plugins\decomb521.dll")
loadplugin("C:\plugins\fft3dfilter.dll")
loadplugin("C:\plugins\msmooth.dll")
loadplugin("C:\plugins\dup.dll")
loadplugin("C:\plugins\framedbl.dll")
loadplugin("C:\plugins\blockbuster.dll")

function keepminrate(clip c, float "amount", int "thresh") {
amount=default(amount,1)
thresh=default(thresh,50)
d=Blockbuster(c,method="noise",detail_min=1,detail_max=2,variance=amount,seed=8)
c=ConditionalFilter(c, d, c, "AverageLuma()", "lessthan", string(thresh))
return c
}
function fmin( int f1, int f2) {
return ( f1<f2 ) ? f1 : f2
}





v = mpeg2source("rc-kill_bunny.d2v",cpu=0,idct=4,ipp=true,moderate_h=20 ,moderate_v=40 ,showq=false,fastmc=false,cpu2=" ")

a = mpasource("rc-kill_bunny-93ms.mpa",normalize=false).delayaudio(-0.093)

audiodub(v,a)


#trim(9666,12840) ##kill bunny
trim(13926,14730) ##who poop last?



fft3dfilter(sigma=2, plane=0, bt=3, bw=40, bh=40, ow=10, oh=10, sharpen=0, smin=4.0, smax=20.0, kratio=1.0, measure=true, interlaced=false)

crop(8,0,-8,0,align=true)


source = last




backward_vectors2 = source.MVAnalyse(isb = true, lambda = 1000, delta = 2)
backward_vectors1 = source.MVAnalyse(isb = true, lambda = 1000, delta = 1)
forward_vectors1 = source.MVAnalyse(isb = false, lambda = 1000, delta = 1)
forward_vectors2 = source.MVAnalyse(isb = false, lambda = 1000, delta = 2)
#return
source.MVDenoise(backward_vectors1, backward_vectors2, forward_vectors1, forward_vectors2, tht = 100, thsad = 250, thmv = 50)

#framedbl(255,1)

#dup(threshold=2.25,copy=true,show=false,chroma=false,blend=false) ##good one. for reference only!
#dup(threshold=3,copy=true,show=false,chroma=false,blend=false)

fft3dfilter(sigma=2.5, plane=0, bt=3, bw=32, bh=32, ow=10, oh=10, sharpen=0.5, smin=4.0, smax=20.0, kratio=1.0, measure=true, interlaced=false)

#deblock(quant = 51, aoffset = 16, boffset = 16)







#bilinearresize(1708,960)
#pointresize(1280,720)

#lanczos4resize(1280,720)
#bilinearresize(960,540)

#bilinearresize(864,486)







#bilinearresize(720,480)

#trim(0,1124)


#peakblur(2,10)

#keepminrate(2,50)


Sorry it's so messy. I experiment with new things in every one of my scripts, then I comment out the ones that I like, but don't need, in case I need them for another project in the future.

I think that's everything.
Thanks.

P.S.
For those of you curious, I was listening to FLCL OST vol 1.

[Revgen]

Hmm... Bitrate Viewer reports no spikes.

Which is good, but then does this mean that when Quenc tells me I have "xxx possible overthrow errors" I should just take it with a grain of salt?

[Nic]

@darkfoon: thanks for testing :) Well it never went over the bitrate, which is good. But it doesn't look like it was really tested as the Quant is pretty low. That might be the reason it had a problem reason reaching the desired bitrate. But it seemed to miss it by quite a bit. I'll look into that. How was the quality?

@revgen: Yup ignore the possible overflows, that's mainly debug data for me :) (it's confusing a lot of people so won't be there on the next build)

[Revgen]

Sorry it's so messy. I experiment with new things in every one of my scripts, then I comment out the ones that I like, but don't need, in case I need them for another project in the future.


Messy? HA! :D

You should look at the mess I made over in this thread. (http://forum.doom9.org/showthread.php?p=708835#post708835)

I'll definately take a few queues from your post and improve the next time I test. ;)

[DarkFoon]

@Nic
the quality is good, for a bad TV capture. The parts that are bad source quality (such as grainy areas) don't look very good.
And there's one scene that's a little blocky where some large text that fills teh screen moves around. (but that could be from the MV denoising)
I'm going to test again with the same parameters with a clip I made in flash (all vector work) which will have NO noise.

On the other hand, the audio doesn't sound very good at all. But this ain't no stinkin' audio encoder! So it's not all that important.

[DarkFoon]

Hmm. My first Quenc bug....
When I load the AVS, or the AVI file directly, into Quenc and hit hte "Encode" button, it changes the button to "stop" then back to "encode" in under a second.
No file is produced, no error, nothing.
Very strange.
The Script:
AVISource("random clip.avi")
converttoYV12()


The file is HuffYUV 2.11 RGB24.
Its 13 seconds long, and 24.00fps (exactly, not 23.976!)
720x480

This happens not only with the experimental version, but also 0.61.

@RevGen
wow that is messy ;) I'm glad that I'm a good example to somebody.

EDIT:
well, I figured out the problem: apparently Quenc doesn't like 24fps, it will accept 30fps, but not 24. Strange...

@Dragongodz
I don't reccomend MPEGStream Eye because it installed some Mpeg2 decoders that have totally messed up the way my system playsback MPEG2. My Hauppauge Capture card no longer works, and I have to re-install its decoder.
So, I'll stick with bitrate viewer (even though I don't like it much)

[dragongodz]

It turns out that the first 3 frames (frames 0,1,and 2) don't appear to be compressed at all.
Revgen - the frames are actually decoded and passed through to QuEnc uncompressed. the sizes of those frames show it is actually compressing because otherwise they would be huge.

can people also download and try mpeg stream eye since i personally have found that more reliable than bitrate viewer. get it here
http://www.free-codecs.com/download/Moonlight_MPEG_Stream_Eye.htm

mean - yes i know another encoder that works the bitrate per GOP. that is it allows a % of the max bitrate proportionally to the amount of frames in the GOP in relation to FPS. so a GOP wont go over the max bitrate and there are bits allowed for the following frames. then after so many GOPS bitrate pickup is also done, that is if the encode is running lower because of VBV fixes then a GOP is encoded back towards the average, the bits compensated back if you will. if you really want to get technical about it though the way Nic is doing it is the most accurate because there should never be an y exceeding in any second of the produced footage.

EDIT:
That might be the reason it had a problem reason reaching the desired bitrate. But it seemed to miss it by quite a bit.
is the bits being lost by lowering the quant being added back to be compensated later ?

I'm going to add a MP4 mode too, purely selfish, I'm going to use it with the mobilehackerz patch so I can encode video for my PSP & W800 phone.
i still say make a seperate program for other outputs such as avi and mp4 etc etc etc. that way if there are any needed fixes or changes it doesnt effect the mpeg 1/2 side of things etc. thats just my hummble opinion anyway but you already know that Nic. ;)

[DarkFoon]

Here's another encode I did to test this Experimental release.
http://rapidshare.de/files/5043073/testvid.mpg.html
(my apologies to those of you who cannot access rapidshare, I don't know of any other services :( )
The ending is hit too hard by the encoder, IMO.
My parameters were:
Mpeg-2
Bitrate: 7000
VBR-on
High Quality-on
2 pass-on
Advanced:
DC-10
GOP-18
B-Frames-2
Closed GOP-on
Max Bitrate-8500
Normal Priority
Mux Profile-DVD
Audio-MP2
Audio Bitrate-384
CQM: Bulletproof's High Quality

720x480
30fps
progressive


Strangely enough, the GOP is reported to be 16 by VDubMod. (Or at least all the I frames are multiples of 16, not 18)

You tell me how the quality is. (I will reserve my opinion until others have spoken)

[Nic]

@Darkfoon: Thanks for all the testing. QuEnc should like 24fps. I'll check later tonight and fix it if it doesn't. Downloading your clip now.
EDIT: Downloaded the clip. Well i'm glad to see the bitrate control worked at least hits the peak almost exactly and doesn't have a huge bitrate spike. I was expecting the quality to be really visually bad, and although the bitrate is lower than it should be, the quality is ok for all that motion and large blocks of color.
It's a nice test clip. Can you post that part of the original?

@dgz:
"is the bits being lost by lowering the quant being added back to be compensated later ?"
Yup, they should be. But i've got a lot of checking to do still in that code.

"i still say make a seperate program for other outputs such as avi and mp4 etc etc etc."
I completely agree. My only problem is I really need QuEnc to do my mobile phone recordings (and so might other people) and I don't have time to make a separate app. It shouldn't harm anything. I hope ;)
(I need QuEnc because the bitrate needs to be below 200kbps. libavcodec can't normally guarentee that in any mode just yet, but QuEncs new 2 pass can :) )

-Nic

[Mug Funky]

Strangely enough, the GOP is reported to be 16 by VDubMod. (Or at least all the I frames are multiples of 16, not 18)

i've noticed this too. turn closed-GOP off and you'll get the correct length.

[DarkFoon]

@Mug Funky
It just occured to me why the GOP is shorter with closed GOP on.
A closed GOP has no inter-GOP dependencies, therefore, it must remove the last 2 B-frames so they aren't dependent on the next I-frame. This would make the GOP 16 frames, not 18.
I first noticed this in TMPG. Why I didn't make the connection sooner I don't know...

@Nic
One question: why can't closed GOP and scene detection be on at the same time? Somehow I've gotten them to work together in TMPG. Usually what happens is when it wants to insert the I-frame (because Scene detection says so) it just closes the current GOP and inserts the I-frame, starting a new GOP. The only side-effect is that some GOPs will be smaller than others, but none will be larger than the user-specified GOP size, so it should still be DVD compliant. (As I understand it, DVD spec says the GOP needs to be at most 18 frames.)
Can it be implemented in this way in the upcoming release of Quenc?

Here's the original, as requested.
http://rapidshare.de/files/5046118/Random_Clip.zip.html
Note: its 24fps, I got it to work in Quenc with assumefps(23.976)
ps
I didn't know which format to use, so I used uncompressed RGB, then zipped it. It worked out favorably ;)

[Nic]

@Darkfoon: Thanks for the clip. Downloading it now.
"One question: why can't closed GOP and scene detection be on at the same time?"
Currently you can't do it in libavcodec. I could try fixing it if I get some time. Personally I like to have scene detection turned off with MPEG-2. Makes the GOPs far more predictable ;)

-Nic

ps
Wow! That did zip up well :)
MPEG isn't particulary good at non-natural images, so it's a nice test in some ways. Do any other MPEG Encoders encode it better (at the same output file size) as QuEnc?

[DarkFoon]

@Nic
No, I haven't tested it with any other MPEG encoders. I think I might do that before I finally go to bed. I actually made that test file earlier today in Flash. Took about 2 hours. I tried to incorporate all the things that strain encoders: low motion then high motion, slow motion overlayed onto of high motion, fast zooms.

Is there a way that I can make a BAT file that runs multiple Quenc tests sequentially? I have a BAT file that works fine, except that it starts all 10 instances of Quenc and has them running concurrently, I would like to run them one after another.

[Nic]

@Darkfoon:
"Is there a way that I can make a BAT file that runs multiple Quenc tests sequentially?"
Not that I can think of i'm afraid. It would be quite tricky to do without an app designed for batching (it would have to CreateProcess and then wait on the process handle of QuEnc to finish before starting the next QuEnc process. Can't think how that could be done in anything other than code)

-Nic

[buzzqw]

use a string like that

FOR /F "tokens=*" %%i in ("quenc.exe -parameter -parameter -- ") DO CALL START /WAIT %%i

for every row, it will wait the end of last befare lauch next

BHH

[dragongodz]

I don't reccomend MPEGStream Eye because it installed some Mpeg2 decoders that have totally messed up the way my system playsback MPEG2.
all you have to do is lower the merit of the moonlight decoder and splitter and they will not be used before other decoders etc. i did that and it interferes with nothing ,never gets used. you can use DSFManager or Radlights Filter Manager to that. :)
the reason i say to try with that is however because you may find bitrates reported by bitrate viewer are lower than the real bitrate.

I don't have time to make a separate app. It shouldn't harm anything. I hope
thats cool. i just dont want it getting too bloated and losing its purpose, a very good mpeg 1/2 encoder. ;)

Is there a way that I can make a BAT file that runs multiple Quenc tests sequentially? I have a BAT file that works fine, except that it starts all 10 instances of Quenc and has them running concurrently, I would like to run them one after another.
so if you create a file called test.bat and put the lines
quenc -i test1.avs -o p0.m2v -auto -close
quenc -i test2.avs -o p1.m2v -auto -close
in it and then run(just double click) the bat file it runs multiple QuEnc all at once ? funny that runs sequentially for me.

now about that random clip, downloaded it and tried it. hmm well it works with QuEnc 0.60RC2(just had it sitting there so tested it) so the problem has come after that version somewhere. hopefully that should help narrow it down Nic.

Nic - i was going to release a test version with PHODS ME for that bad small block but can not. i removed all the relevant #ifdef's and found that the reason the other ME routines are disabled is not just because they are no longer maintained but infact they have been broken. so no FULL SEARCH, no PHODS and no LOG ME's. so you are left with NONE or EZPS and thats it. that sucks.
also about the header stuff we talked about by PM i think i will just hard code the sequential header in to the log at every I frame and see if that makes any difference, tomorrow. well others can test it anyway. ;)

[Axed]

Its because DarkFoon uses Windows ME.

Try doing it like this DarkFoon. If it doesnt work, remove the " " and use input/output file names without spaces.

start /wait "queenc.exe -whatever -options"
start /wait "queenc.exe -whatever -options"

[Mug Funky]

...This would make the GOP 16 frames, not 18.

hmm.. would it not be possible to close a GOP by just making both ending b-frames refer only to the preceding p-frame? this would take away all the advantage of b-frames, but should be do-able.

i know MPX3000s will give GOPs of 12 no matter whether they're closed or open.

[DarkFoon]

@buzzqw and Axed
Thanks!

@Mug Funky
I don't know what an MPX3000 is (I'm guessing its a capture card) but it probably stuffs the last frames with P-frames instead of B-frames. It seems like Closed GOP can be implmented in many ways, as long as all I-frames after the first have a P-frame preceeding them. So, I suppose one could just replace the B-frames with P-frames, or one could just remove the B-frames.

So, yes, one could go about making the B-frames refer to just the P-frame preceeding them, but the problem with that is that it makes a "special" B-frame, and it could potentially confuse the decoder. I'm guessing that's why nobody has implmented it in that way (except for the MPX3000 perhaps)

[hank315]

hmm.. would it not be possible to close a GOP by just making both ending b-frames refer only to the preceding p-frame? this would take away all the advantage of b-frames, but should be do-able.That won't work...
A closed GOP has nothing to do with the way a GOP ends but only how it starts.
In a closed GOP the I-frame is played first; in an open GOP the B-frames after the I-frame are played first and they are predicted by the P-frame from the previous GOP and the I-frame from the new GOP.
It can be closed if these B-frames are only predicted from the I-frame but that's a bad way to start a GOP.

[video]

hank315 is there any good reason for not starting a GOP with an I-frame? However the trouble comes fromt the fact, tha cinema craft's manual calls the GOP colsed when the GOP has no referenceces out of it's boundary - neither starting nor ending pictures are depending on the previous/next GOP.. and afaik the DVD spec uses this definition for "closed" GOPs, too

[hank315]

Maybe my explanation wasn't very clear :)
A GOP always starts with a I-frame and a closed GOP doesn't need information from the previous GOP so the next is absolutely true:
However the trouble comes fromt the fact, tha cinema craft's manual calls the GOP colsed when the GOP has no referenceces out of it's boundary - neither starting nor ending pictures are depending on the previous/next GOP.. and afaik the DVD spec uses this definition for "closed" GOPs, tooBut there's a difference in the stream order and the display order.
In an open GOP the starting I-frame isn't the first frame which is played, first the B-frames after the I-frame are played, after that the I-frame etc.
These B-frames depend on the P-frame from the previous GOP also that's why the video can't be cut at this point so the GOP is called open.
stream order open GOP: IBBPBBPBB... --> play order: BBIBBPBBP... (the first 2 B-frames are predicted from the previous GOP also)
stream order closed GOP: IPBBPBBPBB... --> play order: IBBPBBPBB... (no info needed from the previous GOP)

[DarkFoon]

@video
The GOP starts with an I-frame because of the differences in frame types.
An I-frame is basically the whole frame that has been compressed
a P-frame contains only the changes from the I-frame.
If you started a GOP on a P-frame, that GOP would be dependent on some previous I-frame. The whole purpose of closed GOPs is so that if the user wants to remove some GOPs they don't have to re-encode.
This is as far as I know, correct me if I'm wrong.