QuEnc 0.60 Released!

[Nic]

QuEnc 0.60 Released! New two pass control :)

http://nic.dnsalias.com


New XviD Ratecontrol in 2 Pass mode!
Added a MPEG-1 System mux mode
Can apply pulldown to the encode
Bug fixing...More stable (for use in more than one instance of QuEnc, etc)
Tooltips
A bunch of other stuff I'm too ill to remember ;)


Have fun :)

-Nic

EDIT:
Just release 0.61! Slight bug in the MPEG-1 System Mux was fixed.

[Mug Funky]

weeeee! thanks, nic.

[Koepi]

Great! :)

Unfortunately I did my last full-dvd-encode just yesterday and I've no projects on hold, so it needs some time until I can test it :)

Thakns for your work Nic!

Cheers
Koepi

[Teegedeck]

Yaaay! Congrats! The only MPEG-2-encoder I'd ever use turns 0.60! :)

[dragongodz]

a milestone indeed. Nic releases a 0.60 version. seems he has overcome that demon. :D

[communist]

Great! I have 4 SVCDs to encode for a friend and I just started the first pass on the first disc with 0.59 - might aswell abort it and use this version :D

Quick test with a few small test files: No more crash when running several instances in 2pass mode. Quality seems as good as with 0.59b4 if not slightly better.
Thank You :)

[Affar]

I have same problem with previous version. When i encode this CLIP (http://www.divxhouse.com/temp/error_db.avi), the encoded video has one frame less than source.

Thanks

[ginoboy]

Great!! Excellent! :cool:

Thank you Nic! ;)

[]'s

[communist]

Originally posted by Affar
I have same problem with previous version. When i encode this CLIP (http://www.divxhouse.com/temp/error_db.avi), the encoded video has one frame less than source.

Thanks
AFAIK this is not a QuEnc bug but a VfW / B-frame issue (the 'B-frame decoder lag' message).

[TuRiSOft]

Hey NIC thank you !!! With you and Hank who needs more to use not freeware MPEG2 encoders?

[robot1]

Thank you, Nic.
Will test soon.

[Nic]

@Affar: When I put that AVI clip in VDub, it says it has 149 frames. When I encode a M2V file and run it through BitrateViewer, it says it has 149 frames too. What discrepancy are you seeing and how do I replicate it.

-Nic

[Affar]

I dont know where is the problem, but this persist in 3 diferent pc.

ERROR with this scripts
(avisynth 2.5.5 + ffdshow october 2005 + xvid 1.1)

Avisource("O:\error_db.avi")
BicubicResize(352,576,0,0.50)
ConvertToYV12 ()

Directshowsource("O:\error_db.avi")
BicubicResize(352,576,0,0.50)
ConvertToYV12 ()


Quenc configuration:

quenc.exe -i "script.avs" -o "O:\error_db.m2v" -b 1600 -maxbitrate 2500 -dc 10 -priority 4 -2 -mpeg2 -hq -vbr -scene -notrell -nocgop -nointerlaced -noextreme -gopsize 15 -maxbframes 2 -nocmatrix -aspectratio 4:3 -mpeg2mux noaudio -auto -close

And bitrateviewer says... 148 frames
http://www.divxhouse.com/temp/error_db.gif

any suggestions?

[Pookie]

Awesome. I love this encoder. Can't wait to try out the new version.

[dragongodz]

And bitrateviewer says... 148 frames
yes i got that but look at the number of pictures read, 149.

i tested the .avs with Tmpgenc 2.5 and MainConcept 1.4 aswell and guess what, exact same results.
mpeg stream eye says 149 frames for all of them by the way.

also tried loading the avi in to Tmpgenc and it said 177 frames. tried MC and it said 149 but actually encoded 1 less (147 frames, 148 pics read in bitrate viewer). weird avi. :D

so sorry but this is not a QuEnc problem since the other encoders are encoding exactly the same.

[unixfs]

Nic,
I have a question for you: can you explain what algorithm
you use to calculate the SCR?
In mencoder I used a series of tricks (
something similar to: for every pack scr = Gop initial pts + (delta data/ N) where N is the sum of video and audio data I'm about to mux
), but I realize it's a flawed and too simplistic method.

Often it works well, but sometimes audio pts diverges too much from scr;
additionally it's impossible to manage multiple audio tracks.

I'm looking for better alternatives.

Thanks.

[Nic]

@unifxs: Thankfully libavformat takes care of it for me :) SCR is a pain, I remember coding ReJig and that being one of the most difficult problems for getting DVD compatability just right. I honestly can't remember that much about it now. Sorry. I remember MPUCoders forum had a nice thread on it once.

-Nic

[manolito]

Next version will probably be 0.60 which will have Beta 3's 1st Pass RC and XviD's 2 pass RC. -Nic
Just did a 1 pass VBR encode with 0.61 which came out way undersized (2.52 GB instead of 4.7 GB). As far as I remember my 1 pass encodes with 0.59 Beta 3 always came out right, only Beta 4 1pass VBR was broken.

Another question about the new tool tips:
Scene Detection --- Bad for DVD encoding
Closed GOP --- Recommended for DVD encoding

From my experiences with CCE just the opposite should be true.

Cheers
manolito

[Nic]

@manolito:
1Pass VBR has always been a bit flaky, due to it's very nature. 2Pass is definitely the way to go. 2 Pass also enable the XviD ratecontrol. But I'll look into seeing what I can do.

"From my experiences with CCE just the opposite should be true"
What experiences are those? Could you elaborate. In reality any which way should be fine. Scene Detection can cause bizarre GOPs (i.e. very short GOPs) that a DVD player might not like, but I'm sure most don't have a problem. Closed GOPs are useful for seeking, but aren't necessary. Share your experiences...Are you talking from a quality point of view? If so, then closed gop = false and scene detection = true would probably equate to better quality.

-Nic

ps
@dgz: What changed between beta 3 & 4 again? I can't remember :)
(Ok, time for me to start using a CVS or at least write a changelog)

[dragongodz]

just my humble opinion

Scene Detection --- A few dvd players may not like it 100%
Closed GOP --- Only required for multi-angle DVD encoding or editing

What changed between beta 3 & 4 again? I can't remember
for 1 pass encoding nothing. however what you could try is changing
lmin = 1 * FF_QP2LAMBDA;
to
lmin = 1;
or
lmin = 0.6 * FF_QP2LAMBDA;

since if you remember the use of lambda caused undersizing with 2 pass for over about 4000Kb/s.

actually, just looking, i see you have lambda in the low bitrate setting aswell so would probably want to change that aswell. so either = 2 or = 1 * FF_QP2LAMBDA.

Ok, time for me to start using a CVS or at least write a changelog
since you used to go over/erase versions changes when you did a new one in the same thread a lot of what was changed when was lost. it would be handy though.

[manolito]

@Nic

Well I was wrong about Beta 3 getting 1 pass VBR right. I just redid the same encode with Beta 3, and it also came out terribly undersized.

CCE was the first encoder I used (I came here through DVD2SVCD), and this is what the CCE manual says about Scene Change Detection and Closed GOP:
If Restrict auto I frame insertion is selected, image quality will be slightly degraded. Therefore, do not select this unless necessary.
If Close all GOPs is selected, image quality will be slightly degraded. Therefore, do not select this unless necessary.
"Restrict Auto I frame insertion" is how you disable Scene Change Detection in CCE.

Everybody at the DVD2SVCD thread seemed to agree that these were the best settings for CCE, so I never even bothered to play with them.
1Pass VBR has always been a bit flaky, due to it's very nature.
Just a technical question about 1Pass VBR with libavcodec based encoders:

In CCE and TMPGEnc and HC you do not have control over average bitrate with 1Pass VBR, so some kind of prediction is required if you need a fixed output size. If I understand it right, a 1Pass VBR in CCE (they call it OPV) is just a constant quant encode with the exception that the min and max bitrate restrictions are observed.

Now how does QuEnc manage to do a 1Pass VBR without prediction? Do you start with a certain fixed quantizer and then constantly monitor average bitrate (or file size) and adjust the quantizer dynamically?

Cheers
manolito

[Nic]

@manolita:
What CCE states is quite correct. For quality scene change detection is very good. Closed GOP also stops predication across GOP boundaries so it can hurt quality. But both might cause compatability (scene=on & cgop=off) problems and the enhancement to quality is minimal. I really don't know. Probably makes so little difference either which way it probably isn't worth discussing ;)

I see you can understand why it probably comes out undersized. VBR one pass encoding is very hard to get right unless what you do is limit the range so much that it's almost CBR anyway. QuEnc can do Constant Quant too you know. Just enter a bitrate between 1-31 and it runs in Constant Quant mode.

-Nic

[dragongodz]

damn, i must have had invisible post mode on again. i hate when that happens. :sly:

[Mug Funky]

i've just noticed that the new ratecontrol seems to hit fades-to-black a little too hard - you can confirm this by looking at the quantizers (or just watching it :)). not sure if this falls under the category of "small tweak" or "major rewrite"...

also, though i trust xvid's and thus quenc's new ratecontrol, Maestro has been complaining about occasional buffer underflows (very few) on compiling. it does this with HC as well, so perhaps it's just maestro's problem (bitrateview doesn't show any unnecessarily high peaks). [edit: my max bitrate is 8500]

aside from that, the ratecontrol is working perfectly - good quality and spot-on the bitrate.

i wonder whether it'd be possible to enter a filesize into the little bitrate box? i think this was mentioned a while ago in the request thread...

[nnigam]

Strange behavior with the quenc output with .61 version.

I am capturing my dv camera output to an avi file using windv, capturing the timecodes using dv_datecode. Somehow avisynth is not opening the avi using AVISource so I have to use DirectShowSource. I then process the avs file with quenc .61. It complains about YV12 so I added convertoYV12 into the avs script. The output then becomes an mpg file not an m2v file which muxman refuses to open.

So I process the mpg from above with dgindex, and then use that in in the avs script, and remove the convertoyv12 line. Everything else is the
same, but this time I get an m2v file which Muxman reads just fine. No changes are made in the quenc settings, and the only change in the avs file is to remove the convertoyv12 line, and change directshowsource to mpegsource. Actually I used the script I use to process the avs files and added convertoyv12 to it for the first step.

I do not see any option for mpg/m2v, and chaning the extension in the output file name does not work.

I really would like to know what is going on since now I have to process the files twice through quenc. I upgraded my pc to amd athlon 64, and process time is down to about 3 hours but still would like to avoid having to run quenc twice on the same file.

[Nic]

Ok, I assume what's happening is that, when using DirectShowSource at least some sort of Audio stream is also coming through. Go to the advanced settings and in the mux profile part (lower left corner). Select "No Audio". After encoding the filename may still say .mpg, but will really be a raw mpeg-2 file (.m2v) so you can change it then add it into muxman.

Make sure the video is also the right resolution and frame rate otherwise muxman won't like it.

-Nic

[nnigam]

Thanks, I did not think of that. I think the audio is in the mpeg file.

Frame rate, resolution etc are all taken care of as defaults in the script.

[Wilbert]

Well I was wrong about Beta 3 getting 1 pass VBR right. I just redid the same encode with Beta 3, and it also came out terribly undersized.
Friday i had to do a bunch of mpeg-1 files (with 0.61). They also came out very undersized, although the encoding still had a lot of visible blocking. Highering the average and max bitrate didn't help.

[Koepi]

Weird, my last encode was aiming for 4.3GB and ended up at 3GB - I assumed the codec is saturated. The "original" was very crappy quality so I can't tell fo sure if QuEnc could have done better. (Target bitrate was 3950kbps, max bitrate 8000kbps.)

Cheers
Koepi

[Nic]

@Wilbert: Was that with 2 pass, or one pass?

@Koepi: How does a bitrate graph of the file look like? Is Quant 1 getting used much?

[Wilbert]

@Wilbert: Was that with 2 pass, or one pass?
It was 2 pass (i didn't try 1 pass).

[onesoul]

I tried to send you private message Nic, since your box is full I will post here :p

"Hi Nic, I am sending you a pvt although I am not sure I should post in the quenc thread instead." - lol

I found a weird ghost encoded by Quenc 0.61 as you can see at the bottom of the following pics:
http://img223.echo.cx/img223/6892/quenc0610000506pq.jpg
http://img251.echo.cx/img251/7413/quenc0610000513kv.jpg

It happens at frame 50 and 51, I did the encode at average 3100kbps, I noticed that as dc precision goes higher the worse it gets.

Here are the links to the source clip I used (around 103 mb total):

Your Download-Link: http://rapidshare.de/files/2038719/birds_original.part1.rar.html
Your Download-Link: http://rapidshare.de/files/2040566/birds_original.part2.rar.html
Your Download-Link: http://rapidshare.de/files/2040501/birds_original.part3.rar.html

Left click on them, and then click on free download below.

I find this clip a good test, the fading scenes and specially the fading in to the clouds moving are very hard ones (which I found quenc to be better than others on this particular scene). But generally quenc presents more blocks and noise. The undesizing issue is notorious too.

note: sorry I didn't see if the ghost issue happened to earlier quenc versions.

Hope it helps with you something.

Cheers,
onesoul

[Nic]

Thanks a lot for that onesoul....I look into them ASAP. (My PMs are cleared now :) )

-Nic

[video_magic]

This is all edge-of-the-seat action :) but is it true that the actual guidelines for how mpeg works (or some vital parts) are not viewable and have to be worked out or guessed? - I think this is the case unless people pay to see them, I have read up a lot on the net but it seems this is for mpeg-2 for DVD and I don't know about mpeg-1 which I gather is for VCD. Either ways it's more respect to Nic for working this stuff out! The more I read around I just get more despairing and more glad for Quenc and other people that make the tools :thanks:
Kind of a long shot but is Quenc going to be developed for new Mpeg technlogies like whatever is coming in as the next generation after mpeg-1 and 2. I know that sounds kind of a weak question but now I am looking at this archiving I do wonder about this situation long-term, I trust you understand even if there is no sound answer :o Is Mpeg-4 better for the near long-term Nic, I mean over DVD? I was just thing about DivX and other Mpeg-4 and noticed it looks as good at lower bitrates and I understand there
is hardware player support, so I had to compare this to DVD in my mind. either way, Mpeg-2 for DVD is great for a lot of my current needs like archiving lectures and general footage where high-detail is not the issue.

Thanks a lot for your current work and any hints :)

[Nic]

@onesoul: Just tried to download your files. I didn't notice they were on rapidshare. I can never download from there, my ISP/IP Address is pretty much blocked by them :( Any chance you could upload it elsewhere?

@video_magic: Depends on your needs. MPEG-4 (and it's part 10 H264/AVC) is definitely the successor to MPEG-1/2, But still mainstream support is rare. MPEG-2 is going to be around for a long long time, so it's a good choice for archiving and compatability.

-Nic

[Koepi]

Heya Nic,

ok, I'll try to find a tool which gives me statistical data about an mpeg2.

On a sidenode, since I quit my current job next monday and have a little time before starting with my next one then, I'll try to interface xvid with QuEnc and get a basic avi muxer working - that'd sure rock, a all-in-one encoding solution ;) (Only if you think that's no bad idea of course.).

Cheers
Koepi

[dragongodz]

I'll try to find a tool which gives me statistical data about an mpeg2.
mpeg stream eye can give you info such as average bitrate etc. so may be a starting point.

I'll try to interface xvid with QuEnc and get a basic avi muxer working - that'd sure rock, a all-in-one encoding solution (Only if you think that's no bad idea of course.).
avformat has avi muxxing so thats shouldnt be a problem. actually we did discuss this once before and some of us thought having 2 seperate apps, QuEnc for mpeg1/2 and ??Enc for things like snow etc to avi, would be better.

anyway i am sick as a dog so am back off to bed.

[Swede]

@onesoul: Just tried to download your files. I didn't notice they were on rapidshare. I can never download from there, my ISP/IP Address is pretty much blocked by them :( Any chance you could upload it elsewhere?I'll d/l them for you and put them in your webspace...

[onesoul]

Thanks Swede :). I should have known better.

Nic, I am experiencing the same problem as you (ISP/IP blocked) which wouldn't happen before. Now I can't even download the files I uploaded myself, lol, isn't that weird?

[Nic]

@Swede: Thanks as always :)

@onesoul: rapidshare is a nice idea in principle, but has it's problems. I haven't looked into trackerless bittorrents since their introduction, that might be a nice solution for things in the future.

@koepi: Do with QuEnc as you please. Probably compiling FFMPEG with XviD (I think it supports it) and Lame and then adding it to QuEnc is a nice solution. But if you really do have a few moments of time, i'd love it if you could browse the ratecontrol code in QuEnc. It's pretty easy to read (harder to follow though) and could perhaps do with some tweaking (I can't figure out why undersize occurs and don't have the time to look into it right now).
Congrats on the new job! :)

@dgz: I'm very ill too right now. It sucks.

-Nic

[Koepi]

dgz, nic: get better soon!

Nic: Thanks - it's really a nice job I'm going to get :)

As I need to look into the sources first anyways before starting such a (not too simple IMO) task I could of course look into ratecontrol.
Which values do you set for "container overhead"? That would account for maybe up to 3MB undersize if there isn't real frame-based container overhead in mpeg1/2.

But i'll have to see - it's only a few days until I can get to that :)

Cheers
Koepi

[zilog jones]

IfoEdit is giving me "buffer underruns" (or something like that) with videos I encoded with QuEnc when authoring DVDs. Am I doing something wrong?

The video is 720x576/25fps, from an avs (yv12)
Here's the settings I used:
6500kbps VBR, 2-pass, high-quality
Trellis Quant
12 GOP; 2 max b-frames (is this the default? i don't think i changed it)
Interlaced TFF
DC precision 9
Scene detection
4:3 AR
9500 max bitrate
No audio

[Koepi]

Your max bitrate isn't dvd compliant. Set it to 8500 (-audio bitrate).

[Encoder Master]

I though 9800Kbps is the max. standart of DVDs?!
But with a bitrate of 9500Kbps he has enough for the Audio (for example 256Kbps) and it is dvd-kompliant.

[zilog jones]

Yeah, I thought the max was 9800 too, but I thought underruns were caused by the bitrate being too high in some place, so it makes sense.

Thanks for the help!

[Mug Funky]

max total peak for DVD (including audio, subs, etc) is 10.08mbps

max peak for video only is 9.8

max for any one stream in multiangle is 8.0 minus all audio/subs (so for a 2.0 ac3 you'd end up with absolute max for multiangle video at 7776 kbps, but i'd recommend going a lot lower). additionally, length and GOP structure must be the same for multiangle.

when all's said and done, between poor quality pressings and varying playback equipment, 8.5mbps is a safe max for video. if you're very confident in your encoder's rate control, you could go to 9.0 as well.

remember that a standalone will probably have more difficulty reading burnt DVDs, meaning max bitrate should be conservative here as well (though a good burn will play as well if not better than a badly glass-mastered disc).

it would be so much easier if DVD players had larger buffers - then we could let the bitrate breathe a bit more, and also there'd be no pause at layer breaks.

[Nic]

@onesoul: Thanks again for the clip :) Finally got round to looking at it (I'm still pretty ill, bad chest infection, makes breathing a b***h)

I'm surprised you found the problem (it's so hard to spot). I think it's a motion problem. I'll try and track it down. I might PM you a private build to test, if you'd be willing?

Thanks again,
-Nic

@Swede:Thanks for getting me those files. :)

ps
EDIT: Ok, stupidly, with ffmpeg, you can have EPZS motion estimation or none whatsoever (don't be confused by such options as FULL, etc, they don't actually exist and default to NONE). With NONE however, the problem is gone! And the quality doesn't appear actually any worse?! There must be a bug in the motion code of ffmpeg. I'm going to try and make the bug easy to replicate for the ffmpeg crew, to see if they can fix it.
(I think it only mucks up on things like fades, but it shouldn't be breaking that badly)

[onesoul]

@Nic

No problem, a small contribution it is (I'm sounding like Yoda, lol). I thank you for developing Quenc :).
And thanks for the explanation also, sure I'd like to help testing new version. Maybe when ffmpeg motion estimation is corrected, quality will improve also?

I found it almost by accident, I was comparing the different encoders with that clip, especially at the fading scenes, and I do that by going frame by frame (using avscompare with up to 4 windows). It sounds a bit excentric, I admit that ;).

Get well soon, that goes to dgz too.

[dragongodz]

with ffmpeg, you can have EPZS motion estimation or none whatsoever (don't be confused by such options as FULL, etc, they don't actually exist and default to NONE
so ME_FULL, ME_LOG and ME_PHODS in motion_est.c are never actually used do you mean ?

I do that by going frame by frame
so how many frames does this happen on out of curiosity ?

Get well soon, that goes to dgz too.
thanks. feeling much better, medication does wonders. :D
probably back to 75% but still coughing up things i would rather not be. sounds like Nics worse with the breathing probs.
get well soon Nic and yes i know it sucks.

[onesoul]

so how many frames does this happen on out of curiosity ? In two frames, the ones I linked to. The frame right before was black.

[dragongodz]

onesoul - just curious, does this happen if you use the "extreme & insane" setting aswell ?

[Nic]

@dgz: It happens with almost everything if motion is used, I tried lots of settings to remove the problem, but none helped. Very strange.

[dragongodz]

hmm strange indeed. anyone able to provide a smaller sample ? i am currently on dialup speed so not keen to spend 6 or 7 hours downloading. :)

no great rush as i wont get to spend the hours needed to properly look at this until probably sunday.

[Nic]

@dgz: I'm hoping to cut that fade part and test again, so I can make a small test file that can be given to the ffmpeg guys so they can try and fix it. (If possible). But illness and time has been against me.

[dragongodz]

well had a play today. downloaded and installed msys etc to save hassles recompiling with cygwin etc.

compiled 0.61 fine. cool, no headaches like some previous versions. :D

thought ok i will add some different settings options for testing with that clip , so onesoul and/or Nic can test that is since i dont have it.

hmm thought what the hell may aswell make some other gui changes aswell i wanted to do at the same time. now thats where the troubles started. talk about a pain in the @$$ moving controls from 1 window to another. miss 1 little bloody reference and error city. then try adding a new control and making sure its functional when opening the window throws an error so you cant even see the bloody control. this is going to take a little longer than planned.

ok very few people will be interested in any of that but hey just letting people know things are happening....slowly. ;)

[feedback]

@Nic
Take some antibiotics and maybe use an Advair Diskus for chronic breathing problems. Doom9 needs you around.

Regards,:)

[zilog jones]

I'm confused again -_-

I tried encoding two 40 minute videos (PAL 16:9 progressive), with 2-pass 7000kb/s VBR (high quality, trellis quant, max 8200), and they ended up at 794 and 862MB... I was expecting them to be *a bit* bigger!

It encoded the entire videos though, and the amazing thing was that they were quite watchable even though the resulting bitrate was bordering on SVCD quality :eek:

(It's 0.61 by the way)

[vlada]

I also got an undersized encode. It should have 4 GB (6200 kbps, VBR) but ended with 5000 kbps. Could it be because the source is B&W? Also I set the max. bitrate to 8500, but it was 9800 (according to Muxman). I did it using 2-pass encoding.
With 1pass it is even worse. I know it's hard to keep the average bitrate right, but the encoder shouldn't go over the max bitrate, which happens very often. It causes a choppy playback on standalone players although it plays fine on PC.

[zilog jones]

I could see how b&w stuff can compress well, but my videos were full colour! -_-

Edit: Aaag! It happened again. I tried 6992kb/s just to be paranoid and use a mod 16 number (god knows if it makes any difference), but it ended up around 800MB again...

[zilog jones]

I tried again with 1-pass CBR this time and it worked fine. What's the dealio? (remind me never to use that word again...)

[Nic]

The two pass code is undersizing alot of the time. I don't know why, just moved out of my house for a while and don't have a computer at my girlfriends so can't do any testing for a bit. So i'll be a bit quiet. Hopefully Koepi and Dgz can look into it till i'm back into a normal routine.

@feedback: Antibiotics didn't touch it....And I'm allergic to penicillin, so I don't get much choice. Never heard of Advair Diskus.....

[dragongodz]

well i may just ditch making all the gui changes for now then. its slow and painful finding and adding or moving every little reference etc etc etc.

will have a bit of a play with RC tommorow then. :)

Antibiotics didn't touch it....And I'm allergic to penicillin, so I don't get much choice.
nasty. hope you start to feel better soon.

[Teegedeck]

Get well, Nic! Scientific progress waits for you. :)

[mean]

My guess is that the correction due to VBV enforcement is confusing xvid rate control.

[dragongodz]

well i tried changing different settings such as the curve compression and overflow values etc but none made any difference. so i tested the same clip with the latest avidemux(avcodec with xvid RC) and got even worse undersizing. so the problem is definatly in the imported RC.

[Mug Funky]

if it helps, one thing i've noticed with xvid's rate control is that it undersizes if you give it a noisier source. and it seems to undersize in proportion to the amount of noise added. filesize is spot-on if the source is really clean.

i'd imagine an mpeg-2 codec would be fed noisier sources than xvid would, so maybe the problem is showing more.

however, i haven't tested this out on quenc yet. just throwing an idea into the mix (i've no computer at the moment, but i'm getting a new one saturday :))

get well soon, nic :)

[zilog jones]

Hmm, well my source was pretty clean (HDTV-sourced XviD i think, just Lanczos4resized to PAL D1), so I'm still confused -_-

[feedback]

@feedback: Antibiotics didn't touch it....And I'm allergic to penicillin, so I don't get much choice. Never heard of Advair Diskus.....

@ Nic
Try Cipro an anti-biotic not related to penicilln.

Advair Diskus is for people with major breathing problems ie. COPD. Asthma and enphysema are types of COPD.

Regards,:)

[Koepi]

OK, I'm currently looking at the QuEnc sources and might have found some things which have to be tuned to produce non-undersized files.

The default values which are defined in ADM_xvidratectl.cpp should be looked at:
#define DEFAULT_KEYFRAME_BOOST 0
#define DEFAULT_OVERFLOW_CONTROL_STRENGTH 10
#define DEFAULT_CURVE_COMPRESSION_HIGH 0
#define DEFAULT_CURVE_COMPRESSION_LOW 20
#define DEFAULT_MAX_OVERFLOW_IMPROVEMENT 10
#define DEFAULT_MAX_OVERFLOW_DEGRADATION 10

/* Keyframe settings */
#define DEFAULT_KFREDUCTION 20
#define DEFAULT_KFTHRESHOLD 1

also the default "compressability" assumptions for different frame types should be closer investigated, those values hold true for XviD (those might even not be general for MPEG4):
#define INVARIANT_HEADER_PART_IVOP 1 /* factor 1.0f */
#define INVARIANT_HEADER_PART_PVOP 2 /* factor 0.5f */
#define INVARIANT_HEADER_PART_BVOP 8 /* factor 0.125f */

So i suggest the following values (or a new setup window where we can tweak those values for checking out the correct ones):
#define DEFAULT_KEYFRAME_BOOST 0
#define DEFAULT_OVERFLOW_CONTROL_STRENGTH 10
#define DEFAULT_CURVE_COMPRESSION_HIGH 0
#define DEFAULT_CURVE_COMPRESSION_LOW 0
#define DEFAULT_MAX_OVERFLOW_IMPROVEMENT 4
#define DEFAULT_MAX_OVERFLOW_DEGRADATION 9

/* Keyframe settings */
#define DEFAULT_KFREDUCTION 20
#define DEFAULT_KFTHRESHOLD 1

(the overflow settings 10/4/9 are from Jon.Schaffer who tested those values to be superiour to our defaults. I didn't check whether this is true, but might be a good start. Also, asymmetric curve compression is tricky - don't use that :) ).

For finding good values for the I-, P- and B-VOP invariant part of the frame we need statistics about the frame sizes, more precisely about the motion vector size and texture data size.

Looking at a stats-file generated with the new ratecontrol, I find this:
i 2 0 0 0 5108 0
p 2 0 0 0 439 0
b 2 0 0 0 1067 0
b 2 0 0 0 1061 0
p 2 0 0 0 735 0
b 2 0 0 0 1086 0
b 2 0 0 0 1081 0
p 2 0 0 0 810 0
[...]
So you can see the invariant part which gets calculated will be...hm. Dunno if it's the whole frame size or 0 ;) So the rate controller is quite ineffective this way, you need to spit out mv-data, texture-data and total size (not sure about total size anymore, but we need to know the invariant size to properly scale with xvid's RC).

So much for this post, need to get compiler up and running on my machines so maybe I can do something about it in "binary". :-)

I hope this helps!

Cheers
Koepi

[Nic]

Interesting :) Yup, post a binary so people can try it out.

The assymetric was used to help low motion scenes which were getting very blocky and using low bitrate. It did help, I don't think it harmed the ratecontrol too much, but we will see :)

Thanks :)

-Nic

[Koepi]

I've still troubles setting up my systems with the whole platform sdk and cygwin. If you could do the necessary changes (most important is only the splitted mv-data/texture-data part) it would be nice. (I have to go to the city now, joining my GF, have something to lunch,... will take a while. Also I'm quite busy with some documentation I have to write for my new job.)

Cheers
Koepi

[Nic]

@Koepi: I'll try. Been a hell of a time for me. Had an argument with my mother, so I stormed out my home, now living between my girlfriends and my work colleagues (neither of which have a computer I can use). Looking for a new house + a new job and work is crazy busy (although I get to go to new york for a week soon all paid for by work. woo hoo).

i.e. I'm pretty busy myself for a while.

Take Care,
-Nic

[dragongodz]

hmm and i have been trying to put on a new roof. got it 3/4 done but weather has been off and on so only getting a bit done at a time. :)

anyway, for those wanting to test they can go here
http://www.pcpages.com/dragongodz2/
and download the 0.61 testonly archive. try the exe in that on some of the badly undersizing sources and see if it atleast helps.

[Koepi]

dragon: thank you for the efforts put in there! One question: did you just change the settings or did you split the stats data properly into texture bits/mv data bits?

Cheers
Koepi

[lithoc]

Thanks.

I've encode few video clips.

dragongodz's version of 0.61-test create huge file. Mostly encode B-frames at quant 2.

The speed also slower that Nic's build.

:p


Hope it get fixed soon.

[Koepi]

Hehe, dragongodz' overflow control strength is way too small for my taste, it's 1. It should be at least 5, with 1 it could be possible to accumulate very much over-/underflow and maybe being not able to compensate it over the whole clip/movie.

(The value is in percent [of the frame size] and means, how much of the frame size can be taken away/be added to compensate for over-/underflow.)

Cheers
Koepi

[dragongodz]

dragongodz' overflow control strength is way too small for my taste, it's 1
DOH! i swear i pressed 0 aswell, so it should have been 10.

One question: did you just change the settings or did you split the stats data properly into texture bits/mv data bits?
this is just where i have been playing with some settings etc. as such its probably a bit messy and hardly optimal or tested as much as it needs. it still should be ok though for people to test if these changes are making any noticable differences. ;)

new version up with 1 to 10 change, same link and name. ONLY FOR TESTING PURPOSES.

[mean]

Interesting informations, Koepi.

The infos needed by xvidrate control of 1.x seems to be #of intra blocks, # of inter block and header length.

Those informations can be added/extracted to/from lavcodec with tiny patches in mpegvideo.c

Do you think the root of the issue is there ?

--edit spelling

[Koepi]

mean:

yes, that's very likely. The # of intra/inter-blocks isn't necessary, that's just some info we gathered for historical reasons.

I'll look into mpegvideo.c now and will see what I can do.

Cheers
Koepi

P.S.: just looked into mpegvideo.h and saw that everything is there already...

typedef struct RateControlEntry{
int pict_type;
float qscale;
int mv_bits;
int i_tex_bits;
int p_tex_bits;
int misc_bits;
uint64_t expected_bits;
int new_pict_type;
float new_qscale;
int mc_mb_var_sum;
int mb_var_sum;
int i_count;
int f_code;
int b_code;
}RateControlEntry;

[mean]

Now i'm lost
From source :

fprintf(rc->stat_file, "%c %d %d %d %d %d %d\n",
type,
stats->quant,
stats->kblks,
stats->mblks,
stats->ublks,
stats->length,
stats->hlength);

So quant, size, type, interblock, intrablock, skipped block, headerlength

If the 3 block related are not needed, the only remaining factor is headerlength
In the case of DVD like mpeg2, i would thing it is neglectable as the length is huge.

[Koepi]

I still think it _can_ be the missing header length. Unfortunately I still don't have a cygwin environment up and running for ffmpeg, else I'd dig deeper into that.

I think that the different defaults in DGZ's test-binary might be helping the problem already. So we should test that first.

Cheers
Koepi

[video_magic]

I hope it's okay to report a SUCCESS :D

I have just finished endcoding a series of XViD clips to mpeg2 for DVD with QUEnc v0.61 , and this version works great for me, as far as rate control and quality are concerned.
I have just finished MPlexing' them and NO under-runs detected, the file sizes had all been as expected. Impressive! :thanks:

Their was only one slight hitch with an avisynth exception error on one clip, but I uninstalled Avisynth v256beta4 and installed Triticals 20th July 2005 newer version and then that problem disappeared. QUEnc its' self worked like a joy.

[dragongodz]

I hope it's okay to report a SUCCESS
of course.

I have just finished endcoding a series of XViD clips to mpeg2 for DVD with QUEnc v0.61 , and this version works great for me, as far as rate control and quality are concerned.
which exact version sized ok, Nics or my modified ?

[video_magic]

It has the file date modified 22nd 05 2005.
In the titlebar it says QuEnc 0.61 - By Nic - Using libavcodec

I think I downloaded it from the link in the first post, I had got caught up using Hank315s' HC encoder for a while (which also seems to work very well), so I forget for sure. I just went back through this thread and saw your link to a testing version, that link doesn't have the content anymore but I don't think this QuEnc was got from there.

Anyway, I am very happy. Here are the settings:

[jeffoz1]

I was wondering if it is possible to switch off the audio encoding in Quenc .61 and just encode to m2v? I'm probably having a bad day and can't see how you do this. Been using a much earlier version.

Thanks
Jeff

[video_magic]

Yes, I do this. It is done through the avs input file.
This is mine, the false specifies no audio.

AviSource("D:\atmp\pat\clipped\pat3x08(CLIPPED).avi", false)
LanczosResize(720, 576)
ChangeFPS(25)

:) Read more about this at www.avisynth.org begin your search with avisource

[Nic]

@jeffoz1: It isn't very well labeled, but you can do it from the GUI. In the Advanced Options goto the "MPEG-2 Mux profile" Drop down list and select No Audio. That should do it.
(The output filename will still be suffixed with .mpg but it will be a .m2v)

Hope that helps :)

-Nic

[jeffoz1]

Thanks guys. I will only need it occasionally. With the audio encoding and the simple authoring tool this is such a neat little package Nic. Hope new job going well (and you've made up with your Mum :) )

Regards
Jeff

[dragongodz]

your link to a testing version, that link doesn't have the content anymore but I don't think this QuEnc was got from there.
yes the servers hds crashed and content was lost. so i will have to re-setup the page some time. since nobody seemed interested in bothering to test it i dont see the point in rushing.

also i have had 1 of my hd completely die, its been going for some time, so have had to replace it. so just have to get it all back sorted etc before i can do much.

[video_magic]

I would like to help with testing. I am very much an amateur but maybe I can give results from simple tests that would be useful, and give other feedback.

Sorry to hear about your HardDrive failure, I hope you didn't lose too much. I've been gutted a couple of times to lose a lot of data that was important to me :(

[dragongodz]

I would like to help with testing. I am very much an amateur but maybe I can give results from simple tests that would be useful, and give other feedback.
i thought the people that experienced undersizing, reproducably, would have been interested in testing but as you can see from the replies here i was in obvious error. i will get it set back up sometime soon though.

Sorry to hear about your HardDrive failure, I hope you didn't lose too much. I've been gutted a couple of times to lose a lot of data that was important to me
well it was about 5 years old and used a lot so not terribly surprising. it was nice that it died slowly(reading speed kept getting slower and slower each week) so i knew beforehand to move all critical stuff off it. so really its just a matter of setting things back up on the new drive from all the backed up files etc. just time consuming and boring. :)

[dragongodz]

ok my page has been restored by the server. so the undersize test version is there if anyone is interested to see if they can make it undersize or oversize etc.

[Mug Funky]

hmm. not a related issue (or is it?), but has anyone noticed the last GOP of a 2-pass encode gets hit way too hard? bitrate view (and eyes) clearly show this. it'll go from quant 1 to quant 8 or more very sharply.

also, min quant for b-frames seems to be locked at 2 for 1-pass encodes... this is probably a good idea though. just means 1-pass encodes will undersize if the avg bitrate is higer than 5000 or so.

btw, DGZ - good to hear you didn't lose data. that sucks so bad when it happens (most of my data loss is from physically losing discs... but i've had dead disks before).

[freelock7]

Too much oversized with the Q061 DGZ modified version!
Bitrate=5424 (with a setting VBR=4000 )

[dragongodz]

min quant for b-frames seems to be locked at 2 for 1-pass encodes... this is probably a good idea though. just means 1-pass encodes will undersize if the avg bitrate is higer than 5000 or so.
yes this was done to help with the underflowing etc. depending on the source etc you can still encode over 10000kbs so undersizing is more complex than just the B frames.

Too much oversized with the Q061 DGZ modified version!
thanks freelock7. i actually had another report from a freind who got an undersize(4.03gb output when target was 4.36gb). so i think i will make some different changes and see what that does. probably wont have time until sunday though.

[shirohamada]

got this nasty artifact
source
http://img17.imageshack.us/img17/6418/27fk.th.jpg (http://img17.imageshack.us/my.php?image=27fk.jpg)
encoded
http://img145.imageshack.us/img145/4733/16zq1.th.jpg (http://img145.imageshack.us/my.php?image=16zq1.jpg)

settings,
Q2 1pass 6of9 matrix DC 9 extreme&slow high quality trellis auto bitrate and scene detection.

for now it occurs with high bitrate. q2 default matrix looks fine.

happens during really high motion scene

here's the b0rk encoded clip
http://rapidshare.de/files/3916758/Copy_of_hagaren_17.m2v.html

[akiza]

Audio Question about 2 PASS ...

When encode in 2 pass mode, will the Audio encode 2 times ?

Or only encode once ?

and

Is there any guide / doc about [MPEG-2 MUX PROFILE] ?

THANKS..

[Nic]

@akiza:
"When encode in 2 pass mode, will the Audio encode 2 times ?"
Yes, I think so. The MP2/AC3 encoder is quite simple and fast so it doesn't really slow it down that much, but I suppose it isn't optimal.

"Is there any guide / doc about [MPEG-2 MUX PROFILE]?"
Hopefully it should be pretty self explanatory. If not ask any question you want and i'll try and answer it.

@shirohamada: Weird artefacts have been known to occur. I think it's a bug in the motion code in FFMPEG.
I mainly believe this because:
1) If you turn off the motion comp/est code then those artefacts tend not to occur
2) If you turn off the motion comp/est code the quality of the video doesn't really get much worse?!!

I think I'll add a switch so people can test the codec with motion on and off and see what happens. Maybe DragonGodz can do that with a release :wink: :nudge: :etc: ;)

-Nic

[dragongodz]

actually those artifacts look like the trellis bug to me. shirohamada can you try again but this time disable trellis and slow and extreme and see if it happens then ?

Weird artefacts have been known to occur. I think it's a bug in the motion code in FFMPEG.
yes but we have not seen anything major like that.

I think I'll add a switch so people can test the codec with motion on and off and see what happens. Maybe DragonGodz can do that with a release :wink: :nudge: :etc:
well i was thinking of re-enabling something like PHOD in the avcodec source(commenting out where parts are disabled) and and having the option for selecting it to see what happened. more interested in getting RC working better first though. ;)

[akiza]

@ Nic

Thanks for your answer. ..^_^

One more newbie question:

Is it possiable to make Quenc a AVS-> AVI convert ? ^^

[Koepi]

more interested in getting RC working better first though. ;)

Hi,

I don't know if I already reported back, but the issue isn't solved with your test-versions. It seems you really need to fill the structs for frame size, motion bits and texture bits to make the RC work correctly. I didn't succeed in my (short) try to do that myself, the structs were too complicated to be understandable in half an hour :)

I'd appreciate if you could try to do that!

Cheers
Koepi

[mean]

_context->me_range=255;

is important for mpeg2 to create 100% compliant stream, it may be the cause of the artefact depending on how strict the decoder is.

[Nic]

@Mean: The me_range should be fixed to a restricted boundary in all recent builds of QuEnc. So that shouldn't be the problem hopefully.

[shirohamada]

actually those artifacts look like the trellis bug to me. shirohamada can you try again but this time disable trellis and slow and extreme and see if it happens then ?

and i'm cured
both trellis and extreme are the culprit
though i get a 17% in filesize increase
a little bit more ringing after zooming 300%
and gain of speed ;)

thx all

[Shernand]

Hi to all,
I've just begun using QuEnc and i'm using version 0.61, as i see above there are settings that can make artifacts to appear, i'm trying to encode anime at 1500 kbps, could anyone tell me the best quality / safe (no artifacts, compatible with all DVD players) settings based on the source i have and the bitrate given?

Thanks in advance and br,
Shernand

[Sagittaire]

QEnc (and libavcodec) make MPEG2 DVD compliant stream ... ???
Yes or Not ... ???

[Nic]

@Saggitaire: Yes they do. The compatability from libavcodec has a got a lot better over the last year or so due to some good patches.

@Shernand: Don't use Trellis or "Extreme Settings". Also use the correct GOP size for the format (be it PAL or NTSC) and a maximum of 2 B-Frames. And that should be all you need for good compatible streams. (AFIAK)

-Nic

[Sagittaire]

@Saggitaire: Yes they do. The compatability from libavcodec has a got a lot better over the last year or so due to some good patches.
-Nic

thank you very much

very good work for your encoder ... QEnc is certainely the best encoder available with multipass encoding (buggy in mencoder and FFDShow).

Libavcodec with best setting (RDO, chroma ...) seem produce better quality than your best setting ... why not an "insame quality mode" in QEnc for the next build ...

Vive QEnc ... !!!

[Shernand]

Nic -> Thanks for your recommendations, Quenc is the best free mpeg-2 enconder (at least for me) ;)

Now, i have this avisynth script :

----------------------------------------------------------------------
LoadPlugIn("C:\Archivos de programa\AviSynth 2.5\plugins\ffavisynth.dll")
AVISource("C:\Anime\File.Avi")
ffdshow("default")
ffdshowAudio("default")
ChangeFPS(23.976)
BilinearResize(720,480)
------------------------------------------------------------------

I use changefps due that if i leave the 24 original fps in the avi file, pulldown doesn't work.

Note, i use ffdshow since i like the postprocessing options ;)

At the very end of the enconding (2nd pass) qenc closes itself without saying anything and i get a incomplete file, any tips to fix this?

Br,
Shernand

[dragongodz]

It seems you really need to fill the structs for frame size, motion bits and texture bits to make the RC work correctly. I didn't succeed in my (short) try to do that myself, the structs were too complicated to be understandable in half an hour
yes this is one of the things i am looking at. ;)

QEnc (and libavcodec) make MPEG2 DVD compliant stream ... ???
Yes they do. The compatability from libavcodec has a got a lot better over the last year or so due to some good patches.
well really its yes, the majority of the time. sometimes you may have to set max bitrate a bit lower because libavcodec can still spike rather badly. sorry to nitpick. ;)

Libavcodec with best setting (RDO, chroma ...) seem produce better quality than your best setting ... why not an "insame quality mode" in QEnc for the next build ...
QuEnc does already have an "insane&extreme" mode that turns on a lot of things. it also comes with a nice big speed hit of course.
also the latest versions of QuEnc do not use libavcodecs ratecontrol. so comparison to other libavcodec based programs(except avidemux by mean) is not exactly correct. the change in ratecontrol is to try and produce more consistantly compliant streams. meaning no spiking or underflows etc etc etc which libavcodecs ratecontrol still can do.

[Shernand]

Nic -> sorry about this, just tested again and it worked! :) :) :)

[danpos]

@Nic and/or dragongodz

I did see some post where you comment about OPV at constant quantization mode. So I thought that I could set up a Q parameter like is done in NuEnc, TMPGEnc... but I didn't see such parameter in interface and window's registry either. I'm blind or what? How do I set Quenc up for to do OPV at constant quantization ?

Cheers,

[Koepi]

QuEnc does constant quantizer when setting the bitrate between 1 and 32 -- which then is the quantizer used for the encode.

Cheers
Koepi

P.S.: Thanks for still looking into this dragongodz :)

[freelock7]

It would be fine Nic to encode in constant quantizer with a max bitrate setting -for the DVD compliance-like HC015.
The 1Pass encoding would be improved. I think.

[dragongodz]

Thanks for still looking into this dragongodz
no probs mate. ok well except for having to try and learn the Xvid RC and only doing it in small time blocks instead of all at once etc etc etc. :)

It would be fine Nic to encode in constant quantizer with a max bitrate setting -for the DVD compliance-like HC015.
it would be nice to have 2 pass VBR working 100% first. then maybe 1 pass VBR and CBR. THEN maybe max bitrating CQ. but thats just my preference. ;)

[danpos]

@koepi

Thanks for clarifying me up about CQ (constant quantization) encoding in QuEnc!! http://www.geocities.com/pcdanpos/smilies/thumbsup.gif

Cheers,

[Sagittaire]

... avcodec DOES NOT create compliant MPEG2 files.
The developers of avcodec acknowledge it, and it's clearly documented in their documentation. And we can testify to that.
QuEnc is just a front end to avcodec. Nothing more :!:
No matter what QuEnc does, FreeEnc does, NuEnc does, the final product is the same ...

-kwag

who say true ... ???

How to check the real compliance of MPEG2 stream ... ???

IMO QEnc is DVD compliant (work with all my hardware player) but everyone is far from being convinced of it ... !!!

[Nic]

@Sagittaire: It is compliant. To the best of my knowledge. Once upon a time it wasn't, but several patches made it a lot better. Also it depends on what part you mean. The actual M2V data or the VOB muxing. If people aren't convinced, they should tell me why and i'll fix it.

-Nic

[Sagittaire]

Only m2v file ... I export it with ifoedit or other ... !!!

but it's clear... I will pass the message ... lol

[dragongodz]

as i already said libavcodecs rate control can spike occasionally past max bitrate. now if you set max bitrate to a very high amount, such as 9400 and allowing 448 for ac3 audio, and it spikes past the 9400 to say 9700 for example you have a problem. that is when you go to author the m2v and ac3 you will get an underflow error message, basically saying the bitrate is too big for dvd compliance. that is why i said you sometimes have to set max bitrate a bit lower. its also why QuEncs output may be slightly different than other libavcodec encodes, the settings used try to reduce spiking. finally that is also why the change to using Xvids rate control with QuEnc, to try and get a better, more consistant, rate control.

of interest also may be the fact that even CCE has had reports of spiking slightly over max bitrate with just 2 pass encoding. thats one of the reasons jdobbs changed max bitrate to 9000 minus audio and subs with DVD-Rebuilder. i can search for the old thread if you need it.

[Sagittaire]

as i already said libavcodecs rate control can spike occasionally past max bitrate. now if you set max bitrate to a very high amount, such as 9400 and allowing 448 for ac3 audio, and it spikes past the 9400 to say 9700 for example you have a problem. that is when you go to author the m2v and ac3 you will get an underflow error message, basically saying the bitrate is too big for dvd compliance. that is why i said you sometimes have to set max bitrate a bit lower. its also why QuEncs output may be slightly different than other libavcodec encodes, the settings used try to reduce spiking. finally that is also why the change to using Xvids rate control with QuEnc, to try and get a better, more consistant, rate control.

Yes I understand ... for example 9000 for max bitrate can be very better for DVD compliant stream ... and IMO I think QuEnc produce DVD compliant MPEG2 Stream.

but Kwag, Dialhot, incredible and other in this forum (http://www.kvcd.net/forum/index.php) seem to think the opposite (perhabs bad feedback with hardware player ... I don't know)

it's perhaps interessant to see the problems which they have with QuEnc because they seem to have good competences in MPEG2 encoding ... ???

[Nic]

Read the Pioneer DVR-220 problem from that forum. Using FreeEnc he had issues, when he redid it with QuEnc he didn't. Anyway, it doesn't matter what they think. I never care for opinion. Someone provide me with a make and model of a DVD Player that doesn't like QuEnc produced files and i'll fix it. Until then, people can use what ever they wish. :)

"it's perhaps interessant to see the problems which they have with QuEnc because they seem to have good competences in MPEG2 encoding ... ???"
In the words of Daffy: "That, my little cherub, is strictly a matter of opinion".

-Nic

[shirohamada]

do you think Q1 is a waste of space ?
you can see the difference if you zoom enough...

[dragongodz]

and other in this forum
Sagittaire - that forum is a pay to join one now. some of us wont waste our money so have no idea what they are saying. if they think there is a problem and can give information about it they know fully well this is where to report it. if they do not choose to then they really dont have anything to complain about period.

do you think Q1 is a waste of space ?
in what way? you need to provide more information so people know what you exactly mean.

you can see the difference if you zoom enough...
do you normally watch movies zoomed right in ? :D

[Axed]

do you think Q1 is a waste of space ?
you can see the difference if you zoom enough...

Its never a waste to have a Q1 option! There are sometimes needs for quality without the boundries of space. But, for real use, if it works the same way as XviD you wont see a difference between Q1 and Q2. If this is wrong, someone please correct me.

Nic and dragongodz thanks for the work on QuEnc, been playing with it making SVCD's of home movies and it doesnt spike anywhere near as much as i found NuEnc and FreeEnc did. All my SVCD's have come out exactly sized as i wanted them to so far. Great programs the lot of them, just those bitrate spikes on NuEnc and FreeEnc hurt when you cant go above a certain limit to stay inside specs.

[shirohamada]

i think dark scenes could use the quality boost.
but dark scenes are meant to be compressed...

[freelock7]

Pixels in dark scenes appear when bitrate is too low. That was the main problem with this new RC partially corrected by Nic for the final release -but not perfect.
[What about the curve compression for low motion scenes, Nic -or DGZ?]
BTW I tested once again the QuEnc061-DGZ test on <The flight of the Poenix> .
Avg=4800 (against 5200 for the correct size).
It's still undersized but better than the official Q061 .
Possible underquantization problem (not tested on DVD player yet).
Muxing with Ifoedit: no underflow.

[DarkFoon]

Can I request a feature for Quenc here? Or does that go elsewhere?

[dragongodz]

sorry its taking so long. i have a lot on my plate at the moment and finding time to spend a couple of hours actually sitting infront of the pc is a bit hard. i will get there though.....eventually. :)

Can I request a feature for Quenc here? Or does that go elsewhere?
there is an actual requests thread
http://forum.doom9.org/showthread.php?t=85039
so you may want to read that incase your request has already been asked.

[Mug Funky]

Yes I understand ... for example 9000 for max bitrate can be very better for DVD compliant stream ... and IMO I think QuEnc produce DVD compliant MPEG2 Stream.

yeah. just because DVD allows video to go that high, doesn't mean it should.

after lots of testing (and lots of complaints from fans with playback issues on the madboards), madman use a max of 8500 for everything - and this is with spruce mpx3000 encoder boards which are designed specifically for DVD (they don't go higher than 9600).

[john3voltas]

Anyway, it doesn't matter what they think.
Of course it doesn't Nic...and that'd explain why you haven't show up there for so many time...
I never care for opinion.
I can see why...
But I'm also a "facts" guy just like you.
Someone provide me with a make and model of a DVD Player that doesn't like QuEnc produced files and i'll fix it.
Just tried a 16:9 Anamorphic encode with QuEnc on my AG DVD Player-336K and caput -> choppy playback all over the place!
Sometimes the movie even stops for 1 second and I get a frozen image with a lot of big 16x16 squares of flashing colors.
And then the choppy playback will resume for a couple of minutes.
It would look like an authoring problem right?
But I'm still using DVDLab, the same that I have used for a looong time.
To proove that this had anything to do with QuEnc (or libav) I took my testing CD and DVD with KVCD and KDVD small clips mostly done with Tmpgenc and CCE.
And all is working ok with these other CDs and DVDs.
I know! Let us all blame it on the KVCD matrix...right?
It's just too damn easy isn't it Nic?
Until then, people can use what ever they wish. :)
Of course we can Nic and that's why I've never used QuEnc (or any libavcodec based encoder) on a regular basis.
On the other hand I have been using HCEnc on a regular basis for quite some time and it's been working fine with all the DVD players I could find on all the TV/HiFi stores around here.
"it's perhaps interessant to see the problems which they have with QuEnc because they seem to have good competences in MPEG2 encoding ... ???"
In the words of Daffy: "That, my little cherub, is strictly a matter of opinion".
Of course it's always a matter of oppinion when it comes from anything starting with K, right? :(
From here you will tell me that I have broken hundreds of D9 forum rules and that I need to go :readrule: again, right?
But I couldn't help answering your clear K remarks ;)

[dragongodz]

at the risk of a warning or strike i have to answer that. :scared:

Just tried a 16:9 Anamorphic encode with QuEnc on my AG DVD Player-336K and caput -> choppy playback all over the place!
and what settings did you use ? how did the files play from HD ? can you provide a small sample so people can reproduce and/or examine the problem ?

I know! Let us all blame it on the KVCD matrix...right?
no, why dont you provide some real information so that people can try and help determine what is the problem you are having. besides what the hell has Nic saying QuEnc can produce dvd compliant files got to do with that matrix ? nothing so try reading before spouting off.

It's just too damn easy isn't it Nic?
to be a dick that isnt really interested in help ? pretty clearly it IS damn easy for you. :devil:

[dragongodz]

oh and Koepi, i tried to add the header size in etc for the RC, man what a mess, but i screwed it up. it kept crashing. so i think i will delete the whole folder and start from fresh when i can.

at the moment(last 3 weeks actually) there have been some serious family happenings going on which take precedent over this. as soon as things steady down(hopefully they will) i will get back to it.

[john3voltas]

at the risk of a warning or strike i have to answer that. :scared:
Can't see why...

and what settings did you use ? how did the files play from HD ? can you provide a small sample so people can reproduce and/or examine the problem ?

OK, here goes nothin':

Avisynth script
-----------------
Mpeg2source("D:\CATWOMAN\D2V\cat.d2v")
LanczosResize(704,432,4,74,712,426)
RemoveGrain().Deen()
AddBorders(0,72,0,72)
Letterbox(72,72,16,16) # To achieve an overlap overscan of 2
Slicer(2,15,2,"ping") # Incredible's slicer function similar to selecrangeevery

Slicer.avsi
----------------
function slicer(clip input, int percent, int Goplenght, int Gopmulti, string "ping")
{
PercCount = (Framecount(input)/100)*percent
period = int(Framecount(input)/PercCount)*(Goplenght*Gopmulti)
input=(ping == "pong") ? input.trim((period/2),Framecount(input)):input
selectrangeevery(input, period, (Goplenght*Gopmulti))
}

QuEnc 0.61 settings
--------------------
Mpeg-2 - check
Bitrate (Kbps) - 2500
Use VBR - check
High quality - check
Use Trellis Quant - check
Extreme slow settings - check
GOP Size - 15
Max B frames - 2
Force closed GOP - check
16:9 Aspect ratio - check
DC Precision - 10
Max bitrate (kbps) - 8000
Load custom Matrix - C:\VIDEO\QuEnc\KVCD_Notch_matrix.xcm

The KVCD_Notch_matrix.xcm has been done using Leigh's wonderful matrix editor and has no corruption as it has been used in other encoders without any issues.
Playing from HDD with MPC v6.4.8.4 or VLC v0.8.2 both the M2V and the VOB files presented no problems at all.
Sorry but no small clip. My webspace is very limited...

no, why dont you provide some real information so that people can try and help determine what is the problem you are having.
Because I would bet a whole lot of money in that the problem lies in libavcodec.
Do I smell a lot of buffer underflows? :p
But you're the expert in this matter, so try to figure it out.

besides what the hell has Nic saying QuEnc can produce dvd compliant files got to do with that matrix ?
That's usually the excuse for people that post here with K issues found in D9 encoders...

to be a dick that isnt really interested in help ? pretty clearly it IS damn easy for you. :devil:
Wrong!
I have always tried to help anybody that asks if it is inside my knowledge domain.
All the above post by me was "a message to Nic".
In such sense there was no special reason for an answer coming from you.
In fact you are the usually the boring dick that spends all the time kissing Nic's butt for no apparent reason.
But you are a cool dick, and especially one that tries to help ;)
And that's why I elaborated a bit more than I would usually do, on the settings that I used in QuEnc.
You know this is a public forum and you have the right to answer anything that is posted here even if it's not addressed to you.
You did answer to my post when it wasn't addressed to you and I answered Nic's post when it was not directly addressed to me.
But by being a public forum, and since Nic is a Mod here, he might have been able to choose a more appropriate way of refering to kvcd.net.
But then again, why would he choose more appropriate words when D9 himself speaks as highly of kvcd.net as he does...
At kvcd.net there is no big reason for loving D9 forum, but we acknowledge and respect what is accomplished in here.
Sometimes we would like to see the same coming from here but it's just too damn hard for some of the big shot develppers in here, some that even are (or were) kvcd.net users, to understand that people have the right to choose.
Just by choosing to use K methods, one should not be seen as a hobo or an outlaw.
Look at Prodater64 here (http://forum.doom9.org/showthread.php?p=682007#post682007).
He is a cool guy. He developed a tool that is in fact very interesting and he posted it in July.
Do you know who else posted there and cheered Prodater64 for his work to the community? Zyphon, a really cool guy that is registered both here as well as in kvcd.net and some other video encoding forums.
Why do you think that happens DGz? Why do you think the same has happened with so many other kvcd users, for instance VMesquita?
VMesquita only started to take credit for his work here after he built his own forum...Now, what a coincidence!
So see it this way: my problem was in how Nic addressed to us, and since he says that he doesn't care about oppinions, I don't think he will be bothered with mine on this subject ;)
But anyway thanks for caring about what the issues with QuEnc, that is, with libavcodec.

[DarkFoon]

less drama, more development please :D

[Nic]

@john3voltas: An interesting post. Apart from your obvious anger and venom, you could have a good post.

I have no problem at all with the kvcd matrix, or the forum itself. Myself and kwag seem to get on fine too. My problem is that all I get when told libavcodec isn't producing good streams is hearsay and rumour. But in this instance you actually gave me a make of DVD player that has a problem. Which no one else has done, so I thank you for that.

I stand by my statements, I don't care for opinion or what people "think", no matter what forum they are from. Only fact and useful criticsm interest me. Your critique was useful because you've given me a DVD player that doesn't work with QuEnc. I honestly can't tell you why that would be though, every verification I can do of the MPEG video from QuEnc seems fine (unless the bitrate spikes). Did it in your case? Which version did you use? Can you do tests again for us to help with the development?

I hope that clears it up a little, I'll be looking into your issue soon.

Cheers,
-Nic

ps
Any more of the use of words like d*ck will result in strikes (this may have already taken place, I've only just come back from being away)

[john3voltas]

@john3voltas: An interesting post. Apart from your obvious anger and venom, you could have a good post.
No Sir, no anger and especially no Venom.
What you may have noticed on my words it's a bit of sadness for the way some things are said or done around here once in a while.
I have no problem at all with the kvcd matrix, or the forum itself. Myself and kwag seem to get on fine too. My problem is that all I get when told libavcodec isn't producing good streams is hearsay and rumour. But in this instance you actually gave me a make of DVD player that has a problem. Which no one else has done, so I thank you for that.
No rumours at all Nic.
I truely believe that libavcodec has the best bitrate allocation algos from all the encoders we have right now.
You can see that with your eyes, no need for special equipment.
And I was truely happy to hear that you had finally moved on to XVID ratecontrol because I knew how buggy libavcodec was in that field.
But unfortunately in my case I have an old player that doesn't like it.
That's all.
Small note: bitrate allocation with HCEnc has seen some very good progress and is very close to what libavcodec can offer.
But that's just MHO.
I stand by my statements, I don't care for opinion or what people "think", no matter what forum they are from. Only fact and useful criticsm interest me. Your critique was useful because you've given me a DVD player that doesn't work with QuEnc. I honestly can't tell you why that would be though, every verification I can do of the MPEG video from QuEnc seems fine (unless the bitrate spikes). Did it in your case? Which version did you use? Can you do tests again for us to help with the development?
I don't have much means of analising the stream encoded by QuEnc 0.61.
All I could do was throw it at bitrateviewer and yes, as usual with libavcodec, I could seem some massive bitrate spikes.
When I say massive I do mean massive.
I mean that it blows up for more than 200 frames up to the 10.000~12.000 Kbps.
But I've seen other encoders doing the same and this old player never had any problems with that.
On the other hand this movie has some pretty long dark scenes and bitrateviewer also shows the bitrate going way below the 100Kbps for several seconds.
But I don't "think" it would have anything to do with that since the choppiness is almost systematic.
But hey, you are much more skilled than me to draw such an oppinion.

ps
Any more of the use of words like d*ck will result in strikes (this may have already taken place, I've only just come back from being away)
Ah! you bet it has already taken place.
Only it was not strikes, instead warnings.
Only thing is such word was used by more than one user and I can only speak for myself...

[dragongodz]

Do I smell a lot of buffer underflows?
doesnt dvdlab tell you if it detects underflows ? try running the clip through muxman or dvdauthorgui or Tmpgenc dvdauthor as they should tell you if this is detected.
actually just for the sake of completness try authoring with one of them and burning the result to a dvdrw(assuming your player plays them) and see if the problems are reproduced. this will rule out dvdlab not liking QuEncs output.

In such sense there was no special reason for an answer coming from you.
actually as the other person who works on QuEnc, infact currently looking at its ratecontrol, there is every reason for me to be interested in any problems. i know it just says "by Nic" in the title bar but what people dont see is a lot of PM's that Nic and i have had over both QuEnc and Rejig(which i also helped with, mainly engine tuning). and no we dont always agree on things but we accept that and continue anyway. believe me Nic is one of the easiest people to work with and thats not kissing up to him. ;)

Sometimes we would like to see the same coming from here but it's just too damn hard for some of the big shot develppers in here, some that even are (or were) kvcd.net users, to understand that people have the right to choose.
my problem is with certain people from that forum that have come here in the past to only flame and abuse rather than ask or give help. yes there are others who post on both forums and i have no problems at all with them. i also am no fan of the fact it has gone to a pay system where you can not even view posts without paying to join first but i do not blame or take that out on users.

bitrateviewer also shows the bitrate going way below the 100Kbps for several seconds.
But I don't "think" it would have anything to do with that since the choppiness is almost systematic.
actually some players(some models of philips and panasonic for example) have been reported as not liking bitrates to drop below about 300Kbps but since its systematic as you say then this is not likely the problem unless it happens at all problem points.

if you can encode a small clip, say 5 minutes worth, and author that and have it still show the problem then that would be good for you doing some testing. if that short is no good then you would have to see how much needs to be encoded to constantly reproduce it for tests.

so lets assume authoring with another program didnt fix the problem, this is what i would suggest trying.
1. disable trellis and extreme settings. encode small clip.
2. disable custom matrix. encode small clip.
3. disable closed GOP. encode small clip.
4. do not filter input(deen). encode small clip.
of course enable the disabled settings for the other encodes to isolate each setting/change.

hmm i just noticed you didnt mention have 2 pass ticked. i assume you are using 2 pass though yes ? 1 pass encoding doesnt use the xvid RC. i plan to work on 1 pass after 2 pass undersizing is fixed or atleast much better.

Only thing is such word was used by more than one user
yes i used it first and am sorry but if you reread your post you should see it can come off rather aggressive and provided no clues to what the problem may be. so yes it irritated me at a very stressful time.

less drama, more development please
yes boss. :D

[Nic]

@john3voltas:
Hmmm. Then I'm guessing it's the bitrate spikes causing the problems with your player rather than any other bitstream problem. I've never seen bitrate spikes like that using the latest version and two pass. Just to repeat what Dragongodz said really, if you didn't use two pass, please try again using two pass mode (this enables the XviD ratecontrol). Without it, you are using libavcodec's ratecontrol, and that would explain the spikes (and hence the problems with your player).

Let us know how you get on, if that's the case :)

-Nic

[Zarxrax]

I have been doing some encodes with quenc, trying to author a dvd in Adobe Encore, and Encore complains that the bitrate is going too high for dvd. I set the max bitrate to 8000, average bitrate to 4500, and there is no audio. The too-high bitrate doesnt seem to occur until towards the very end of the stream though. I've encoded some shorter clips (< 15 minutes) and they didn't have this problem. I am using 2-pass encoding. I dont have trellis or extreme enabled, I'm not using a custom matrix, and I have tried with and without closed GOP.

[Nic]

@Zarxrax: How close to the end of the stream? The very very end (like the last few hundred frames?) Or is it just generally towards the end of the encode. I assume this is with QuEnc 0.61 (?)

[Zarxrax]

Yes, 0.61. One of my files is about 1 hour 11 minutes in length, and Encore says that the too-high bitrate occurs around 1 hour 03 minutes.

Do you know of a tool that can display the max bitrate that is used in the file, so I can see if maybe its just a bug in Encore, or if the bitrate really is spiking?

[danpos]

@Zarxrax

You can to use Bitrate Viewer or alternatively to use a tool present in DVD-Lab Pro.

Cya!

[Zarxrax]

Ok, the peak bitrate of my file went way to high all over the place, not just near the end. The Bitrate viewer in DVD-Lab is saying the peak bitrate is 10230 kbps.

While I am encoding the 2nd pass, it reports that there are many possible overflows. Is that referring to bitrate overflows? At less than 10% through, it already reports 6 possible overflows!

[kwag]

my problem is with certain people from that forum that have come here in the past to only flame and abuse rather than ask or give help. yes there are others who post on both forums and i have no problems at all with them. i also am no fan of the fact it has gone to a pay system where you can not even view posts without paying to join first but i do not blame or take that out on users.

@All

Hi.

Before I get banned, or this post gets deleted, I just hope several people have a good chance to read it and digest it.
If it gets deleted, I'll just repost it in the main public page at KVCD.Net.
I'm sure it will spread worldwide in a matter of hours.
I said to myself a long time ago that I was not going to post at this site anymore, but it seems that I must in order to clear up several comments about me and KVCD.Net.
Since KVCD.Net went to a "pay-once" (dirt cheap $2.99) model for forum access, some people around the net immediately started whining.
Why?, because most sites are free, and don't require any payment, so anyone can join.
Some use advertizing (very bad model in my opinion, unless it's google, CNN or other huge sites ;) ), and others are free for some time, before finally folding up after some time because of not making any revenues to maintain the site.
Well, since this model was put into operation, KVCD.Net has been the cleanest and most joyful site to visit and to talk about advanced video conversion, because the people that join truly want to learn, and the pay model keeps the rats out of the site.
Now, I've been refered here, because specifically dragongotz has made several comments about us, on different occasions, and I'd like to show the community exactly what KVCD.Net does with some of the money that comes in via new registrations.
Below is our PayPal record of some transactions that have been made specifically to the open source community, and some of them with dates that are prior to the time we started the payment registration model. Back then, the money came out of my pocket.



Web Accept Payment Sent (ID # 4B877749NU657345W)

Original Transaction
Date Type Status Details Amount
Feb. 24, 2004 Payment To Laurent DUVEAU Completed ... -$25.00 USD

Related Transaction
Date Type Status Details Amount
Feb. 24, 2004 Transfer From Credit Card Completed Details $25.00 USD

Name:
Laurent DUVEAU (The recipient of this payment is Non-U.S. - Verified)
Email:
laurent@aldweb.com

Total Amount:
-$25.00 USD

Item Amount:
$25.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
Donation to support the GuppY project
Time:
06:59:11 PST
Status:
Completed
Shipping Address:

No Address Provided

Funding Type:
Credit Card
Funding Source:
$25.00 USD - MasterCard Card XXXX-XXXX-XXXX-xxxx
This credit card transaction will appear on your bill as "PAYPAL *LAURENT".

-----------------------------------------------------

Transaction Details

Web Accept Payment Sent (ID # 4A840097MM512301D)

Original Transaction
Date Type Status Details Amount
Feb. 3, 2004 Payment To Jason Rohrer Completed ... -$5.00 USD

Related Transaction
Date Type Status Details Amount
Feb. 3, 2004 Transfer From Credit Card Completed Details $5.00 USD

Name:
Jason Rohrer (The recipient of this payment is Verified)
Email:
jcr13@cornell.edu

Total Amount:
-$5.00 USD

Item Amount:
$5.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
The MUTE Project
Time:
08:38:44 PST
Status:
Completed
Shipping Address:

No Address Provided

Funding Type:
Credit Card
Funding Source:
$5.00 USD - MasterCard Card XXXX-XXXX-XXXX-xxxx
This credit card transaction will appear on your bill as "PAYPAL *JCR13".

Description:
The MUTE Project

----------------



Transaction Details

Web Accept Payment Sent (ID # 11L981748U312622X)

Original Transaction
Date Type Status Details Amount
Feb. 11, 2003 Payment To Videotools.net Completed ... -$25.00 USD

Related Transaction
Date Type Status Details Amount
Feb. 11, 2003 Transfer From Credit Card Completed Details $25.00 USD

Name:
Videotools.net (The recipient of this payment is Non-U.S. - Verified)
Email:
payments@videotools.net

Total Amount:
-$25.00 USD

Item Amount:
$25.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
professional_package
Time:
13:22:19 PST
Status:
Completed
Shipping Address:

No Address Provided

Business Contact Information

Customer Service URL: http://www.videotools.net
Customer Service Email: supportrequest@videotools.net

Funding Type:
Credit Card
Funding Source:
$25.00 USD - MasterCard Card XXXX-XXXX-XXXX-xxxx
This credit card transaction will appear on your bill as "PAYPAL*VIDEO TOOLS".

Description:
professional_package

------------------------------

Jun. 25, 2005
Transaction Details

Web Accept Payment Sent (ID # 2X453905167394053)

Name:
OSDN / VA Software (The recipient of this payment is Verified)
Email:
salexander@valinux.com

Total Amount:
-$10.00 USD

Item Amount:
$10.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
Donation
Invoice ID:
239485
Time:
18:34:49 AST
Status:
Completed
Shipping Address:

No Address Provided

Business Contact Information

Customer Service URL: http://www.sourceforge.net
Customer Service Email: staff@sourceforge.net
Customer Service Phone: 510-687-7181

Funding Type:
PayPal Funds
Funding Source:
$10.00 USD - PayPal Account

Description:
Donation

Note:
Great work Kris :)
And btw, thanks for changing the license to BSD. I'm not very fond of GPL ;)

Thanks,
-Karl
http://www.kvcd.net
-----------------------------

May 4, 2005
Transaction Details

Web Accept Payment Sent (ID # 4H264470XL3323333)

Original Transaction
Date Type Status Details Amount
May 4, 2005 Payment To DVDREasy Completed ... -€5.00 EUR

Related Transactions
Date Type Status Details Amount
May 4, 2005 Currency Conversion (debit) From U.S. Dollar To Euro Completed Details -$6.62 USD
May 4, 2005 Currency Conversion (credit) To Euro From U.S. Dollar Completed Details €5.00 EUR

Name:
DVDREasy (The recipient of this payment is Non-U.S. - Unverified)
Email:
dvdreasy@netcabo.pt

Total Amount:
-€5.00 EUR

Conversion From:
-$6.62 USD
Conversion To:
€5.00 EUR
Exchange Rate:
1 U.S. Dollar = 0.756307 Euros

Item Amount:
€5.00 EUR
Shipping:
€0.00 EUR
Handling:
€0.00 EUR
Quantity:
1
Item Title:
DVDREasy €5 Donation
Time:
02:42:50 AST
Status:
Completed
Shipping Address:

No Address Provided

Business Contact Information

Customer Service URL: http://pwp.netcabo.pt/dvdreasy
Customer Service Email: dvdreasy@netcabo.pt

Funding Type:
PayPal Funds
Funding Source:
$6.62 USD - PayPal Account

Description:
DVDREasy €5 Donation
-------------------------------------------

Mar. 10, 2005
Transaction Details

Web Accept Payment Sent (ID # 6CB399479B321621K)

Name:
Ratajik Software, LLC (The recipient of this payment is Verified)
Email:
sales@ratajik.com

Total Amount:
-$14.99 USD

Item Amount:
$14.99 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
StationRipper-FullVersion
Item Number:
100
Time:
19:28:36 AST
Status:
Completed
Shipping Address:

United States
Unconfirmed Help

Business Contact Information

Customer Service URL: http://www.ratajik.com
Customer Service Email: support@ratajik.com

Funding Type:
PayPal Funds
Funding Source:
$14.99 USD - PayPal Account

Description:
StationRipper-FullVersion

--------------------------------------------------

Feb. 28, 2005
Transaction Details

Web Accept Payment Sent (ID # 2U720486V85903434)

Name:
Laurent DUVEAU (The recipient of this payment is Non-U.S. - Verified)
Email:
laurent@aldweb.com

Total Amount:
-$10.00 USD

Item Amount:
$10.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
Donation to support the GuppY project
Time:
13:18:41 AST
Status:
Completed
Shipping Address:

No Address Provided

Funding Type:
PayPal Funds
Funding Source:
$10.00 USD - PayPal Account

Description:
Donation to support the GuppY project
-----------------------------------

Feb. 16, 2005
Transaction Details

Web Accept Payment Sent (ID # 0EA20842775885503)

Name:
jeffrey weisberg (The recipient of this payment is Verified)
Email:
jaw+paypal@tcp4me.com

Total Amount:
-$10.00 USD

Item Amount:
$10.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
argus contribution
Time:
19:34:52 AST
Status:
Completed
Shipping Address:

No Address Provided

Funding Type:
PayPal Funds
Funding Source:
$10.00 USD - PayPal Account

Description:
argus contribution

Note:
Thanks for a wonderful piece of software!
Argus rocks!!! :)

Thanks,
-Karl
http://www.kvcd.net
-------------------------------------------------

Jan. 20, 2005
Transaction Details

Web Accept Payment Sent (ID # 46284855BL779473E)

Name:
The NetBSD Foundation, Inc. (The recipient of this payment is Verified)
Email:
paypal@netbsd.org

Total Amount:
-$10.00 USD

Item Amount:
$10.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
The NetBSD Foundation
Time:
00:55:35 AST
Status:
Completed
Shipping Address:

No Address Provided

Business Contact Information

Customer Service URL: http://www.netbsd.org
Customer Service Email: admin@netbsd.org

Funding Type:
PayPal Funds
Funding Source:
$10.00 USD - PayPal Account

Description:
The NetBSD Foundation

Note:
Thank you all for a wonderfull and stable OS!

Karl Wagner
http://www.kvcd.net
--------------------------------------------------

Dec. 19, 2004
Transaction Details

Web Accept Payment Sent (ID # 9H769888B8268731Y)

Name:
Hubert Feyrer (The recipient of this payment is Non-U.S. - Verified)
Email:
paypal@feyrer.de

Total Amount:
-$5.00 USD

Item Amount:
$5.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
g4u
Time:
14:35:24 AST
Status:
Completed
Shipping Address:

No Address Provided

Funding Type:
PayPal Funds
Funding Source:
$5.00 USD - PayPal Account

Description:
g4u

Note:
Hi Hubert,

Thanks for such a wonderful utility, and for basing it on one of my favorite OS'es ;)

Cheers,
-Karl
http://www.kvcd.net
------------------------------------------
Dec. 17, 2004
Transaction Details

Web Accept Payment Sent (ID # 6FV13308CC485771W)

Name:
OSDN / VA Software (The recipient of this payment is Verified)
Email:
salexander@valinux.com

Total Amount:
-$5.00 USD

Item Amount:
$5.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
Donation
Invoice ID:
223316
Time:
20:55:47 AST
Status:
Completed
Shipping Address:

No Address Provided

Business Contact Information

Customer Service URL: http://www.sourceforge.net
Customer Service Email: staff@sourceforge.net
Customer Service Phone: 510-687-7181

Funding Type:
PayPal Funds
Funding Source:
$5.00 USD - PayPal Account

Description:
Donation

Note:
Thanks for a wonderful piece of software.

-Karl
http://www.kvcd.net
----------------------------------------

Dec. 4, 2004
Transaction Details

Web Accept Payment Sent (ID # 6PH284168E1303916)

Name:
Manuel Kasper (The recipient of this payment is Non-U.S. - Verified)
Email:
mk@neon1.net

Total Amount:
-$10.00 USD

Item Amount:
$10.00 USD
Shipping:
$0.00 USD
Handling:
$0.00 USD
Quantity:
1
Item Title:
m0n0wall
Time:
01:14:54 AST
Status:
Completed
Shipping Address:

No Address Provided

Funding Type:
PayPal Funds
Funding Source:
$10.00 USD - PayPal Account

Description:
m0n0wall


------------------------------


Donation of $25.00 (if I recall the amount correctly) was made to DVD2SVCD about 3 years, but I lost track of that one.
Also donation to Baldrick at vcdhelp.com some time ago.

Also contributions made by code review/fix, specially to the FreeBSD Team as shown below:


Page 180
The example in the middle of the page should read:

For example, to generate a second set of 32 pseudo-terminals, enter:

# cd /dev
# ./MAKEDEV pty1

You can generate up to 256 pseudo-terminals. They are named ttyp0 through ttypv, ttyq0 through ttyqv, ttyr0 through ttyrv,

ttys0 through ttysv, ttyP0 through ttyPv, ttyQ0 through ttyQv, ttyR0 through ttyRv and ttyS0 through ttySv. To create each

set of 32 terminals, use the number of the set: the first set is pty0, and the eighth set is pty7. Note that some processes,

such as xterm, only look at ttyp0 through ttysv.

Thanks to Karl Wagner for pointing out this error.
Page 197, first line

link here: http://www.lemis.com/errata-2.html

More:
http://www.openbsd.org/donations.html


And too many others I lost track of, or were payments I did on an old PayPal account I no longer have.

This is just the way I show appreciation to some developers and people I value, so KVCD.Net DOES give back a lot to the community.
So anyone that joins KVCD.Net can be assured that some of the money he gave when joining, eventually goes to some selected open source projects, and that is a feeling of satisfaction.

Have a G'day!,
-kwag :thanks:

[Zyphon]

Well, since this model was put into operation, KVCD.Net has been the cleanest and most joyful site to visit and to talk about advanced video conversion, because the people that join truly want to learn, and the pay model keeps the rats out of the site.
Hi Karl,

I have to agree with you there. Since the paid model has come into action KVCD.net has very extemely clean indeed.

In the past it used to get very frustrating with all the AVI warez kiddies that used to hound the board with ways to convert their illegally gotten movies and got to such a state that it was becoming unbearable.

Since the change it has been a clean site whith genuine people who love video/audio encoding and who are always on hard to help people out and to be honest I think $2.99 is such a small amount to ask and is not hardly going to break the bank.

KVCD.net was one of the first places I found and I have learned a lot from there and Karl and the other members some of whom are members here also have taught me a lot. So thanks Karl for that. :D

@All

Please don't feel that I am putting this site and forum down, I an not. I like being a member here also and equally there are many many great members here that are also so helpful and I have learned a lot from this site also.

This is a great site to, but the beauty of the www is that you can have more than one source for from which to get knowledge and this is a good thing.

I just wanted to help defend Kwag's decision to go the way of a pay site. :)

Thanks for listening. :D

[john3voltas]

@Nic,
As far as I can recall, I mentioned all the settings that were enabled.
If I didn't mention 2-pass it's more than sure that I had it disabled.
And if what you're saying is that in single pass the ratecontrol is managed by libavcodec, then it only gives me more reason to be angry at libavcodec...
@Kwag,
Nice seeing you around.
Glad you made your point very clear to anyone ;).
@all
Doom9 is one of the best places to find video encoding information.
And is also the places where one can find more free open source developpers coding video enconding tools.
And that's very cool.
The encoding community owes a lot to Doom9 and to it's users.
For that I thank you all.
But there are other places where people can find help and where one can find a lot of information gathered from lots of testing.
Kvcd.net is one of those places and so it is Vcdhelp (or whatever name is used nowadays) which is another good example.
I just would like to know why some people here won't acknowledge that and why they will never stop sending sarcastic messages when someone else says he/she has a problem with an encode that used the Notch matrix or that was encoded with some help at the Kvcd.net forum.
At the end of the day what I mean is that "Knowledge and good will" are not an exclusive of Doom9.
And for me this would close the argument that I raised.
Just my 0.02€ before I get another warning or get striked for not being nice or for going way too off-topic...
Thanks

[dragongodz]

since this model was put into operation, KVCD.Net has been the cleanest and most joyful site to visit and to talk about advanced video conversion, because the people that join truly want to learn, and the pay model keeps the rats out of the site.
In the past it used to get very frustrating with all the AVI warez kiddies that used to hound the board with ways to convert their illegally gotten movies and got to such a state that it was becoming unbearable.
hmm ok lets assume the "rats" refered to are warez kiddies. how exactly does disabling reading stop them from fouling up the forum ? it doesnt. disabling posting by needing to be a member does. so the arguement that reading by anyone has to be members only aswell to stop them is plain false.
now you may say why would anyone just want to read. ok i will give you an easy example.
Bill hears about kvcd and after looking around thinks he may be interested in testing it out for his vcd/dvd. now he hears there is an actual website with a forum. good he thinks i can see what experiences people have had and any problems and work arounds etc. goes to the website, goes to read the forum and......he must pay.
now other may be fans of that all they like but i am not.

because specifically dragongotz has made several comments about us, on different occasions
funny but i dont seem to remember me ever going to your forum and flaming away at people as you have done before here. infact me saying things like i dont like a forum being pay-per-view is nothing to the attitude you have brought here in the past. as i also said i get on fine with people that are seriously trying to give or get help here but not those who just want to rant and flame. oh and so we are clear on this it was john3voltas who brought kvcd in to this topic with his mini-rant about how kvcd matrix always gets blamed etc. instead of just explaining what the problem was(with details) and seeing what we would say.

Below is our PayPal record of some transactions that have been made specifically to the open source community
well good on you. still has nothing to do with what i have said.

I just would like to know why some people here won't acknowledge that and why they will never stop sending sarcastic messages when someone else says he/she has a problem with an encode that used the Notch matrix or that was encoded with some help at the Kvcd.net forum.
now thats a big stretch. go back and read that post you did. you assumed people would say something. maybe in future wait and see what they actually say instead.

this is all way off topic and i have no interest in reading more justifications of peoples actions so i wont bother to reply to anymore such posts here.

[john3voltas]

Correction: it wasn't me who introduced the kvcd.net into this topic.
That was Sagittaire's doing, not me.
I just commented on Nic's comments about kvcd!

Note: I have lurked D9 for a very long time and I don't recall Kwag ever flaming in here.
I do remember some argumentations (both here and at kvcd.net) with a lot of people from both forums flaming the opposite end.
If for instance we were talking about honorable moderator Mr. Neo Neko flamings at kvcd.net then I would easily remember and agree.
Maybe you could give us some evidence of such flaming behaviour from Karl?...

Note2: BTW we both used the word d*ck a few posts above.
I got a warning for that.
Did you get a warning too :devil: ?
Forget it. I can guess it :D.

[Mug Funky]

Note: I have lurked D9 for a very long time and I don't recall Kwag ever flaming in here.

well, that thread was in fact delteated. it got quite nasty, and i'm not too proud of the contribution from either "side". i totally don't understand inter-forum rivalry at all. we're all just netizens after all, but the whole thing just left a bad taste in both kvcd and doom9's collective mouths. stupid really, and since then kvcd people have been immediately on the defensive as soon as they post here, which of course means they don't get particularly useful responses from doom9 members - it's the text equivalent of poor body language, and it's hard to avoid thinking some people are just trying to start a fight.

[edit]

btw, i think i read the first 2 sentences of kwag's post. please put all that in a code block so people who are interested can read it, but people who are interested in quenc development can read on without wearing out their scroll-wheel.

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

[Guest]

Two points to add to Hank's correct statements:

1. A coded GOP order of IBBPBBP... can still be closed if the leading B frames are coded with macroblocks not using forward prediction.

2. The coded order IBBPBBP... is normally preferred for GOPs because it has a higher compression ratio than IPBBPBB...

[DarkFoon]

@Nic
you asked, and I have delivered: A test showing how different encoders treat the test clip I created yesterday.
They all used the same parameters (as far as I could control):
gop-18
b-frames=2
closed-gop-ON
bitrate-7000
max bitrate-8000
CQM-one I whipped up last night

So here goes(ignore all of the filename except the last part, that's the encoder):

Source
http://rapidshare.de/files/5046118/Random_Clip.zip.html

Quenc
http://rapidshare.de/files/5071994/Robot_Chicken_0.8_0.5_Quenc.m2v.html
size: 7,403kb

HC
http://rapidshare.de/files/5071829/Robot_Chicken_0.8_0.5_HCenc.m2v.html
size: 10,791kb

TMPG
http://rapidshare.de/files/5071900/Robot_Chicken_0.8_0.5_TMPG.m2v.html
size: 8,388kb

(sorry, no CCE. I don't have it)
All filesizes reported by window's "details" view

Attached are the log files from HC and TMPG, if you are interested.

OT:
In light of hank315's last post, I realize that I know nothing :eek:

[video]

DarkFoon no :) an open GOP allways starts with a B-VOP. Only colsed GOPs can be started with I-VOPs

[communist]

Ok I'm a little bit confused as to where the error lies but I *think* its in QuEnc.
I recently tried to encode a DV avi file using a simple script as followed:

AviSource("d:\street.avi")
ConvertToYV12(interlaced=true)

This opens up fine in VirtualDub (1.6.10) and I can even add filters to the script and it will encode the whole file. I'm using the PanasonicDV codec, all other DV avi files work but this one wont encode.

However the same script will crash QuEnc (closes itself) as soon as I hit Encode. When I select separate passes for Audio/Video QuEnc will encode the Audio but not the video. So the Audio seems to be not the problem. When I select No Audio in muxing profile it will only create a 0 byte mpg file but not encode anything. When I select No Video it will create the mpeg file with audio only.
All other options like MPEG1/2, VBR, HQ, Extreme, DC precision, Interlaced etc. dont seem to have any impact at all on the problem.

Using DirectShowSource("d:\street.avi",25) instead of AviSource fixes this problem (QuEnc encodes the file) but all other DV avi files work fine with AviSource.

Here is a 10frame long sniplet from the file that exihibts the same problem.
crash.avi (http://www.stud.uni-goettingen.de/~s304280/D9/crash.avi)

The PanasonicDV codec can be found here (http://www.stud.uni-goettingen.de/~s304280/D9/pdvcodec.zip).

[Nic]

@communist: How very odd! Thanks for the good bug report and test files. It crashes here for me too (I'm at work so can't find out where and why it crashes yet). I'll try and fix it for the next release. Thanks again :)

[communist]

Nice, I was already thinking that the file was cursed by the usual windows works for all except file x. I had already reverted to a older windows installtion from an image file just to find out that it was indeed the file. Good to know its not my setup :)

[dragongodz]

However the same script will crash QuEnc (closes itself) as soon as I hit Encode.
using the MS DV codec it just doesnt encode, 0 size file, rather than crash. atleast for me.
here is another example that works with QuEnc 0.60RC2 fine, just as the 24fps crash clip did, but doesnt with 0.60 and 0.61 release versions. so the change/bug for both these has happened between 0.60RC2 and 0.60 release.

[Nic]

http://nic.dnsalias.com/QuEnc_PrettyExperimental.zip

Just an update for people that are testing these builds as to where I am going with the encoder for the next update.

a rough changelog (since the VeryExperimental build):

1) Drop down codec list (Includes SNOW and MPEG-4)
2) Can output an MP4 (with AAC or MPEG-4 or both)
3) Can output an AVI (with SNOW)
4) Can encode to MP3 and M4A
5) Tweaked rate control for 2 pass
6) Tries to give better options depending on the content of the source (so detects if has video/audio/both and only displays relevant options)
7) Now works on 24 frames per second video (plus others perhaps broken last build)
8) Pulldown should now be working for MPEG-2
9) Should now work on communists problem clip (hopefully! please test)
10) The MP4 that is created is PSP profile. Works on a PSP/K750/W800* as well as it does in something like QuickTime.

-Nic

*As long as you keep within the encoding parameters for those devices

[communist]

Great! My problematic clip no longer crashes QuEnc :)
MP4-Output? That looks pretty cool and already works to some degree as expected.

Also I dont know if you already know it or whether I'm doing something wrong:
When MPEG4 as codec is selected:
QuEnc will crash at encoding start when ("MPEG2 ;)" ) Mux-Profile is set to MP4
QuEnc wont crash when No Audio or No Video is selected, output files are ok.
I tried with several clips but this script will do the same:

ColorBars(720,576)
ChangeFPS(25)
Trim(0,250)
ConvertToYV12()

[DarkFoon]

Great release!
no more 24fps bug.
but I have noticed some interesting things.
It accepts the RGB24 test clip AVI as is (without any conversion to YV12.)
And the output size of the test clip is larger than the previous release.
(8,122 vs. 7,403)
Will the next version fix the problem with compressing the fade to black too much?

[Nic]

@communist: Well spotted. Depends on the resolution of the clip. (it's to stop the user making incompatible PSP MP4 files inside movenc.c). It does not apply here, so i'll remove that limitation and reupload :)
Thanks again!

EDIT:
Ok, reuploaded. Download http://nic.dnsalias.com/QuEnc_PrettyExperimental.zip again and make sure it's the new version by right clicking on the exe, goto properties->version and check it's version 0.6.1.4. That should fix the MP4 bug you were having (although there are plenty more i'm sure ;) )

@Darkfoon: Yup 24 fps fixed. It uses more bitrate on your clip now like it should have done. The black = blocks problem is a tricky one (not only on fades). I'll be trying to fix it soon, but don't really know where to start on that one.
When fed an AVI QuEnc creates a temporary AVS to load the AVI and use YV12 colorspace :)

-Nic

[DarkFoon]

A quick note for anybody who has been using the test clip I provided for testing:
frames 73-76 seem to show the most compression.
In my experimenting with CQM's, I have found that certain ones reduce the ammount of artifacting in those frames.

Hmmm... upon further investigation, it appears to me that the artifacting I'm noticing might be related to the B-frame compensation.
Would any body care to look at this and verify?

@Nic
It seems to me that Quenc removes 1 frame total from my clip. I have 304 frames in the original, and the encoded version has 303. I seem to remember a post about this in one of the earlier versions, but I thought it had been fixed?

[JoeBG]

@ Nic

Great idea to add mp4 output to QuEnc. I always was a QuEnc fan for my mpeg2 Encodes but changed last year to mpeg4.

Testet Version 0.6.1.4. Very Blocky results with 700 kbps. Much better with 1800 kbps (without b-frames) but not in action scenes. Here also very blocky when looking from frame to frame.

The first pass ist as fast as Xvid is on my system in the second pass and the second pass of QuEnc is as fast as the first pass in Xvid => Why is the second QuEnc pass so fast?



In the moment QuEnc produces mpeg4 ASP. Do you plan to add the possibilities for mpeg4 settings?

[dragongodz]

for those interested in testing if having a value for headers makes any difference to the rate control there is a new 0.61 test version at
http://www.pcpages.com/dragongodz2/
you should only compare it to 0.61 release version and NOT the experimental versions. also dont expect much difference as its a just a small hardcoded value. the point is to see if there is any up or down(size/bitrate wise) variance because of it. testing with long clips, expecially ones that undersize with 0.61 release, would be highly desirable.

[Mug Funky]

hmm. CBR mode seems to be b0rk, no sure since what version (i'm using the latest "pretty alpha")

i'm doing 2-pass CBR at 7000, and average quant is about 16, peaking at 22 or so (if you trust bitrateview).

contrast that with a CQ 7 encode that comes out average 3236 kbps with a peak of about 6500.

QLB matrix used on both.

i can provide a test sample in huffy if need be. i'm testing this on a real-world problem sample, because i have a few short captures of the source lying around, and i just figured out how to get them into avs without any colourspace conversion...

btw, 1-pass CBR doesn't seem to suffer this, but appears to hit b-frames a little too hard. (GOP structure is non-negotiable, unfortunately) looks the best so far though, not counting the CQ one.

[Nic]

@MugFunky:
In theory, there is no such thing as 2 pass CBR. But i've heard it mentioned a lot. Could people explain it to me? CBR means constant bitrate. 2 pass is only used to determine how to distribute bitrate, but CBR restricts any sort of distribution.

I can imagine a kind of 2 pass ABR where the range of bitrate is tightly limited. But 2 pass CBR makes no sense to me.

I think i'll turn off 2 pass mode when CBR is selected for the next version.

-Nic

[Mug Funky]

yeah, i thought that too... it could in theory improve matters, but only in a very limited set of cases (and it'd probably suffice to do it per-GOP then).

though i wonder what is happening there - there's a marked difference in how the 2 modes behave.

btw, for CBR encoding, would it make sense to allow b-frames to have the same quants as p-frames? 2-pass mode doesn't limit b-frame quants, which is why i was using it. looks like it backfired :)

nice work with adding mpeg-4 and aac encoding for PSP :)

[dragongodz]

In theory, there is no such thing as 2 pass CBR. But i've heard it mentioned a lot. Could people explain it to me?
if you insist. ;)
you are correct in saying that 2 pass CBR should never really be needed(i have said it myself plenty of times aswell) however the way some encoders work is they they get as close to CBR as possible and pad frames to make the CBR. sometimes however some do not pad correctly, example over padding or not raising a quant so the bitrate actually rises above the target CBR. its usually very small and really of no matter. also if an encoder doesnt pad properly the bitrate can of course also drop below the CBR. now a second pass can come through and correct any such minor mistakes.thus is born 2 pass CBR. :D
also some do not pad at all but just use the closest it can get so you see up and down frame sizes which is really more a constrained/tight ABR. i imagine an encoder could choose to do padding on such streams in a second pass or change the ABR if it thinks its not the most effective.
as i said though it is pretty pointless IMHO as the encoder should be checking the frames before they are written and making any corrections on the spot for CBR.
i can name 1 comercial program by the way that supports it, CCE 2.70. BASIC version supports 2 pass CBR and SP support multi-pass CBR.
http://www.cinemacraft.com/eng/basic.html

now as it relates to QuEnc, actually libavcodecs RC is of course far from great. infact CBR shows this just as good as anything. with one of the previous versions someone was trying to make a vcd or svcd or something and using CBR but got spikes. i told him to do it 2 pass and sure enough it reduced the spiking and gave him a usable file.

btw, for CBR encoding, would it make sense to allow b-frames to have the same quants as p-frames?
thats a RC decision. that is you have to consider that B frames could have a lot more motion vectors and be larger than the P frame at the same quant ,so to get it back down to CBR you would up the quant. :)
now with 1 pass we have set some settings to try and reduce spiking and this does hit the B frames but it is better than the alternative. maybe later we can add mpeg2enc's(modded TM5) 1 pass CBR and VBR RC which should prove much better. or even turn 1 pass VBR in to more of an ABR mode maybe.

[Mug Funky]

ah, okay. but the MVs wouldn't add that much would they?

if you saw this sample all would make sense (you got anywhere big i could upload it to?). if you're familiar with the r4 studio ghibli DVDs, you'll know they're multiangled with a storyboard, and so their max BR is limited to 7000, and their GOP structure is immovable (segment re-encodes on multiangle features is nightmarish... even when all the numbers work out, spruce finds something to complain about).

well, after the encode of Pom Poko got QC'd, there were a couple of bits that just looked awful. every encoder has its limits i guess... so i decided to grab the bad bits uncompressed and use them as "problem samples". i plan to collect a few more of these and use them as generic encoder test clips, rather like the problem samples we all know from audio encoding - applause, castanets, fatboy slim, etc. so far all i have is 2 anime clips of beaver things running through thick scrub. one normal, one fading into a still scene. typically anything with sharp edges, high motion (with no motion blur) and lots of green is going to completely mess up an encoder...

well, anyway, when i tested quenc on these samples, it was the b-frames that were the big problem. everything else was fine, and changing the matrix didn't help much. encoding at constant quant, though dramatically lowering the bitrate, seemed to prevent the bad scenes going really bad. so it would seem that CBR mode could certainly spare a lower quant on the b-frames in these cases, considering that at such a high quant, it must have been padding these frames anyway (CQ 7 looked better and peaked at 6500 after all).

perhaps it's more a b-frame quant ratio thing? when the p-frame quants get a little high, the b-frames turn into a blockfest.

btw, QuEnc is great on everything else, so not to worry :) i can send this sample if need be (it's 65 megs in huffy, considerably bigger in that stupid "blackmagic" uncompressed 8 bit uyvy format though...).

[edit] btw, 1-pass VBR is actually really good... i wouldn't be replacing that unless there was something better to replace it with. hasn't been any spiking since the 0.6 release. also, isn't mpeg2enc's RC macroblock based?

[DarkFoon]

@dgz
I have seen 2-pass CBR in one other place: Windows Media Encoder 9
but that's for WMV.
[edit] I like 2-pass CBR, for the record (meaning that I use it occasionaly)

@Nic
I don't think I have mentioned this, but Quenc is the fastest encoder on my system. :)
It used to peak out at ~11fps with DivX on 352x240(30 fps)
Quenc working on 720x480(24fps) goes up to 15fps!!!!
Keep up the good work!
Will there ever be a constant Q mode that is constrained by max bitrate?

[manolito]

btw, 1-pass VBR is actually really good... i wouldn't be replacing that unless there was something better to replace it with. hasn't been any spiking since the 0.6 release. also, isn't mpeg2enc's RC macroblock based?
Lately I do a lot of AVI2DVD conversions using QuEnc or FreeEnc 0.31 in 1-pass VBR mode, and I am quite happy with the results. (For low bitrates the quality is noticeably better than with CCE 2.67 in 1-pass VBR-RoBa mode). I do have a question though about which formula for rate control equation would be most suitable in 1-pass VBR mode.

In FreeEnc I have experimented with "rc_eq=tex^qComp" and "rc_eq=tex". With "rc_eq=tex^qComp" I had hoped that the amplitude of the bitrate spikes and dips would be somewhat lower, but BitrateViewer tells me that the peaks are about the same. Using "rc_eq=tex" I can tell by looking at FreeEnc's graph that the bitrate does fluctuate more freely, and encoding speed is a little higher. Visually I was never able to put my finger on any differences in quality between the two methods.

Which method does QuEnc use in 1-pass VBR mode? And which of the two methods should theoretically be able to deliver a better rate control pattern in 1-pass VBR mode? And does the "^" really mean "XOR"? (You see I am totally ignorant about FFMPEG / MENCODER).

Cheers
manolito

[GoDuke]

Nic & Co. --

As requested, I've run a couple of tests with both the current Experimental Version (.6.1.4) and the current release version (.61).

Settings:

Avg Bitrate: 7000
VBR
2-Pass
High Quality
Interlaced
Max Bitrate 9500

Input: Simple Script, VHS capture (352x480) 00:01:42 long

RESULTS (Bitrate Viewer):

Version .6.1.4
Avg Bitrate 4414
Peak Bitrate 6714
Avg Q 2.06
Peak Q 5.74

Version .61
Avg Bitrate 6045
Peak Bitrate 8619
Avg Q 1.07
Peak Q 5.64

Comments
I'm not sure why the new version does so much more poorly. Perhaps it has to do with the poor quality input. In either case, the target average of 7000 is missed pretty severely.

Most interesting to me is that both versions severely cut the bitrate in the last 2 seconds or so. This isn't a function of the source. The clip actually cuts off in the middle of a fairly high motion sequence. There is suddenly a lot of blocking in the background with no apparent cause. If it would be helpful, I can post / send the frames in question for comparison.

I plan to run an encode of an entire 20 min segment tonight (using the Experimental Verion). I'll post those results in the morning.

Let me know if any additional information would be of use.

[freelock7]

-Manolito
rc_eq=tex^qComp doesn't change really something in FreeEnc.
Many undeflows reported by ifoedit with freeEnc031 led me to tweak some values in the incredible template to reduce underquantization.
Lmin = 1 and spatial_cplx_masking=0.1 change the bitrate distribution with a better quantization.
But the 031 version uses the QuEnc051 libavcodec known for its bitrate spikes. So, do not set the high bitrate above 7000!
For now, QuEnc062 experimental has a very good VBR1Pass and seems to correct undersize (tested with LADDER_49).

[manolito]

Thanks freelock7,
I already read your post in VMesquita's FreeEnc forum and did some test encodes with the values you proposed for Lmin, Lmax and spatial_cplx_masking. The concept of "lagrange multiplier" is way beyond my math capabilities, but 1-pass VBR tests with your tweaked values came out pretty good. Will do some more testing....

Cheers
manolito

[dragongodz]

if you're familiar with the r4 studio ghibli DVDs, you'll know they're multiangled with a storyboard
did you forget who you are talking to ? ;) of course i know the studio ghibli dvds, i even own some(not all), so yes i know what they are like. :)

you got anywhere big i could upload it to?
how big ?

btw, 1-pass VBR is actually really good... i wouldn't be replacing that unless there was something better to replace it with.
thats cool. there was plenty of problems in the past but maybe its ok now. havent tested it recently. if everyone is happy with it then there is indeed no need to change it.

I have seen 2-pass CBR in one other place: Windows Media Encoder 9
i suspect since that uses techniques from mpeg4 it uses the same type of definition for CBR(more like ABR) which is not exactly the same as mpeg1/2 CBR. as such 2 passes may indeed help it.

GoDuke - it would be nice to see what the test version i mentioned also produced in that test you did aswell. especially compared to QuEnc 0.61 release version.

[DarkFoon]

Encoder test using the same parameters.
Sample 1 (http://rapidshare.de/files/5237333/TMPG-SVCD-QLB-2pass-VBR_2000avg-2400max_.m2v.html)

Sample 2 (http://rapidshare.de/files/5236991/Quenc-SVCD-QLB-2pass-VBR_2000avg-2400max_.m2v.html)

Both have their pro's and con's:
Sample 1 doesn't compress the fade as bad, but has worse overall quality (blocking in almost every motion frame).
Sample 2 has better overall quality (less blocking/the blocking is concentrated in a few frames) but certain luminosities are hit really hard, and have lots of blocking. (last time I chcked, Nic was working on that)

Both samples are MPEG2, closed GOP, QLB matrix, anime, and SVCD (Yes, I know its customary to IVTC anime, but I really don't want to go through the trouble of hand tuning it to look perfect, and its going to end up on TV anyway, so it won't matter.)
I wonder why the Quenc sample has the kind of blocking that Blockbuster() was created to reduce (DCT blocking?) on the color areas, but not the other sample.
I can't wait for 0.7! :D

[GoDuke]

dragongodz:

Your wish is my command . . . :)

Using your experimental version with the same script and parameters as before resulted in much improved rate control:

Avg Bitrate: 6597
Peak Bitrate: 9533
Avg Q: 1.75
Peak Q: 8.07

Interestingly, however, the problem with the last few second of the clip seems even more pronounced. In a low motion, fairly dark scene, the bitrate plummets from 6895 to 696.

EDIT: Apparently, I forgot to post the earlier version on this full 23:34 clip with version .6.1.4. All settings were the same as the shorter clips above:
Avg Bitrate: 4728
Peak Bitrate: 8676
Avg Q: 2.01
Peak Q: 8.07
This full clip ends with a fade out, but the blocking problem is huge here on the last 10 frames or so. At full speed, it's not very noticable, but if you watch it slow, it's really bad.

Hope this helps . . .

[dragongodz]

GoDuke - thank you very much for testing it. hmm bigger difference than i expected.

anyone else intereseted in testing ? not only for reproducable undersizes but also ones where 0.61 release version sized fine, that is does my test version then oversize or is it still close etc.

see i really need multiple tests on different sources etc to know exactly if its more generally good or bad and that only comes from more tests.

[Koepi]

Requested bitrate: 5188 kbps (2pass).

0.61 (Nic): 4100 kbps
0.61+Headers-dgz: 4100 kbps
0.61-without headers-dgz: 3000 kbps

Cheers
Koepi

[dragongodz]

thanks Koepi. how long(time) was the source ?

[Koepi]

It was round about 1 h 40 mins, a full movie encode.

I didn't look into your changes, but if you add a "theoretical" overhead, make it i.e. 1/8 of real frame size for b-frames and maybe 1/4 for p-frames. Just for testing let's assume i-frames aren't scalable, thus entering full frame size as "static" could be ok.

Those values are an average in mpeg4 asp. Maybe they work well for mpeg2, too.
(I just mention this because you wrote you added static overhead to the stats).

Cheers
Koepi

[dragongodz]

well the ideal would be to get the header stats from libavcodec. will have to look back in to passing that through when i get time. ;)

as such though this test version is meant to see if a header value increased the bitrate on undersizing and/or oversized correct sizing encodes. since it isnt a big change i dont expect large variation in general but more of a general direction adding the header takes things. so if a few more people want to test it would be nice. if you are interested in the bits i have found for this so you can see what i am talking about Koepi then PM me. :)

[Mug Funky]

one thing on the undersizing in 2-pass mode: i've noticed that open/closed GOP makes a large difference. the open-GOP 2-pass file (all other settings identical to the closed one) was about half the size of the closed one. strange.

there's no marked difference between open and closed in 1-pass mode (bitrate behaviour is about the same, just a little different).

i'm not sure how reproducible this is on other clips (need more testing), but it could be a place to look :)

[dragongodz]

Nic - please read this thread if you havent already.
http://forum.doom9.org/showthread.php?p=715272

i'm not sure how reproducible this is on other clips (need more testing), but it could be a place to look
i will run some tests(hopefully tomorrow) and see if i can reproduce it aswell.

[dragongodz]

Mug Funky - ok ran a couple of tests with both QuEnc 0.61 release and experimental versions on a 10 minute clip with open and closed GOP. result was closed GOP files a few hundred K bigger. considering the final files sizes were nearly 200MB its not really much, certainly not half the size as you experienced. so i dont know what happened with your clip to have such a major difference. how long was it ?

[Mug Funky]

how long was it?

quite short actually :) about 200 frames. i guess it's not surprising that it'd behave unpredictably on such a short sample, but it's also strange that closed-GOP made such a difference, considering there was no scenechange detection. there would be a slightly higher number of i-frames, but could that explain all the difference?

if there's no difference over long clips i wont worry. IMHO a more pressing concern is getting the last second of reatecontrol to behave nicer.

[DarkFoon]

IMHO a more pressing concern is getting the last second of reatecontrol to behave nicer.
Agreed! :)

[Nic]

Been in NYC (working sadly), so haven't looked at QuEnc. Should get time this week. I'll fix that last second problem (shouldn't be too tricky, I hope ;) )

Thanks for all the feedback :)

-Nic

[freelock7]

-DGZ
Tested your <QuEnc061-testonly> with a 100min movie lenght(2Pass):
set average=5000
Encoding Average =4882
Set Max Bitrate=8200
Bitrate spike=9010
Muxing with IfoEdit= No buffer- under- runs detected

[boombastic]

if i use the /? switch for quenc to have the list of the possible command to use i can't see the way to encode the audio to 48000 Hz sampling rate instead of the default 44.1 KHz,is there a way?

[dragongodz]

freelock7 - thanks for the test. can you also do a comparison against 0.61 release version so i can see the actual difference ?

i can't see the way to encode the audio to 48000 Hz sampling rate instead of the default 44.1 KHz,is there a way?
QuEnc encodes at the rate it is given, feed it 44khz it encodes to 44khz. to change the sample rate with Avisynth read the Avisynth docs that are installed with it.

[freelock7]

Tested another movie
QuEnc-DGZ
Wanted avg=4500
Encoded avg=4010
Global QLevel=1.40

QuEnc061(original)=exactly the same!

Well, strange QLevel with many flat lines at quant=1 (underquantization).
Fine quality picture (sure, for this average!)
Both of them work the same. Did you change something?

[dragongodz]

Both of them work the same. Did you change something?
yes but it is only a small change to try and see if it has a posative or negative impact. on some it seems posative while others negative and others no difference. so i think there are more fundamental changes needing to be made for any major improvement. i will be trying to look at some other changes this week as time permits. thanks again.

oh and for that second test, if you have a lot of Q1 and na average of 1.40 then you are practically saturating the compression. so it would struggle to get up to that bitrate unless it used padding etc which of course doesnt add any quality just size. :)

[DarkFoon]

unless it used padding etc which of course doesnt add any quality just size. :)

That's something that's been puzzling me. A few weeks ago (probably a month or two), it sounded like you were just adding some kind of padding to increase the bitrate, but what is the point of that? Isn't smallest size at the highest quality (possible) the purpose of compression?
No offense, but I can't think of any situations where undersizing would be undesirable.

[dragongodz]

it sounded like you were just adding some kind of padding to increase the bitrate, but what is the point of that?
no, not adding padding. the things i have been changing are to do with bit distribution and rate control calculations.

No offense, but I can't think of any situations where undersizing would be undesirable.
when the rate control has failed to distribute as much bitrate as possible. for the above example where the average quant is around 1 then you are practically at saturation point and wont get much more in either size or quality. however say the average quant had been more like 4 or 5 and you were still under your target bitrate. that suggests that there should be areas where a lower quant me be able to be used, thus raising bitrate towards target and ,atleast in theory, increasing quality. of course the distribution still has to adhere to any restrictions such as max bitrate and VBV etc.

[DarkFoon]

I stand corrected.

By the way, how is max bitrate determined by quenc/libavc? I remember come confusion on the subject a while back.
I always thought it was the number of bits used to encode 30 frames (NTSC) or 25 frames (PAL). And when a new frame was encoded, the oldest frame in the comparison group (the 30 or 25 frames used to determine max bitrate) was dumped, and the newest frame could have at most as many bits that would make the group total the max bitrate.

hmmm, but that wouldn't work too well... if there were 29 frames of 0 bits(unlikely), the 30th frame could by 8.5 megabits in size (assuming max bitrate=8500) which would totally mess up set top playback devices.

[Mug Funky]

of course, if you're getting an undersized file at average quant 1, then you can squeeze a few more bits with a higher bitrate matrix - the numbers in the quant matrix behave the same as the global quantizer - lower numbers = more bits = more detail.

of course, some stuff undersizes no matter what... i encoded "son of godzilla" with a flat 8 matrix (all 8's for intra and non intra) and it still came out at almost constant quant 1. pre-compression filtering can often be too efficient (maybe these movies were mastered for divx rather than DVD?)

[DarkFoon]

@Mug Funky
That's an interesting idea. My MPEG-2 capture card uses different quant matrices. I'm not sure what causes it to change, but when I run it through DGDecode with the "show quant matrices" option, I get a large file with about 10 to 20 matrices.

I'd be kinda neat if a user could specify a directory with a bunch of matrices, and quenc could switch to another matrix if it maxes out on quant 1 with the first one the user specifies. Or the user could specify 4 or 5 matrices for quenc to choose among for highest quality/smallest size, depending on which the user prioritizes.

[Mug Funky]

i'd love it for CBR stuff. it'd be easier to implement i think - if quant=1 and bitrate < target, then multiply matrix by some calculated number (based on compressibility stuff i have no idea about, and also a ratio of current bitrate and target bitrate), then round to integers. this wont affect the "shape" of the matrix much (rounding excluded), but will allow quant 1 to keep more detail.

[dragongodz]

I always thought it was the number of bits used to encode 30 frames (NTSC) or 25 frames (PAL). And when a new frame was encoded, the oldest frame in the comparison group (the 30 or 25 frames used to determine max bitrate) was dumped, and the newest frame could have at most as many bits that would make the group total the max bitrate.
correct. though not all rate controls will go through all that. some will just go by GOP and target that to the relevant percentage per frames per max bitrate etc. Nics latest experimental versions is infact trying to do it the way you describe. ;)

hmmm, but that wouldn't work too well... if there were 29 frames of 0 bits(unlikely), the 30th frame could by 8.5 megabits in size (assuming max bitrate=8500) which would totally mess up set top playback devices.
actually no it shouldnt. that is if the dvd player has that little dvd symbol on it then it is meant to be able to handle such a case as that seeing as it is technically legal. ok reality may show that not all players would handle it great but reality should also show that it would have to be an extreme case, and i mean really extreme and rare, for an encoder to ever produce such an encode. so its not actually something you should need to worry about.

I'd be kinda neat if a user could specify a directory with a bunch of matrices, and quenc could switch to another matrix if it maxes out on quant 1 with the first one the user specifies. Or the user could specify 4 or 5 matrices for quenc to choose among for highest quality/smallest size, depending on which the user prioritizes.
well yes that is possible but it would be much simpler to simply adapt the chosen matrix if needed. that is if after 1st pass at Q2 the size/bitrate estimated is smaller than half the target size/bitrate then reduce/halve the values in the matrix(limiting to 8 and 16 values for intra and non-intra). then adapt the GOP/frame sizes from the first pass to a rough(you would need another real first pass to be actually accurate) new value from what the new matrix should produce. then encode second pass based on that. want to guess how much fiddling around that would be ? ;)

i'd love it for CBR stuff. it'd be easier to implement i think
i agree, for CBR it should be easier to implant aswell. still fiddley though.

[DarkFoon]

The reason I suggested swapping matrices as opposed to modifying one was because I thought that would be easier.
This is how I thought it would work (with no idea as to how it would be programmed):
Let's say the user specified higher quality as opposed to smallest size. So, when the encoder encodes a frame that is not Q1 (or as high as it can go, like Q2 for 2 pass, first pass) it re-encodes that frame with a different matrix and if that fails, then another, until it exhausts all the ones it can use, and then it picks the best out of those. If it encounters a winner on its second matrix, then it will go with that one, and not even try the others: this would be for speed enhancement. Instead of going through them all and encoding each one, it would just try "the next one" and if the "next one" is better than "the last one" then it sticks with it, even if there are other past it that could od a better job, it doesn't know.
The hardest part, that I can see, is getting it to still respect the bitrate. I mean, if it just picked the largest frame it could every time, then bitrate would be thrown to the wind.

[boombastic]

is there a command line to use the author dvd feature?

[freelock7]

Tweaked rate control for 2 pass

I confirm it!
Encoded a movie with QuEnc062Prettyexperimental in 2Pass, VBR=4500, scenechange off, closed gop off and quality is great!
Any more prediction problem (correct). :)

[manolito]

When I select "Force Closed GOP" in QuEnc 0.61 it seems that the resulting GOP length can only be 1+(multiple of 3). A GOP length of 12 or 15 is not possible, only 10, 13 or 16. When I select a GOP size of 15, QuEnc will change it to the nearest lower value (13 in this case).

Is this normal (or even desirable), or is this something that should be corrected?


Cheers
manolito

[dragongodz]

for those interested in doing a little experimentation/testing i present QuEnc 0.62 alpha3.

this should not undersize as bad as the other 0.62 alphas did. it should be closer to 0.61's undersizing, that is not always using quant 1 when it can for high bitrate or easy encodes. however feedback on not only high bitrate encodes but also low bitrate aswell, to see how good that is aswell, would be appreciated.

WARNING this is an alpha experimental version only and should be considered for testing purposes only.

binary(self extracting 7zip archive)
REMOVED. see alpha 4 link and mirror in later posts.

QuEnc 0.62 experimental source code
http://www.megaupload.com/?d=GL62KA1L

[communist]

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

Latest alpha still does that (not that it was supposed to be fixed in this version) - any news on that?

Also a temp. mirror for anyone else having trouble with megaupload:
Binary (http://www.stud.uni-goettingen.de/~s304280/D9/QuEnc/QuEnc062-alpha3.exe)
Source (http://www.stud.uni-goettingen.de/~s304280/D9/QuEnc/QuEnc-062alpha-src.rar)

[guada 2]

:thanks: communist.

Bye.

[freelock7]

Happy to test again:) .
DGZ, there is a problem -a great problem- in the bitrate average setting 2Pass.
At low bitrate <3000, prediction is not correct (oversizing+++)!
If you choose a VBR=2500 (or another value < 3000), prediction is always 4500!

[dragongodz]

Happy to test again
thanks. its one of the hardest things to get people to do. ;)

there is a problem -a great problem-
woops. see now thats why i need people to test and with different bitrates etc. :)

this should fix it
http://www.megaupload.com/?d=B3HIFBOZ

[Inc]

ehhm ....

I had a look into the sources of AVSEnc.cpp of the Qenc Source package.

In the section where its determined when using the QLB Matrix I found this ...

if ( bUseQLB || csMatrixFile.IsEmpty() == FALSE )
{
CString csQLBIntra, csQLBNonIntra;
csQLBIntra = CString("8 16 19 22 26 27 29 34 ")
+("16 16 22 24 27 29 34 37 ")
+("19 22 26 27 29 34 37 39 ")
+("22 22 26 27 29 34 38 42 ")
+("22 26 27 29 32 36 40 50 ")
+("26 27 29 32 36 40 50 61 ")
+("26 27 29 35 40 50 59 75 ")
+("27 29 35 40 50 59 75 89 ");

csQLBNonIntra=CString("16 17 18 19 20 21 22 23 ")
+("17 18 19 20 21 22 23 25 ")
+("18 19 20 21 22 23 24 26 ")
+("19 20 21 22 23 24 26 28 ")
+("20 21 22 23 25 26 28 29 ")
+("21 22 23 24 26 28 29 31 ")
+("22 23 24 26 28 29 31 34 ")
+("23 24 25 28 29 31 34 38 ");


...
...
..
.


What makes me thinking is this line where its asked IF the user uses the integrated QLB Matrix or if the Matrix is loaded from a given matrix text file.

if ( bUseQLB || csMatrixFile.IsEmpty() == FALSE )

Im very new in C/C++ but ...

"csMatrixFile.IsEmpty() == FALSE" doesnt this mean if I(t)sEmtpy then a boolean true is the result?
(I couldnt find the specific class in the source files thats why Im asking)

So if the user determined as matrix the integrated QLB one then >bUseQLB=true< and if no external matrix has been loaded then >csMatrixFile.IsEmpty() = true< ... did I catch the right?

Cause if yes then even if an external matrixfile is loaded, still the usage of QLB is forced??

But maybe Im too much in Carnaval here in cologne at this moment *lol

[Nic]

@Inc: Look just one line lower and you'll see:

if ( csMatrixFile.IsEmpty() == FALSE )
{
// Load XVID matrix file


So then it checks again that the user has given a matrix file, then loads it if so.

[Inc]

ah, ok .... as said too much carnaval in here ;)

[freelock7]

DGZ, the link doesn't work.
there is a problem...
Sure it's not a critic. I know you're working on it!:o

[Zarxrax]

It's been a long time since there was any release of this great encoder!

I was just wondering a few things.

1.) Is the 0.62 alpha 4 by DGZ the suggested version to use?
2.) Are there any known bugs or issues I should be aware of?
3.) Is a new release planned anytime soon?

Thanks.

[dragongodz]

DGZ, the link doesn't work.
just checked it and its working fine here. see the count down in the upper right ? once that gets low an add covers it, slide the add down and once the countdown ends it turns to the download link.

a mirror aswell incase people do have problems.
http://s12.yousendit.com/d.aspx?id=0LBY9IVIM46IJ19TJ4XIISAOQF

Sure it's not a critic. I know you're working on it!
i didnt takr it as such either. we need people to spot these things so thank you. ;)

1.) Is the 0.62 alpha 4 by DGZ the suggested version to use?
NO. its an alpha and as i said in the alpha 3 post strictly for testing. if it proves to give improvements and not fubar things then a proper release will eventually be done.

2.) Are there any known bugs or issues I should be aware of?
the last 20 odd frames are stuck on quant 9 for some bizarre reason. i want to get RC in general working better before worrying about other things though. easier to concentrate on 1 thing at a time.

3.) Is a new release planned anytime soon?
define soon. :)
there is no point doing a proper release before there is something that makes it worth releasing. thats why i have released this test alpha for example.

[Zarxrax]

Ah, I didn't even realize that you released that yesterday :p
I was looking down the dates of all the posts, and they are all last year, then suddenly yours was yesterday :p

I have some issues to report:
1. When you uncheck the interlaced option, the pulldown option is no longer selectable. However when you first go to advanced options, pulldown will be available, no matter if interlaced is checked or not.
2. Mpeg-1 files dont seem to work right. If I use the built-in splitter in media player classic, the file seems to stall at the very beginning and then catches up pretty quickly. If I use the default splitter on my system the file will barely play at all. It starts playing then suddenly begins freezing for long periods of time. The longer it plays, the longer it will freeze each time it displays a frame.

[dragongodz]

1. When you uncheck the interlaced option, the pulldown option is no longer selectable. However when you first go to advanced options, pulldown will be available, no matter if interlaced is checked or not.
something else for me to look at later. pulldown needs the seq headers marked as interlaced even if encoding progressive if you want to use pulldown. if not this has been shown to cause stuttering playback on hardware dvd players and its also been shown CCE does it that way by default. thats all from memory. :)
so i will have to check if the changes for pulldown set the seq headers to interlaced or not. if they dont then pulldown would have to be limited to interlaced encoding for that reason.

2. Mpeg-1 files dont seem to work right.
i just checked a 30 second clip encoded to 1 pass cbr, 1 pass vbr and 2 pass vbr MPEG1. i tested with just MPC splitter, with MPC splitter and decoders and with external splitter and decoder. no playback problems at all.
try MPC with splitter and filters and see how that goes for you because it sounds more like a problem whatever codec is being used has. you can see what codec it is since it will be listed in the filters (right click on playing video) with MPC. mine used MS mpeg1 decoder 2.0.
if that still doesnt work for you then can you list what decoder is being used and what settings you used to encode. oh and try QuEnc 0.61 but i am guessing you will see the same from that.

[Zarxrax]

My mpeg decoder was just called "mpeg decoder". I switched it to ffdshow and there was some improvement. Playback using mpc internal splitter seemed to work perfectly fine, but using my system default splitter "mpeg I-stream splitter", it was still freezing, but only at about half the rate as before i used ffdshow to decode. CPU is not being maxed or anything.
I blocked that splitter and then it used MainConcept splitter. It seemed to be fine for a while but then it too started stuttering and freezing.
After blocking all 5 million MainConcept splitters that were on my system (damn, it seems like every single adobe app installs a new one), I was left with "Mpeg splitter (low merit). This one actually seemed to play fine with no problem.

But in any case, this isn't how a normal mpeg performs on my system. Just about any of those splitters would play my other mpegs just fine.

At this point, I decided to try QuEnc 0.61. Output was the same. Finally, I tried the "no audio" setting. Finally, it seems to play back perfectly normally. One problem though. The output file is only 30 seconds, and my input was 2:40. It seems it just cut off the last 2 minutes or so.

[dragongodz]

My mpeg decoder was just called "mpeg decoder"
if you select its you will probably find that is the MS decoder.

can you tell me all the settings you used ? also a small sample clip to test would be helpful aswell if possible.

The output file is only 30 seconds, and my input was 2:40. It seems it just cut off the last 2 minutes or so.
try playing the AVS first to make sure that is full length. next check that it only plays 30 seconds and not just says that at the bottom of MPC but plays full time(i have seen that happen and is not QuEncs fault).

[freelock7]

Link ok!
At low bitrate (<3000) Alpha4 has no particular difference with Q061 :same Q, same bitrate, same -good-prediction*.
At high bitrate (>5000) Q061 is undersized (5120 )
Alpha4 has a better high bitrate peak control (8900 against 9600 for Q061 with a maxbitrate set=9200) but it's still undersized (5120).
*based on a clip video of 120"

[dimzon]

thanks. its one of the hardest things to get people to do. ;)


woops. see now thats why i need people to test and with different bitrates etc. :)

this should fix it
http://www.megaupload.com/?d=B3HIFBOZ
All download slots (300) assigned to your country (Russian Federation) are in use.
Please try again later. :devil: :devil: :devil:

[dragongodz]

At low bitrate (<3000) Alpha4 has no particular difference with Q061
well thats good. :)

still undersized
can you please see what sort of quants its giving ?

All download slots (300) assigned to your country assigned to your country (Russian Federation) are in use.
so does that mean 300 people are already downloading that file or is it 300 slots total from megaupload for RF ? be a bit strange if its the second.
i also gave a yousendit mirror in another post so try that aswell.

[freelock7]

For a 5500 VBR
Global Q is the same (2.35 against 2.34) but a high bitrate peak shows that:
Alpha4=8706 (Bitrate)-6(Qlevel)
Q061=9170(bitrate)-5.44(Qlevel)
At low bitrate (VBR=2500)
Quantization is very similar (globalQ=4.90 against 4.89) with a little difference in high bitrate peak:
Alpha4=8309(bitrate)- 6.14(Qlevel)
Q061=8.360-5.88

[Zarxrax]

Ok, I've done a little more testing.

The problem seems to be with the bitrate used. If I set the bitrate to 1000 (max bitrate 9800), the files seem to come out fine and work on all my splitters. If I raise the bitrate for the mpeg-1 to 2000 though, all hell breaks loose.

[snherbst]

Hi

I've actually have a question regarding MPEG4. MPEG4 supports a varity of audio formats the list includes .mp2 and mp3. So why is there not other formats supported in QuEnc than AAC?

http://forum.doom9.org/showthread.php?t=62723
http://gpac.sourceforge.net/index.php
http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm

[Zarxrax]

Ok, some more possible bug reports, some questions, and some suggestions.

I am not only getting strange playback errors with MPEG-1 files encoded from QuEnc, but also with MPEG-2 files. It seems there may be some relation with the quantizers used. An mpeg-2 encode using constant quantizer 1 reported a running time of 29 seconds (although the source is 20 seconds). Although it had a reported running time of 29 seconds, it would abrubtly end at about 20 seconds. Encoding again with constant quantizer 2 created a file with the correct running time.

Encoding a quant 1 video as "seperate passes" and then multiplexing them outside of quenc resulted in a correct file. I urge you to check out the multiplexing code in quenc to see if any problems exist.


Next, using trellis with quant 1 causes artifacts. Probably outside of your control, but I had heard this was supposed to be fixed?


Now some questions and suggestions for the interface.

Why is Extreme and Slow settings grouped with GOP and Bframes? This doesn't make logical sense to me.
Since extreme and slow enables trellis by default maybe trellis could be removed altogether? Then move extreme to the main form, replacing trellis. Unless someone likes to use trellis without extreme, I guess.

Next, why is GOP default at 12? The tooltip says for dvd these should be 15 or 18, so wouldnt one of those make a more logical choice for a default?

Finally, is a gui color selector really necessary? I don't really object to it, but it seems unneccessary and would simplify the gui further by removing it.

[dragongodz]

freelock7 - thanks. its good 0.62 alpha is now so close to 0.61 as the earlier 0.62 alphas undersized worse. now i just have to see if i can push it higher without breaking anythjing. ;)

MPEG4 supports a varity of audio formats the list includes .mp2 and mp3. So why is there not other formats supported in QuEnc than AAC?
i have a really easy out for this ... its Nics fault. :)
Nic added mpeg4 for converting video to play on his PSP. i will look at adding mp3 atleast later. however this is not what i am working on at the moment so it wont be done yet. please also remember that this is the first version that even has mpeg4 and is an ALPHA so its not going to be complete and may contain bugs. this is where testing by others proves helpful to find such problems so they can be fixed and then other things added.

The problem seems to be with the bitrate used. If I set the bitrate to 1000 (max bitrate 9800), the files seem to come out fine and work on all my splitters. If I raise the bitrate for the mpeg-1 to 2000 though, all hell breaks loose.
well i tested with 2500 and plays 100% fine here. i suspect its either your hardware(what cpu do you have ?) or software thats causing problems. without knowing what settings you are using to encode i can not 100% replicate what you are doing of course. even a small encode that shows problems would be something to see if it plays ok on mine or not.

reported a running time of 29 seconds (although the source is 20 seconds). Although it had a reported running time of 29 seconds, it would abrubtly end at about 20 seconds. Encoding again with constant quantizer 2 created a file with the correct running time.
so in other words it played the correct time irrelevant of what the reported time was.
i actually came across this ages ago and reported it in a thread. the thing is i found, after much testing, that it was decoder dependant. that is some decoders reported the wrong time and others didnt. also with one you could set use PTS or frame count, when set frame count it was way out but PTS was nearly right.
i was also able to replicate the exact same problem with other encoders so decided it was really the decoders problem trying to guess the correct total time. nothing i have seen has made me change my opinion on that yet.

Next, using trellis with quant 1 causes artifacts. Probably outside of your control, but I had heard this was supposed to be fixed?
this should only generally happen using custom matrices. there is a way to reduce this from happening but since it reduces the precission the ffmpeg guys rejected it, as they do so much its not funny. if i remember i will fix that when its time for a proper release.

Since extreme and slow enables trellis by default maybe trellis could be removed altogether?
actually no extreme should not enable trellis as it did in early QuEnc versions. this was already meant to be changed versions ago.

Next, why is GOP default at 12? The tooltip says for dvd these should be 15 or 18, so wouldnt one of those make a more logical choice for a default?
another easy out ... Nics fault. he decided the defaults. :D
though 12 is not a bad default really. the 15 and 18 are actually max numbers.

Finally, is a gui color selector really necessary? I don't really object to it, but it seems unneccessary and would simplify the gui further by removing it.
Nic likes the red while i like grey. others may like other colours to more match their desktop. its not a big thing so really doesnt hurt. so its in for the forseeable future.

[Zarxrax]

so in other words it played the correct time irrelevant of what the reported time was.
i actually came across this ages ago and reported it in a thread. the thing is i found, after much testing, that it was decoder dependant. that is some decoders reported the wrong time and others didnt. also with one you could set use PTS or frame count, when set frame count it was way out but PTS was nearly right.
i was also able to replicate the exact same problem with other encoders so decided it was really the decoders problem trying to guess the correct total time. nothing i have seen has made me change my opinion on that yet.


You replicated the problem on other encoders? Which other encoders does this happen with? I've never seen it from anything else besides Quenc. Plus I have hundreds of mpeg files and I have never seen these issues aside from my own encodes made from quenc.

And if its a problem on the decoding end, it happens with at least half of the decoders I have tried. Perhaps its more of a case of some decoders being more "strict" in what they will accept than others? Plus, note how I found that muxing the video in a seperate program left me with a fine stream, while muxing in quenc did not.

In any case, when someone chooses to make an encode to MPEG-1, they generally choose that because its a universal format that can be played practically anywhere, correct? Well if it can't be played properly by a lot of decoders out there, then there is a serious problem.

[Zarxrax]

Ok, I think I've FINALLY got some real insight into what the problem is. I got ahold of an old copy of tmpgenc, and I'm using it to mux the files now. It reports buffer underflow errors when I use it to mux the streams. Lots of them. I'm sure this is the main problem. Only by significantly lowering the bitrate will tmpg mux without complaining about buffer underflows.

I also found a program called Multiplex that can mux mpeg-1 files, and it too complains about the buffer underflows.

Hope this helps.

[Mug Funky]

yo, just been trying the alpha 4 out for a bit. it's hitting average BR perfectly (unless the file is all Q1 or max BR, but i can't expect better than that obviously), and it's not underflowing. that's on a wide range of higher bitrates - everything from 4000 to 8500 (with max 8500 each time).

from looking at bitrate scans though, it looks like bitrate distribution could stand to be averaged over a longer period (i don't know how long it is right now, but it seems to compensate very quickly for hard scenes). also, it might do well to start with a lower quantizer - it tends to start at around 3, when it could safely start a little lower, especially if there's a fade-up at the start (these get hit rather hard :().

all in all, i think it's ready as it is to go beta or higher. it's almost perfect 1-pass RC.

[edit]

maybe the averaging period could depend on the playing length of the input? does quenc have access to that kind of info? that would mean it could be conservative and compensate quickly if the input length is short (like 1-2 mins), and react slowly if the input is long (like 80 mins or more). hell, this might even be happening already...

[mean]

For the last frames stuck at Qz=9

if(framenum<_nbFrames-_roundup)
{
...
}
else
{
if(q<9) return 0;
}

Since we don't have a next half gop to check vbv, it is encoded at cq=9. Could probably use the last Qz as since there is not infra coming in, the risk & damage caused by underflow would be light.

[dragongodz]

It reports buffer underflow errors when I use it to mux the streams.
actually this does make some sense. mpeg1 was never made for high bitrate, for example for dvd mpeg1 is limited to 1700(ish) total muxed bitrate from memory. i will have to dig out the specs some time and look at exactly what it says.

Since we don't have a next half gop to check vbv
23 frames(PAL encoding) is more than half a GOP. :)
actually from memory the first period is 1 second so that actually makes sense. i will have to look at and play with that later aswell.

EDIT:
of course a better solution would be to encode this last section to the relevant percentage of the target bitrate. so for example if you have 90% of 1 seconds worth of frames you would target those last frames to be 90% of real target bitrate. you should never need to worry about underflows with that. just my opinion anyway. ;)

[Zarxrax]

By the way, my interest in QuEnc is because I am working on an MPEG1/2 guide for a site I frequent, and I would prefer to use a nice free encoder such as QuEnc as opposed to a commercial one like TMPGenc. I just can't recommend a method that might be producing files that won't work properly, when a another method has been working fine for years.
So I hope I don't come across sounding too demanding or anything :D

[dragongodz]

I just can't recommend a method that might be producing files that won't work properly
the problem is replicating problems. that is you say your playback is bad while i can play it fine. is this then a problem with QuEnc or could it be something more specific to your pc ? so to try and replicate it exactly i need information such as whats your cpu, what exact settings are you using, can you provide a small sample that show the problem etc. i have asked these things several times already but there comes a point where i will simply stop asking when they are not answered.

[Zarxrax]

Ok, sorry, here is a sample file I have encoded: http://zarxrax.kicks-ass.net/quenc_test.mpg
(16MB)

Settings:
Codec: MPEG-1
Constand Quant: 2
Use VBR
High Quality
18 GOP Size
2 Max B-frames
Force Closed GOP
Auto Max Bitrate
4:3 Aspect Ratio
Mux Profile: MPEG-1 System
Audio Codec: MP2
Audio Bitrate: 224

Edit: Oh, and my CPU is an old Pentium 4, 2.26ghz.

[dragongodz]

had a quick look and yes that stutters a bit. then again the average bitrate is 6305507 and maxes at 10941323 and thats just video. so not the sort of bitrate mpeg1 was designed for as i said.

i will however look at making some changes that may help fix that anyway. unfortunatly some real life things have come up which means most of this week i am going to be away from my pc.

[Mug Funky]

constant quant modes don't respect max bitrate settings (unless something's changed recently?)... so there might be a difficult part in that video that's causing underflows at q2. most software splitters wont care about this, but some could if they're strict about compliance.

try set avg rate = max rate, then you'll essentially get CBR without padding.

[Zarxrax]

Well, its not even a problem with just using high bitrate like that.
Here is another file I encoded, exact same settings, only I set the bitrate to 3000.

http://zarxrax.kicks-ass.net/quenc_test3000.mpg

This file also stutters badly and reports the playing time wrong. Even VLC player doesnt handle it properly.

In contrast, I have a nearly 10mbps mpeg1 file sitting here that someone made on a different encoder, and I have absolutely no problems playing it. If its as you say, and the bitrate is simply too high, then it makes no sense that my 3000kbit file will break down, while a much higher bitrate file will play fine.

In fact, I must have at least 20 to 30 mpeg files that use higher average and peak bitrates than this file I am posting now, and there are no problems with any of them.

Whats more, I can encode the file in tmpg with an EVEN HIGHER bitrate than that first file was, and it still plays properly.

[dragongodz]

Well, its not even a problem with just using high bitrate like that.
if you knew what else i was thinking then you would know that yes there is more to it than that but it is the high bitrate being used when its not expected to thats the heart of the problem. :)

In contrast, I have a nearly 10mbps mpeg1 file sitting here that someone made on a different encoder, and I have absolutely no problems playing it.
yes and even without looking i think i know what they are doing. once i get a chance to confirm it then i can make the needed changes aswell. why wont i say what i am thinking ? well i want to be sure i am right first of course. ;)

reports the playing time wrong
i talked about that before. it is a different subject.

[Sagittaire]

QEnc use libavcodec librairies for MPEG2 encoding. Libavcodec use very advanced fonctionnality like:
- RDO for MB decision
- Adaptative Bframe
- Multi-pass (solve some overflow problem)
- ratio/offset for bframe
- Adaptative Quantisation with various masking like lumimasking
- Rate distorted optimal coded block pattern
- Rate distorted optimal quantization for each macroblock

These setting done very better compression efficiency (Higher metric with smaller size for same constant quant encoding).

Why not use these setting in QEnc ... ???

[dragongodz]

just a quick note about the problem Zarxrax is having. i have had him test a version with a change that does similar to what both CCE and MainConcept do. it does improve playback. he said he still has some problems with some players though so i will try to look at that later aswell. just so people know things are going on. :)

Why not use these setting in QEnc ... ???
some of those types of settings are used for extreme & slow option. notice the speed of it though ? i could also turn diamond size up to 6 and increase quality but the gain is small compared to a huge speed loss so not really worth it. i will probably tweak the extreme setting though and see what can be hopefully gained without too much more speed impact. its just not high on my priority list at the moment.

[DarkFoon]

@DGZ
What language is QuEnc programmed in?

Also, couldn't there be a place in the GUI for the user to enter "custom" LAVC options to be passed to the encoder? (kinda like the DivX encoder has the command-line box)
For example, if somebody didn't care about the speed tradeoff and wanted diamond size 6, they could set it there.

Just an idea, I can understand the reasons not to put that in (cluttered GUI, newbies complaining about things not working, etc..) But like any project with something like that, just say it's unsupported and tell them to shutup. :devil:
I, while I like to use QuEnc, don't like being "protected me from myself" which is how I feel lacking more control over the encoding process. Now you'll probably tell me to go use Mencoder, and I don't like Mencoder, so I'm done.
Just my .02$

[dragongodz]

What language is QuEnc programmed in?
C/C++

Also, couldn't there be a place in the GUI for the user to enter "custom" LAVC options to be passed to the encoder? (kinda like the DivX encoder has the command-line box)
For example, if somebody didn't care about the speed tradeoff and wanted diamond size 6, they could set it there.
the aim of QuEnc though is to be both simple and good. to add the ability to use any and all settings is asking for lots of questions. if people are really that worried about getting the smallest quality difference,which they would probably never see with actual playback, even though it may take a week to encode then they surely should try using something like mencoder or ffmpeg and everything that implies. ;)

while I like to use QuEnc, don't like being "protected me from myself" which is how I feel lacking more control over the encoding process.
the fundamentals are there though so you can trade some speed for a bit extra quality etc. adding in lots more settings will not suddenly make encodes better and infact can cause results to be worse because a lot of people do not know what they are really doing, even though they think they do. and no i didnt mean you by that.

Now you'll probably tell me to go use Mencoder, and I don't like Mencoder, so I'm done.
maaaate, would i do that ? :devil:

[DarkFoon]

the aim of QuEnc though is to be both simple and good. to add the ability to use any and all settings is asking for lots of questions.
...
the fundamentals are there though so you can trade some speed for a bit extra quality etc. adding in lots more settings will not suddenly make encodes better and infact can cause results to be worse because a lot of people do not know what they are really doing, even though they think they do.

Point taken.

and no i didnt mean you by that.

Of course not, I wouldn't have ever thought that. (no sarcasm) (really I mean it. stupid internet and it's inability to carry tone!)

As soon as a few of the bugs in QuEnc get worked out(fades getting hit too hard, etc...), I'll be using it for my DVD creations.
And, this is the best part, I may be able to help contribute in the future: ("oh no!" I hear you thinking :devil: ) I am taking a C++ class this term. Sure, I won't be C++ master in 10 weeks, but I'll at least be able to read the source and know whats going on, and maybe even help.

[dragongodz]

(no sarcasm) (really I mean it. stupid internet and it's inability to carry tone!)
ye i know what you mean, which is why i had to say i was not meaning you.

I am taking a C++ class this term. Sure, I won't be C++ master in 10 weeks, but I'll at least be able to read the source and know whats going on, and maybe even help.
any help making QuEnc better is always welcome. as for being a C++ master, well i am self taught so am no master either. now you know why i work so slow. :)

[DarkFoon]

cool!

Now, I've forgotten where to get QuEnc or its source code (I guess at the same place, right?). Maybe a link?

[dragongodz]

Maybe a link?
hmm those last links i gave in this thread should still be ok. however i have made a few little tweaks etc so i will bundle up the latest source code etc and PM you a link tonight.

dont anybody else bother to ask since the changes etc are still very experimental. i will give a proper link here when i am interested in having people test out a binary.

[Rockas]

Hi dragongodz and nic!
During the tests on my SynthEditor I found a few strange behaviour with QuEnc... I'll try to present a full report when I enable video encoding with QuEnc it has to do with size predictions but that is not my main question today :)

on syntheditor I'm using QuEnc to take care of the Audio encoding (video encoding will come next) and that brings my question.... are you thinking about enabling 5.1 AC3?

another question
is it possible to encode video and audio at the same time but output them separate (not program stream)?

[Mug Funky]

yep, there's a mux option "separate passes". does video then audio.

alternately you could simply run it twice (commandline perhaps) with either "no video" or "no audio" modes. this is helpful for long batches - you feel better about the encode when all the audio gets done at super speed before the long hard slog at the video :)

[Rockas]

yep, there's a mux option "separate passes". does video then audio.

alternately you could simply run it twice (commandline perhaps) with either "no video" or "no audio" modes. this is helpful for long batches - you feel better about the encode when all the audio gets done at super speed before the long hard slog at the video :)
The problem is that the "separate passes" is not on th CLI documentation... or... I'm not seing right :) - that can happen to :D

[dragongodz]

The problem is that the "separate passes" is not on th CLI documentation
your right its not. only things like dvd/svcd/vcd/novideo etc are. i will try and remember to add seperate for the next version though.

are you thinking about enabling 5.1 AC3?
it isnt ? hmm i just fed it a clip with 5 channel audio and it encoded to ac3 as 5 channel. loaded in to MPC and checked it properties and it says 5 channel audio aswell. disabled MPC internal ac3 decoding and set ffdshow to decode and it also reported 5 channel audio.

I'll try to present a full report when I enable video encoding with QuEnc it has to do with size predictions but that is not my main question today
dont forget to mention which version of QuEnc since its already known to undersize when low quants(such as 1) are needed. the 0.62 alpha i did should improve that and i have actually already done better again with an internal version. still not anywhere near as good as it should be yet though.

[Rockas]

it isnt ? hmm i just fed it a clip with 5 channel audio and it encoded to ac3 as 5 channel. loaded in to MPC and checked it properties and it says 5 channel audio aswell. disabled MPC internal ac3 decoding and set ffdshow to decode and it also reported 5 channel audio.
Sorry... I haven't check that out :(
I was testing the conversion between formats (mpa/mp2 to AC3 mainly) ... I guess the conversion 2ch to 5.1 isn't possible (at this point), right?

dont forget to mention which version of QuEnc since its already known to undersize when low quants(such as 1) are needed. the 0.62 alpha i did should improve that and i have actually already done better again with an internal version. still not anywhere near as good as it should be yet though.
That's why I wasn't specific about it... I haven't tested the latest "test" release, yet... on my tests I was using 0.61.

[Rockas]

@dragon
where can I get the latest release?

[dragongodz]

I guess the conversion 2ch to 5.1 isn't possible (at this point), right?
well QuEnc wont do that internally just as it wont resize etc. there is no need to when its getting its source from avisynth which can do these things. you may be able to turn stereo to 5.1 using something like getchannel() and getting the 2 stereo channels multiple times to fake it. you would probably have to ask more about this in the avisynth sections though as i am no expert on this. :)

on my tests I was using 0.61.
you should give the 0.62 alphas a test aswell. the last one for example should have been an improvement on 0.61 and alpha5 should be a bit better again. also it helps me track if things are getting better or worse and what needs improving etc.

where can I get the latest release?
QuEnc 0.62 alpha5 for peoples testing now available here
http://www.mytempdir.com/519388

things to test for those willing.
1. sizing and max bitrate not exceeded etc
2. last frames at constant Q, that is they shouldnt be now :)
3. -mpeg2mux separate (cli option for Rockas)

[Zarxrax]

Can there be an option to revert the settings to default?
Or is there a registry key where the settings are stored?

[Fishman0919]

dragongodz, the ver from the link is saying 0.6.1.4.... testing on a movie that only needs to be sized alittle... avg bitrate 5123k w/max at 6000k.... just checking if it was a slip.

[dragongodz]

Can there be an option to revert the settings to default?
matbe later. i mean its not too hard to just set the settings you want is it ?

Or is there a registry key where the settings are stored?
settings are stored in HKEY_LOCAL_MACHINE/SOFTWARE/QuEnc

the ver from the link is saying 0.6.1.4
yes i didnt change it. not something i was thinking about with these alphas. :)

testing on a movie that only needs to be sized alittle... avg bitrate 5123k w/max at 6000k
great. if you could also compare what 0.61 does on the same source that would be good. that way i can tell which is doing things better etc.

[Mug Funky]

hey cool, another alpha :) i'll have to check it out as soon as i get home.

[Rockas]

@dragongodz
Got it! Thanks
I'll let you now about my tests... not many as I don't have many avilable time... but I'll give you the results of the tests using SynthEditor
I usually use two prediction sizes routines... one for Generic Mpeg and Another for DVD (need overheadt for NAVPACKS, etc)... with QuEnc 0.61 there is a little undersize... HC is hitting the target with an impressive precision (on the tests I made until now)... have you tried to get some tips from Hank?

[Rockas]

Ok... here you have it:
Using last Alpha5
I'm using SynthEditor for this. Quenc Encodes audio too.

Clip Data:
Width=704
Height=576
AspectRatio=4:3
FrameRate=25
Duration -> 569frames (aprox. 00:00:23)
Target Size -> 10MB (Audio + Video)

AC3 Size (after QuEnc Encode) -> 1.04MB

MPEG PROFILE
Calculated bitrate=3302 (Shown by DGIndex=3253)
VideoSize -> 8.79MB
Total Size (after multiplexing) -> 9.94MB

DVD PROFILE
Calculated bitrate=3253 (Shown by DGIndex=3201)
VideoSize -> 8.66MB
Total Size (after multiplexing) -> 9.95MB

For multiplexing I used mplex 2.0.0 using the "Generic MPEG" and "DVD" Profiles.

As you can see... there's a little undersize. Maybe this is caused by the avrg bitrate (reported by DGIndex) being smaller than the one programmed?
I haven't tried "One Pass with Q" 'cause I haven't that feature on SynthEditor yet :)

Next I'll try QuEnc 0.61 :)

Now... was this post colorfull or what :D

[Rockas]

Using QuEnc 0.61

MPEG PROFILE
Calculated bitrate=3302 (Shown by DGIndex=3268)
VideoSize -> 8.59MB
Total Size (after multiplexing) -> 9.75MB

DVD PROFILE
Calculated bitrate=3253 (Shown by DGIndex=3221)
VideoSize -> 8.46MB
Total Size (after multiplexing) -> 9.76MB

Looks like it gets a bigger undersize... meaning... you are on the right path my friend :)

[Rockas]

Oh! by the way... the "-mpeg2mux separate" doesn't seem to be working through the cli... but don't loose your time on this yet... I'll have to find a way of predicting the final audio size before I can make it work for me :)
At this point I do the audio encoding first then I calculate the Video size after knowing the Audio file size... I think this is more accurate.

[ricardo.santos]

Hi everyone!
dont know if its a bug or not but when opening an avi file in folder A it wont let me convert to Mpeg2 into the same folder, same thing with mpeg1 and snow, it will let me convert to mpeg4 though.

it says "could not write to destination directory"

im trying the latest beta

[dragongodz]

meaning... you are on the right path my friend
thats good to hear. :)

the "-mpeg2mux separate" doesn't seem to be working through the cli.
hmm i did a simple
quenc.exe -i file.avs -o outfile.m2v -mpeg2mux separate
that produced an outfile.m2v and outfile.ac3 in the 1 test i did. will play with it over the weekend and see if i can get it to fail etc.

dont know if its a bug or not but when opening an avi file in folder A it wont let me convert to Mpeg2 into the same folder, same thing with mpeg1 and snow, it will let me convert to mpeg4 though.
will look at this too.

[freelock7]

Fine.
At low bitrate, prediction is correct.
At VBR=5000, prediction=4876 (very good!).
High bitrate peak very well controled.;) ;) ;)

[Rockas]

hmm i did a simple
quenc.exe -i file.avs -o outfile.m2v -mpeg2mux separate
that produced an outfile.m2v and outfile.ac3 in the 1 test i did. will play with it over the weekend and see if i can get it to fail etc.
I'll post my command line... maybe there's something wrong with it... as soon as I can I'll post it.

[Rockas]

@dragongodz
Sorry... I just noticed that QuEnc has the option to encode mp3!?!?!?
is it available through cli?

Another (probably noob) question... If I select 2 passes VBR encode for audio only will it make any effect? Will the result be different (quality)?

[Rockas]

Well... let me answer my Own questions :D
Sorry... I just noticed that QuEnc has the option to encode mp3!?!?!?
is it available through cli?
No... mp3 is not available from cli, YET ;)


If I select 2 passes VBR encode for audio only will it make any effect? Will the result be different (quality)?
It doesn't matter if you select 2 passes... when encoding audio only, QuEnc will perform one pass only :)

[dragongodz]

mp3 is not available from cli, YET ;)
hahaha well it is new and of course only for use with snow and mpeg4 outputs.

sorry i didnt get to answer your questions first but ... it would have been a litle hard while i was asleep. ;)

[Rockas]

Nah! don't worry... I know thay you Australians like to sleep 'til late :)

by the way... I forgot to post my cli :(
let's see if I remember it when I get home :)

[manolito]

Just for clarification: Am I correct to assume that all the tweaks of the current Alpha versions only apply to 2-pass VBR?

I just did a 1-pass VBR encode with Alpha 5 and compared it to 0.61 stable, and everything seemed pretty identical. File size was the same, and Muxman reported the same peak bitrate.

Cheers
manolito

[Mr_Odwin]

I've only tested with one 20 minute file using 1-pass vbr and the newer version didn't undersize as much. The difference was considerable.

[dragongodz]

Just for clarification: Am I correct to assume that all the tweaks of the current Alpha versions only apply to 2-pass VBR?

most of the work has been on 2 pass since that will in general i think be the more used mode. there are a few little tweaks to 1 pass aswell though. of course its dependant on the footage and bitrate used etc etc etc but it should also help with any undersizing versus 0.61 aswell.

let's see if I remember it when I get home :)
:goodpost: :eek:

[manolito]

there are a few little tweaks to 1 pass aswell though. of course its dependant on the footage and bitrate used etc etc etc but it should also help with any undersizing versus 0.61 aswell.
Yes, it looks like you found a very good balance between reaching the target size and not getting untolerable bitrate spikes even in 1-pass mode.

I just encoded "The Transporter" with 0.61 and 0.62 Alpha5 using 1-pass VBR, and the results are quite different. Average bitrate is 6.425 kbps, the movie is highly compressable. I never succeeded encoding it with FreeEnc 0.31, even lowering max bitrate to 7.000 and restricting average bitrate to 5.800. Even with these settings MuxMan would refuse to mux it due to buffer underruns.

Here are the results for QuEnc 0.61 and 0.62 Alpha5 (Max bitate 8.000, Standard Matrix, 1-pass VBR):

0.61
-----
Size (including original AC3 audio): 3.936.956.416 bytes
Peak bitrate reported by MuxMan: 10.649.600 kbps


0.62 Alpha5
-----------
Size (including original AC3 audio): 4.637.456.384 bytes
Peak bitrate reported by MuxMan: 11.093.333 kbps

Even with this slightly higher peak bitrate MuxMan had no complaints about the encoded file. So I am very happy with Alpha5...

Cheers
manolito

[siddharthagandhi]

Hey Nic just a graphical problem...the progress bar is kind of hard to see....you might want to fix that?

Different color for the progress bar...?

I mean, white on gray isnt that easy to see...

[siddharthagandhi]

And one more thing. its a great encoder. At a low 5 mbps bitrate it gives like double what Nic's WM encoder can give me at the same bitrate, or HC encoder at same bitrate.

[Koti]

Different color for the progress bar...?

Advanced Options / GUI Apperance /
Just change the sections to any color you like

[hellfred]

by the way... I forgot to post my cli :(
let's see if I remember it when I get home :)
__________________
Warning!!!
Too much sex is not healthy. It causes amnesia and other problems that I can't remember!!!
No text

[Rockas]

@dragongodz
Sorry for not having post my cli using -separate yet... I'll have to redo the code to get it again (yes I could try it mannually but that's not the same... it didn't worked using my code ;))

My new post is just for making a new bug report (or a new stupidity from my part)... when encoding AC3 5.1 (6) channels I'm getting wrong (how can I say this) channels distribution (hope you can understand my "portuguenglish" :D... I haven't tested this on a 5.1 system yet, but on my Laptop seems like I'm getting the center channel on my right speaker and on my left speaker I get "background sounds" - these could be the left rear channel (I'm just gessing about left speaker but could QuEnc being "rotating" the channels?).
Loading the avs using "ac3filter" and nicaudio.dll (the latest build by dizmon) it plays just fine... the supposed rotation only happens after AC3 (6channels - 5.1... 2ch seems to be fine)Encoding.
Do you need some kind of samples to check this out?

edit: typo

[DarkFoon]

@Rockas
I don't have a 5.1 setup myself, but I have noticed that when I make a 5.1 ac3 file, sometimes the decoder doesn't know what to do with the extra channels because I only have a 2 speaker setup. So sometimes, it jumbles them up and puts the rear channels up front, and the regular up front channels all go to one side, etc.
I'm not saying that Quenc isn't having a problem (it could be) I'm just offering another scenario that might explain what you're hearing.

[Rockas]

Nah! I don't think so :)
I've made dozens of tests just to make sure... it only happens with QuEnc's AC3 5.1 encoded files.

I really like to make as many tests as I can before submiting anything at all - at this point I'm testing one or two bugs more... but I'm keeping testing until I'm sure :D

Anyway.. thanks for your suggestion... that gives me a reason for a few more tests :)

[dragongodz]

Even with this slightly higher peak bitrate MuxMan had no complaints about the encoded file.
cool. however people should be aware 1 pass does still go over the set max sometimes. however more work on that will have to wait until i am happier with things like 2 pass etc.

when encoding AC3 5.1 (6) channels I'm getting wrong (how can I say this) channels distribution (hope you can understand my "portuguenglish" :D
i assume you mean the channel mapping.
maybe this will help
http://forum.doom9.org/showthread.php?p=759547#post759547

if so i will look at having the remapping done automatically, assuming i can with libavcodec. :)

[DarkFoon]

I've made dozens of tests just to make sure... :)
At least somebody knows how to properly isolate a problem and submit a useful bug report!
I'm sorry I assumed you didn't test.

[Rockas]

assume you mean the channel mapping.
maybe this will help
Yes that helped... well kind of :)
here's the original script:
LoadPlugin("D:\Meus documentos\VISUAL\VideoEditor\tools\dgindex\DGDecode.dll")
LoadPlugin("D:\Meus documentos\VISUAL\VideoEditor\tools\PlugIns\nicaudio.dll")
Video = MPEG2Source("D:\Meus documentos\VISUAL\VideoEditor\temp\VideoFile.d2v")
Audio = DelayAudio(NicAC3Source("D:\Meus documentos\VISUAL\VideoEditor\temp\VideoFile T01 3_2ch 448Kbps DELAY 80ms.ac3",6), 0)
Clip1 = AudioDub(Video,Audio)
LanczosResize(Clip1,720,416)

The corrected one:
LoadPlugin("D:\Meus documentos\VISUAL\VideoEditor\tools\dgindex\DGDecode.dll")
LoadPlugin("D:\Meus documentos\VISUAL\VideoEditor\tools\PlugIns\nicaudio.dll")
Video = MPEG2Source("D:\Meus documentos\VISUAL\VideoEditor\temp\VideoFile.d2v")
Audio = DelayAudio(NicAC3Source("D:\Meus documentos\VISUAL\VideoEditor\temp\VideoFile T01 3_2ch 448Kbps DELAY 80ms.ac3",6), 0)
Audio2=GetChannel(Audio,1,3,2,5,6,4)
Clip1 = AudioDub(Video,Audio2)
LanczosResize(Clip1,720,416)

Now the strange thing (or maybe not :)) is that if you run the Script directly on Media Player... it gets the problem of the first script after QuEnc encode... I guess this is normal 'cause we are swaping the order of the channels right?
if so i will look at having the remapping done automatically, assuming i can with libavcodec.
That would be great! :)
If you can do that there's no need for a script for a Preview mode and another one for encoding ;)

At least somebody knows how to properly isolate a problem and submit a useful bug report!
I'm sorry I assumed you didn't test.
Well... I sure have my moments too :D ... I can be pretty stupid when I want to :D

[OT]
@dragongodz
When will you move to Europe? The "GMTs" are a really pain :D

[Rockas]

Finnally! :D
Here you have my generated cli
"D:\Meus documentos\VISUAL\VideoEditor\Tools\QuEnc\QuEnc.exe" -i "D:\Meus documentos\VISUAL\VideoEditor\temp\Video.avs" -o "D:\Target\Video1.m2v" -b 4124 -maxbitrate 9000 -2 -hq -dc 8 -notrell -noscene -interlaced -tff -aspectratio 16:9 -mpeg2mux separate -audiocodec AC3 -audiobitrate 384 -auto -close
This one returns a "0" lenght AC3 file :(

The AVS I'm calling is the last one of a scripts sequence... can this be the problem? Let me explain... QuEnc is supposed to encode a script called "Video.avs" - here you have it:
S0=Import("D:\Meus documentos\VISUAL\VideoEditor\temp\Clip0.avs")
S0

ConvertToYV12(Interlaced=True)
as you can see... this scripts imports the "Clip0.avs":
# Created by SynEditor - Rockas 2006-03-21 10:58:40

Clip0 = Import("D:\Meus documentos\VISUAL\VideoEditor\temp\VideoFile.avs")
Trim(Clip0,004550,005050)
And at last this one imports "VideoFile.avs":
# Created by SynEditor - Rockas 2006-03-20 17:05:33

LoadPlugin("D:\Meus documentos\VISUAL\VideoEditor\tools\dgindex\DGDecode.dll")
LoadPlugin("D:\Meus documentos\VISUAL\VideoEditor\tools\PlugIns\nicaudio.dll")
Video = MPEG2Source("D:\Meus documentos\VISUAL\VideoEditor\temp\VideoFile.d2v")
Audio = DelayAudio(NicAC3Source("D:\Meus documentos\VISUAL\VideoEditor\temp\VideoFile T01 3_2ch 448Kbps DELAY 80ms.ac3",6), 0)
Clip1 = AudioDub(Video,Audio)
LanczosResize(Clip1,720,576)
ConvertToYUY2()

Anyway... If I encode Video or Audio seperatly it works fine so I think I'm doing something wrong on the CLI.

As I said before... this is not very important at this point... it can go for the "ToDo" list :) ... you have more important stuff to take care of... (clue: MP4... mp3 on the cli? :D)

Thank you.

[Rockas]

Ok... here's a few more bugs (or not :D)!

1st - if I feed QuEnc (via GUI) with the script "VideoFile.avs" (see above) and select "novideo" as muxprofile to output an mp3 I receive a Windows error and QuEnc terminates :(

2nd - if I choose output as MP4 on QuEnc GUI and then I try to encode (via CLI) the audio (still using my scripts above) to AC3... QuEnc terminates... it seems like not being updated with the new parameters from the CLI and still try to use the last ones inserted on the GUI...
Video Encoding goes fine though.

edit:
[Off Topic]
- Am I the only one using QuEnc, now? :D

[manolito]

[Off Topic]
- Am I the only one using QuEnc, now?
No, you certainly are not the only one! I have been using avcodec based encoders (QuEnc and FreeEnc) for a long time. While I was still doing very low bitrate SVCD conversions it was easy to see that avcodec based encoders delivered better quality than CCE. Today I mostly do AVI2DVD conversions of analog TV captures, and I found that 1-pass VBR encodes with QuEnc give me the best balance between quality and speed (I do have a slow computer by today's standards). But since I always use QuEnc together with DVD2SVCD or sometimes DVDRebuilder, QuEnc's audio capabilities are nothing I can comment on.

cool. however people should be aware 1 pass does still go over the set max sometimes. however more work on that will have to wait until i am happier with things like 2 pass etc.
I believe that there is not much room for improvement for 1-pass VBR mode. IMO bitrate spikes above the specified max bitrate can never be completely avoided in 1-pass mode, and as long as the VBV buffer is handled correctly, this does not really hurt. I think it was Sir Didymus who mentioned it first (he has access to professional verification software), and I fully confirm what he said: If MuxMan does not complain about the encoded video stream, then the resulting DVD will be compliant. Any cheapo standalone will play it without hickups. Period.

To be absolutely sure I just did a torture test with Alpha5 in 1-pass VBR mode. I encoded one high action chapter of the movie "The Transporter" with max and average bitrate both set to 9.500 kbps. MuxMan reported: Bitrate - avg: 9301139, min: 4130133 (lba 162), max: 11946666 (lba 40814). No buffer problems, and the DVD plays just fine in 3 standalones I have access to.

So all I can say about Alpha5 is: Please leave 1-pass VBR mode as it is now, it can't get much better. And of course a big Thank You!


Cheers
manolito

[Rockas]

No, you certainly are not the only one!
Of course not :)
Sorry... I forgot the smiley on that question :D
Fixed that.

[dragongodz]

you have more important stuff to take care of... (clue: MP4... mp3 on the cli? )
hahaha do you realise how much work you are giving me if i am expected to add everything to the cli in one go ?

muxprofile to output an mp3 I receive a Windows error and QuEnc terminates
well its not supported via cli yet so nothing would surprise me that way.

if I choose output as MP4 on QuEnc GUI and then I try to encode (via CLI) the audio (still using my scripts above) to AC3... QuEnc terminates... it seems like not being updated with the new parameters from the CLI and still try to use the last ones inserted on the GUI...
did you also try setting it to mpeg2 with "-mpeg2" since thats where the ac3 encoder is ?

Please leave 1-pass VBR mode as it is now, it can't get much better
well of course i wouldnt keep any changes that were not an improvement and as i said i have no plans to play with this yet. just look at all the work Rockas keeps giving me. ;)

finally. i am currently sick so spending most of my time in bed. will get back to work on QuEnc when i am better. thanks to everyone thats testing and reporting what they find.

[dragongodz]

Am I the only one using QuEnc, now? :D
ye i know you are joking. still 53 downloads of alpha 5 isnt bad. especially when you consider it is an alpha which scares many away. also the download link is hidden away inside this thread and not at the first post. full releases get thousands of downloads. look at the visitor counter on my pcpages page, its over 29,000 and still slowly(now) climbing and the page only has QuEnc 0.54 and Rejig on it. :)

When will you move to Europe? The "GMTs" are a really pain :D
haha but i like where i live. its not perfect by any means but better than other places i have been. :D

[Rockas]

Quote:
muxprofile to output an mp3 I receive a Windows error and QuEnc terminates
well its not supported via cli yet so nothing would surprise me that way.
No... that one is using the GUI


Quote:
if I choose output as MP4 on QuEnc GUI and then I try to encode (via CLI) the audio (still using my scripts above) to AC3... QuEnc terminates... it seems like not being updated with the new parameters from the CLI and still try to use the last ones inserted on the GUI...
did you also try setting it to mpeg2 with "-mpeg2" since thats where the ac3 encoder is ?
I'll run some tests tomorrow (your today :D) and let you know about that :)

just look at all the work Rockas keeps giving me.
Yeah! but admit it... you love every minute of it (work)!!! :D
and besides... that's why I pay you :o

haha but i like where i live. its not perfect by any means but better than other places i have been.
Well... as long as you don't come to Portugal... you'll be fine :D
take a look: http://www.portugalforbeginners.pt.vu/

[Rockas]

oh! by the way... I really hope you get better quick... this ain't any fun without you :)

[dragongodz]

No... that one is using the GUI
ok just tested it. let me guess, you tried to encode audio with more than 2 channels ? that does cause QuEnc to fail of course since normal mp3 is 2 channel max. i tried it with 2 channel source and it worked fine. you can of course also use Avisynth to downmix to 2 channel(stereo).

besides... that's why I pay you :o
i get paid ? damn the postman must have been ripping off the letters with the cheques in them. :eek:

take a look: http://www.portugalforbeginners.pt.vu/
hahaha opened up the celebrity page to find
"There aren't many."
i also liked the Brad Pitt entry at the bottom. :)

[Rockas]

ok just tested it. let me guess, you tried to encode audio with more than 2 channels ? that does cause QuEnc to fail of course since normal mp3 is 2 channel max. i tried it with 2 channel source and it worked fine. you can of course also use Avisynth to downmix to 2 channel(stereo).
Yes... I thought about something like that but the main issue is that QuEnc crashes... is shouldn't... message error? yes ... crash... not good :D
i get paid ? damn the postman must have been ripping off the letters with the cheques in them.
uummm... maybe he's portuguese!?!?! :D
hahaha opened up the celebrity page to find
"There aren't many."
i also liked the Brad Pitt entry at the bottom.
You must read it all... I read it... it's one of the funniest things I have ever seen :D
Don't forget to read "Essential Portuguese" section :D

[Rockas]

did you also try setting it to mpeg2 with "-mpeg2" since thats where the ac3 encoder is ?
Sorry... you were right about this one... the problem is that I assumed that when inserting "-mpeg2mux" it would be enough :o ... it was working for video ;)

[dragongodz]

message error? yes ... crash... not good
of course. however this is new of course so in no way is everything done for it. you have just found 1 more thing to fix before a release version. :)
or think of it this way. Nic adds the basic features he wanted and leaves me the job of cleaning it up for everybody else. :D

the problem is that I assumed that when inserting "-mpeg2mux" it would be enough
you do know what assumption was the mother of right ? ;)
i will probably change some of the behaviours of commands etc to a more logical way anyway.

[Ebobtron]

Hi all,
I would like to add my two cents concerning encoding ac3 ?

QuEnc61 always seems to reduce the audio level approximately 10db in the encoded output.

Following list should explain:

> than 0 db input.. -10db output
0 db input.. -10db output
-3 db input.. -13db output
-6 db input.. -16db output


Number of channels makes no difference in the output.

10db is a heavy reduction in volume. Don’t remember anyone ever complaining about it. But it has been a long time.

Just wanted to add this to the list.:)

Thanks Dragon

[Rockas]

Yes I believe you are right... I was suspicious about it but I was not sure...
I thought it could be a difference between players and not an encoder result and since I'm busy with other issues I didn't gave it any importance :)

edit: I made a quick review on my SynthEditor (development) notes (yes... sometimes I take some notes :D) and there it was.
Remember to verify sound output volume... sound seems low... AviSynth problem?
Trying todo:
Don't forget to try "normalize" on AVS Script!!!
[Sorry for the bad english - direct translation from portuguese :)]

[dragongodz]

always seems to reduce the audio level
yes a known problem. you can find out more in the audio section. other programs use things like normalisation from memory to fix it. will have to relook over those threads again.

of course you can increase volume in Avisynth aswell to reduce this problem aswell.

actually going from memory there was a patch submutted a long time ago to the ffmpeg mailing list that was meant to fix this. it was not accepted for whatever reason. i did look for it before but failed to find it. now if someone still had that floating around it could be helpful.

[Rockas]

Well.. I just added a "AmplifyDB(9)" to my "Audio to encode script"... I put 9 'cause it seemed to my hears that 10 was exagerated and maybe 9... I'll wait for some feed back about this but I feel like 8 would be a good value...
I'll keep on testing :)

[Ebobtron]

@dragongodz
yes, I thought the ac3 levels issue had been bounced around. It has been so long I remember it not.

@Rockas
I can only offer this caution. QuEnc has some kind of limiter or clamp working, but shows no signs of normalization for low or high level input. My ears tell me some clipping begins if I push the input level to high.

I believe, and my tests show that the max output of QuEnc's ac3 encoder is -10db. You may input +20db, I think you will find a -10db out which sounds clipped. If you input -10db your result will be -20db.

dragongodz’s suggestion to normalize would make more sense.

But I think for know -10 is all we are going to get.

[Rockas]

I made a few tests with "AmplifyDB(9)" and it didn't look like cliping is occuring... I just released my new SynthEditor with AmplifyDB(9) enabled... can you try it for a little?

In the mean time I'll try with some more different sources.

dragongodz’s suggestion to normalize would make more sense.
ummm... I don't know about that... if QuEnc encodes -10db then the sound will always get a lower level... maube it can help a little but...

thank you

[Zarxrax]

Would it be possible to implement DV encoding in QuEnc? Unless I'm mistaken, its just a specific case of mpeg-2, right?

[Rockas]

At this point SynthEditor is supposed to encode DV using AviSynth... QuEnc for audio and QuEnc/HC for video... target size will be accurate... I hope :D

[Zarxrax]

At this point SynthEditor is supposed to encode DV using AviSynth... QuEnc for audio and QuEnc/HC for video... target size will be accurate... I hope :D

Oh, interesting :)

[communist]

Would it be possible to implement DV encoding in QuEnc? Unless I'm mistaken, its just a specific case of mpeg-2, right?
No its more like an "advanced MJPG".
Since QuEnc uses libavcodec a LOT of formats could be added but I dont think thats what everyone wants - since implementeng / testing / bug-fixing etc. them will take quite some time.

[Sagittaire]

@ dragongodz

Libavcodec (and QEnc) seem buggy for quant value only for MPEG2.

OSD for ffdshow show x2 real scaling for quantizer (only 2,4,6,8 ... etc etc)

[dragongodz]

Sagittaire - can you explain in a bit more detail what you mean ?

[Zarxrax]

Sagittaire, I believe it is probably a bug in FFDshow. Try with a different encoder. Using TMPGenc at the highest bitrate settings FFDShow says its using Quant 2.

Also examining the files (mpeg1 only, there should be no difference though) in MPEG_Stat, reports that the frames are encoded at Quantizer 1.


dragongodz: can we maybe expect a new beta version soon, I hope? :)

[Sagittaire]

Sagittaire, I believe it is probably a bug in FFDshow. Try with a different encoder. Using TMPGenc at the highest bitrate settings FFDShow says its using Quant 2.


1) I'ts wrong : TMPGEnc max quality (CQ100) done quantizer 1 for each macroblock without vbv limitation. FFDShow OSD macroblock quantizer show that only for Libavcodec MPEG2. MPressionist MPEG-2 Analyzer seem show same quantizer than FFDShow.

2) In fact Libavcodec show internaly that it use 1, 2, 3 ... etc but in fact Libavcodec apply x2 scaling for quantizer and use only 2, 4, 6 ... etc for each frame or macroblock if you use adaptative quantisation.

You can make little experience too:
Libavcodec constant quant encoding q2 done approximatively the same bitrate than all other MPEG2 encoder (HC, TMPGEnc, CCE ... etc) at q4 with same source, matrix, dc ... etc

In fact Libavcodec can't simply use impair quantizer for MPEG2 (for frame or macroblock) and use only pair quantizer. This "bug" can explain for example saturation for Libacodec at very high bitrate because use quantizer 1 is simply impossible ... ???

[dragongodz]

Libavcodec constant quant encoding q2 done approximatively the same bitrate than all other MPEG2 encoder (HC, TMPGEnc, CCE ... etc) at q4 with same source, matrix, dc ... etc
confirmed. something is a bit screwey here. frames are marked as quant 2 but macroblocks are quant 4. will add it to the list of things to see if i can fix.

can we maybe expect a new beta version soon, I hope? :)
well as you can see theres still some things need fixing. add in all the things Rockas has raised and you will see there is still a bit for me to do. :)

[wmansir]

Hey guys, I'm updating the DVD-RB guide for Doom9 and I have a question about QuEnc.

DVD-RB has two options for QuEnc 1-pass mode. CQ VBR (which DVD-RB figures out the CQ, like CCE 1-pass), and QuEnc's 1-pass, which I have no first hand information about. Besides the method used, are there any major differences between them in terms of speed, quality or size prediction?

From a quick search of this thread it seems QuEnc's 1-pass is pretty good, so is DVD-RB's CQ 1-pass more of a legacy option? Or are there situations where it is preferred?

[Rockas]

Well I guess that "1 pass CQ" will always deliver a better quality than 1 Pass VBR.
CQ (as you know) will be an Encode based on the Q value... found after Rebuilder's analisys.

1 Pass VBR is used the same way the 2 passes VBR but it will do just one, of course :)

I don't know this is the kind of answer you were expencting but...

[Inc]

Due to Quants (some postings from Sagittaire before)

TmpgEnc, CCE --> Non-Linear Quantization
Libavcodec --> Linear Quantization

Do search of some posts from PeterCheat ....
http://forum.doom9.org/showthread.php?p=564629&highlight=linear#post564629

If BV shows in a libavcodec encoding a Q of 2 then its comparable to a Q of 4 in TmpgEnc,CCE etc. FFdshows Q parser output imho only is capable to provide integer values. So if a float of 3.x results, fdshow repots 4 --> Imho

[dragongodz]

Well I guess that "1 pass CQ" will always deliver a better quality than 1 Pass VBR.
i would have to disagree with that. it can be very bitrate and source dependant. for example if you are encoding to a small size you may end up with a CQ of say 8(just for example). however 1 pass VBR will vary the quants and use lower sometimes when it thinks it needs it and higher when it thinks not much difference is lost. so 1 pass VBR can have better looking parts in such a case.

also of importance is that CQ with QuEnc is not max bitrate restrained. that gives the potential for exceeding legal max bitrate for dvd(again for example) if its very low quant.

[Mug Funky]

CQ is very good for credits - for whatever reason (subpel accuracy or lack of?) credits can be given massively high quants and still look good, but by the same token, both 1 and 2-pass ratecontrol (in any encoder) seems to give them far too high a bitrate, usually around max bitrate if there's more than a few words on the screen.

so CQ is good in these situations, especially if you wish to shave a couple of hundred megs off an encode without damaging anything :)

credits usually still look good up to (linear) quant 8-12. you could go further, but there's a point of diminishing returns when the credits are already so small that hitting them harder will only buy you an extra meg.

[dragongodz]

both 1 and 2-pass ratecontrol (in any encoder) seems to give them far too high a bitrate, usually around max bitrate if there's more than a few words on the screen.
i think you will probably find its because most encoders see all that moving text as high motion.

[Sagittaire]

Due to Quants (some postings from Sagittaire before)

TmpgEnc, CCE --> Non-Linear Quantization
Libavcodec --> Linear Quantization

Do search of some posts from PeterCheat ....
http://forum.doom9.org/showthread.php?p=564629&highlight=linear#post564629

If BV shows in a libavcodec encoding a Q of 2 then its comparable to a Q of 4 in TmpgEnc,CCE etc. FFdshows Q parser output imho only is capable to provide integer values. So if a float of 3.x results, fdshow repots 4 --> Imho


And IMO Bitrate Viewer simply sucks here because BV read simply frame header and don't make real stream analyse. FFDshow and MPressionist MPEG-2 Analyzer done same result.

1) Libavcodec can use adaptative quantisation in two mode:
- Macroblock Rate Distortion
- Macroblock masking (lumi, dark, spacial, temporal, inter masking)

for example:

Libavcodec encoding
http://multimediacom.free.fr/Video/LAVC-AQ.jpg

Like you see:
- Macroblock quantizer is not constant
- FFDShow OSD show real frame average quantizer
- Libavcodec use only pair quantizer (4,6,8,10 and 12 in this frame) and never impair quant

CCE encoding
http://multimediacom.free.fr/Video/CCE-AQ.JPG

Like you see:
- Macroblock quantizer is not constant
- FFDShow OSD show real frame average quantizer
- Libavcodec use only pair and impair quantizer (7,8 and 10 in this frame)


2) I think that actually all MPEG2 encoder must always done approximatively same size for same quantizer if comparable setting are used (matrix, DC precision, good ME level ...) and certainely not half size. Size variability is difference between optimisation like ME search function, Rate Distortion, trelli : gain can be perhaps 5, 10 or 25% for size between MPEG2 encoder but certainely not 50% ...

[Mug Funky]

hmm. try an encode with CQ set to > 31/2. it seems the macroblock quants are wrong somehow, and the frame quants are (more or less) correct.

i tried CQ 17 (number plucked from BV's average frame quant for a 1-passer) and ffdshow was reporting block quants at 34. i wouldn't think that's possible.

[edit]

CQ 20 came out with block quants reported as 40...

[dragongodz]

i am glad people read this
http://forum.doom9.org/showthread.php?p=805102#post805102

anyway i sort of have it working better, well size wise.
test = small clip at constant quant 17

HC 0.17 = 2.79mb
QuEnc 0.62 old = 1.55mb
QuEnc 0.62 new = 2.45mb

as for mb quants QuEnc encodes both show 34 while HC shows 28 ???

tested HC at quant 20 and it shows 40 ????

result = i will leave the change i just made for now since it seems to me to closer equel expected sizing.

[hank315]

IMO quants for Quenc and HC are both correct.
The next table shows the difference for Quenc (linear scale) and HC (non-linear scale).
quantiser linear non-linear
0 (forbidden)
1 2 1
2 4 2
3 6 3
4 8 4
5 10 5
6 12 6
7 14 7
8 16 8
9 18 10
10 20 12
11 22 14
12 24 16
13 26 18
14 28 20
15 30 22
16 32 24
17 34 28
18 36 32
19 38 36
20 40 40
21 42 44
22 44 48
23 46 52
24 48 56
25 50 64
26 52 72
27 54 80
28 56 88
29 58 96
30 60 104
31 62 112
The quantizers are written in the bitstream, the choice for linear/non-linear is written in the Picture_coding_extension.
Programs like ffdshow will read both, make the proper conversion and output the linear/non-linear quantizer_scale values.
So Q=17 will show 34 for Quenc and 28 for HC.

[dragongodz]

my concern was more with the rather huge size difference. however ,as i said, i have reduced that difference so this should no longer(hopefully) be an issue.

[tin3tin]

Will there be commandline acces to the maxbitrate function in the next release?

[Mr_Odwin]

There is in 0.61 so I would assume it would stay. For example, -maxbitrate 8000

[dragongodz]

or from CLI you can just go
QuEnc.exe -?
and see a nice little poppup list of CLI commands. :)

[tin3tin]

Ehm, I'm sorry. :o I meant 'Auto max bitrate'.

[Ebobtron]

(maxbitrate = 0) == auto

[manolito]

Would it be hard to split up the "Interlaced" setting into separate settings for the scan method and for flagging the stream as progressive or interlaced?

Explanation:
Most of my conversions are analog TV captures of Hollywood movies. While the movie itself is purely progressive most of the time, the end credits usually are interlaced. When I encode these clips as progressive, the end credits look really bad (jagginess, jerky movement). Of course I could just encode the whole movie as interlaced, but this is not good for compressibility, and it also is much slower.

For this kind of encodes I get the best results if I encode the whole movie as progressive (zigzag scan), but flag the whole stream as interlaced tff. For reasons I do not completely understand my standalone (PAL Cyberhome 402, connected to a standard CRT TV via SCART) does display a progressive stream differently depending on whether the stream is flagged as interlaced or progressive.

For CCE and HC it is possible to set the scan method and the flags independently, so it would be very nice if QuEnc could also do this. The reason I'm asking is that right now QuEnc (0.62 Alpha5) in 1-pass VBR mode is my encoder of choice. IMHO right now no other encoder beats it in terms of quality vs speed.

Cheers
manolito

[DarkFoon]

Sounds like a complex feature (as in dumb users might screw something up if they stumble onto it and don't know what it does), which me thinks means it wont get added.

[dragongodz]

possible to set the scan method and the flags independently
well it was discussed some time ago and concluded that setting the wrong scan order lowered quality. so thats why they are set to the appropriate setting to the encode type automatically.

have you tried just deinterlacing the end credits ? that would seem the easiest solution to me.

note to make the change to flag setting you are suggesting probably means i would have to change it in avcodec and then again every time i wished to update it. as it is the change for pulldown and another experimental change which isnt in alpha 5 already require this. the less i have to change in that way the better. so at the moment i am leaning towards not making that sort of change. i would definatly not count on i for the next release.

[Mug Funky]

one could always encode the movie and the end credits separately, then join later with their authoring program... this will give you better quality than messing with flags.

"zones" would be useful, but that would possibly complicate the program too much.

[manolito]

It turned out my problem was not the "Interlaced" flag, it was the TFF flag. For a progressive encode QuEnc does not set the TFF flag which causes my standalone to send out the fields as BFF. Please have a look here: http://forum.doom9.org/showthread.php?p=813844#post813844

Since I am totally unfamiliar with the DVD specs I would like to ask what the correct behavior for an encoder is when encoding as progressive: Should the TFF flag be set (like CCE does) or not (like QuEnc, FreeEnc and HC)?

Cheers
manolito

[dragongodz]

first off progressive encoding means there are no fields but whole frames. fields are interlaced encoding.

this is sounding very much like the problem discussed here
http://forum.doom9.org/showthread.php?s=&threadid=75923
and here
http://forum.doom9.org/showthread.php?t=80636
please completely read them to understand them.

as for correct behaviour well if you are encoding progressive then field order is totally irrelevant because as i said its not fields. the only exception is when pulldown is being done, as mentioned in those threads, because its being treated mnore like interlaced and fields. note that CCE even has an option called progressive which will do exactly the same as QuEnc and HC etc do. it just defaults to being off all the time.

my advice is to do as already mentioned, encode all as interlaced or deinterlace the credits and encode all as progressive or encode the credits separatly as interlaced and join the footage later.

[manolito]

first off progressive encoding means there are no fields but whole frames. fields are interlaced encoding.
Yes, I know that. But when my standalone DVD player talks to my standard CRT TV set, it has to disassemble these frames into fields before sending it to the TV. And the order in which these two fields are sent does seem to change according to the TFF flag. For true progressive content this does not matter of course, because the two fields have been shot at the same moment in time, but it does matter if some interlaced stuff happens to be in the stream.
as for correct behaviour well if you are encoding progressive then field order is totally irrelevant because as i said its not fields. the only exception is when pulldown is being done, as mentioned in those threads, because its being treated mnore like interlaced and fields. note that CCE even has an option called progressive which will do exactly the same as QuEnc and HC etc do. it just defaults to being off all the time.
I live in PAL country, so no pulldown is involved here. And for encoding with CCE I actually do set the "Progressive" option. When I analyze this stream with ReStream, it shows that the "Progressive" and the "TFF" flags are set. Streams encoded with QuEnc, FreeEnc and HC also have the "Progressive" flag set, but the "TFF" flag is not set. And only the stream encoded with CCE does not have the jerky vertical movement for the end credits.

And I also do know how to "correctly" encode hybrid content. It's just that I am lazy, and it is not so easy to find out if end credits (where there is no horizontal movement usually) are actually progressive or interlaced. So for me the method of choice is the one that is the fastest and covers all source formats. In my case this means just flagging the whole stream as "TFF" using ReStream. This takes care of the credits while not doing any harm to the main movie, and it also is quite fast.

Cheers
manolito

[Mug Funky]

it doesn't take long (even for the lazy like me) to open the avs in virtualdub and seek to the end...

FWIW, i'd like to be able to set TFF and progressive. even if it doesn't make sense in a perfect world, there is always a chance that there's interlaced sections that just can'y be found without watching the thing all the way through. in these cases, setting the field-order flag to the correct input field order can mitigate the problem. however, such interlaced frames encoded as progressive will most likely be complete crap to look at - chroma will be mashed and quants will be high, but that might not get noticed on an interlaced screen as much as flipped fields (plus all the other problems) would be.

[manolito]

it doesn't take long (even for the lazy like me) to open the avs in virtualdub and seek to the end...
True, but if there is no horizontal movement, there will be no combing, even if the source is interlaced.
FWIW, i'd like to be able to set TFF and progressive.
I absolutely second that. Without elaborating too much, I did a couple of tests which show that artifacts from encoding an interlaced source as progressive are much less visible on my standard CRT TV than artifacts caused by flipped fields.


Some other findings from my tests:

CCE 2.67 always flags progressive encodes as TFF

TMPGEnc Plus 2.5xxx flags progressive encodes as Interlaced and TFF

After a quick glance over the QuEnc source code it seems that only one line in the AdvOptionsDlg.cpp has to be commented out to achieve this:
// Only allow TopFieldFirst if interlaced encoding
m_btnTopFieldFirst.EnableWindow(m_bInterlaceEnc);


Maybe DGZ can be talked into modifying QuEnc to let us set the Progressive and TTF flags at the same time, even if it might not be strictly DVD compliant...


Cheers
manolito

[dragongodz]

And for encoding with CCE I actually do set the "Progressive" option.
i just reinstalled the 2.67 trial version. yes you can set progressive frame flag but it is not possible to set the progressive sequence flag .. at all. where as QuEnc, HC and Tmpgenc 2.54 all set it for for progressive encodes. how weird is that. :)

TMPGEnc Plus 2.5xxx flags progressive encodes as Interlaced and TFF
sorry but 2.54 does not but according to the other thread where you asked about this 2.53 and below did. i just checked that aswell with 2.54 and it did exactly the same as what QuEnc and HC did.
ok i just checked MainConcept aswell, want to guess what it does ? yes it doesnt set TFF either when set to progressive encoding.
so the only encoder mentioned so far(anyone care to test Procoder ?) that does things differently with setting TFF for progressive encoding is CCE.

no pulldown is involved here.
this case is about telling the decoder to treat the stream slightly differently than its been encoded, hence my pointing out the pulldown threads by the way.

Maybe DGZ can be talked into modifying QuEnc to let us set the Progressive and TTF flags at the same time
hmm maybe. thats if avcodec even really will do it. unfortunatly not right now though as i am setting up footage because i am going to run some tests on ... oh cant mention that yet. :D ;)

[Mug Funky]

True, but if there is no horizontal movement, there will be no combing, even if the source is interlaced.

sure there will be... it'll just look different. interlaced credits are usually easy to spot. combing isn't an exclusively horizontal phenomenon (though it is much harder to deal with when motion is vertical and slow - comb detection often fails because the 2 fields are completely identical and the mismatched frame can actually give lower metrics than the correctly matched frame).

the good news is that if you can't see any combing, it's most likely safe to encode it as progressive... in this case TFF flagging would indeed be useful, but there'd be little to no perceptible difference.

[dragongodz]

Maybe DGZ can be talked into modifying QuEnc to let us set the Progressive and TTF flags at the same time
i tested this by the way. no good. it still doesnt flag the TFF so i guess it must have to be changed in libavcodec aswell.

After a quick glance over the QuEnc source code it seems that only one line in the AdvOptionsDlg.cpp has to be commented out to achieve this:
// Only allow TopFieldFirst if interlaced encoding
m_btnTopFieldFirst.EnableWindow(m_bInterlaceEnc);
actually theres 3 or 4 places that needed to be changed. :)

[manolito]

Anyways, thanks for testing it. I hope I haven't wasted too much of yor time.

And I still prefer QuEnc 0.62 Alpha5 1-pass VBR over CCE OPV, even if it takes about 10 additional minutes to restream the encode to add the TFF flag.

Cheers
manolito

[dragongodz]

I hope I haven't wasted too much of yor time.
no thats ok. it did take a little time to make sure i found all the places that needed changes for it so its abit disapointing it didnt do anything. i wont worry about digging in libavcodec with this version/release as that will take even longer. however in the future, when i do an update of libavcodec, i will probably see what i can find about this.

[burnix]

Sorry, but ijust want tot test it, but the link was bad (post page 15). If someone can help me i thank you a lot.

----------------
Thanks Feedback
----------------

[feedback]

You can get it Here.
http://www.pcpages.com/dragongodz2/