Log in

View Full Version : QuEnc 0.72


Pages : 1 [2] 3 4 5 6 7

Revgen
23rd May 2006, 03:04
VFB buffer size shouldn't be changed from 1835 if you're trying to create DVD compatible files.

Mug Funky
24th May 2006, 05:14
actually, while we're on requests...

these would all no doubt complicate the interface, but it's all a matter of balance

- the ability to set 16:9 pan-scan (that is, sequence_display_extension width = 540, so it fills the screen on a 4:3 TV rather than being letterboxed). currently one must do this in ReStream, which can cause problems in rare cases.

- I-frames seem to get hit too hard on 1-pass mode. would this be an i-frame reduction thing? also something like b-frame multiplier and offset options would be cool in some cases.

- skipped blocks used more when bitate looks to be overflowing. this is probably an ffmpeg issue though, and would require some haxx0ring...

- "zones" would kick arse. like chapters, with their own settings, so you could set interlaced parts, progressive parts, even top-field and bottom-field parts.

- auto 3:2 pulldown :) this'd be hellish to implement (though it could be easier than one might think - just compare top fields and bottom fields with those in the next frame and if they're the same, drop one and set RFF). could this also work for PAL? that'd be cool for still scenes to encode 2/3 the amount of data :).

that's all i can think of right now, except for the stuff that requires severe ffmpeg hacking, like scenechange + cgop, better behaviour on scenechanges when SCD isn't set, etc.

Revgen
24th May 2006, 05:47
- auto 3:2 pulldown :) this'd be hellish to implement

Dscaler ( http://sourceforge.net/project/showfiles.php?group_id=7420 ) already has an auto 3:2 pulldown algorthim that works pretty good when I watch TV. You could look at the source code and see if it can be ported.

Delta2
25th May 2006, 09:59
I can't make it to work with OPV ( 1 PASS VBR )

here is my CLI options :

QuEnc -i script.avs -o multiplex.mpg -b 8300 -maxbitrate 9800 -dc 10 -priority 3 -1 -vbr -mpeg2mux dvd -hq -audiobitrate 256 -aspectratio 4:3 -auto -close

and the script.avs is this :

LoadPlugin("blockbuster.dll")
LoadPlugin("deen.dll")
LoadPlugin("aWarpSharp.dll")
LoadPlugin("aSharp.dll")
LoadPlugin("UnDot.dll")
DirectShowSource("tom yum goong.avi")
AssumeFPS(25,true)
ConvertToyv12()
Blockbuster(method="noise",detail_min=1,detail_max=10,variance=0.3,seed=2)
aSharp(1,4)
UnDot()
Tweak(hue=4,sat=1.3,bright=0,cont=0.9)
Lanczos4Resize(720,468)
AddBorders(0,54,0,54)

2 PASS is OK

1 PASS makes QuEnc 0.70 to close immediately

* edited *

source has PCM uncompressed audio

it seems to work only when I set the -mpeg2mux switch to SEPARATE...

Is this a bug or I'm doing something wrong ?

buzzqw
25th May 2006, 12:10
leave 1 pass but remove the -close and -auto switch... i had some problems with these...

BHH

dragongodz
26th May 2006, 04:27
hi guys. currently i am rather sick.

as for the suggestions please remember that if it has to be done in libavcodec then i am not going to be real keen on it. reason is every time Nic or i would update libavcodec then such changes would have to be repeatedly done. a major pain in the rear in other words. as i is there are a couple of these that need to be done, more isnt always better. ;)

those commenting about peaks, can you please give as much information as possible when this happens ? ie. mpeg1 or mpeg2, 1 pass or 2 pass, max bitrate set compared to max bitrate reported(and i dont mean by bitrate viewer since i have personally seen that give screwy readings so dont take anything from that as being reliable), type of footage etc etc etc. thanks.

Zarxrax
26th May 2006, 19:19
dragongodz: Encoding short mpeg2 clips, it exceeds max bitrate every time, unless I either disable VBR, or set a sufficiently low average bitrate. Statistics taken from the Streameye program that you mentioned before.

On a 1:30 clip with lots of motion, 23.976fps, progressive:
2pass, VBR, AVG Bitrate 6000, Max Bitrate 8000:
- real max: 9 128 159
- real avg: 6 298 218
- real min: 1 064 919

1pass, VBR, AVG Bitrate 6000, Max Bitrate 8000:
- real max: 9 039 735
- real avg: 6 321 235
- real min: 1 054 370

1pass, CBR, AVG Bitrate 6000, Max Bitrate 8000:
- real max: 7 811 970
- real avg: 6 501 919
- real min: 5 525 806

2pass, VBR, AVG Bitrate 3500, Max Bitrate 8000:
- real max: 7 725 081
- real avg: 4 036 798
- real min: 895 936


On a 5:00 clip with average motion, 29.97fps, interlaced:
2pass, VBR, AVG Bitrate 6000, Max Bitrate 9000:
During encoding, it said "4 possible overflows". (ah, so it already does this, there goes one of my previous feature requests :p)
Also, QuEnc CRASHED near the end. So I had to encode again. It worked the 2nd time.
- real max: 9 666 163
- real avg: 6 368 984
- real min: 1 325 633

1pass, VBR, AVG Bitrate 6000, Max Bitrate 9000:
- real max: 10 048 101
- real avg: 6 300 892
- real min: 1 201 916

1pass, CBR, AVG Bitrate 8000, Max Bitrate 9000:
- real max: 10 312 317
- real avg: 8 535 455
- real min: 7 641 870

2pass, CBR, AVG Bitrate 8000, Max Bitrate 9000:
Reported "3 Possible overflows"
- real max: 8 923 147
- real avg: 8 530 420
- real min: 7 733 698


The goal is to encode the highest quality file possible, with no regard to filesize, without exceeding the max bitrate.

Additionally, it would seem that QuEnc does not put a Sequence End Code in the video stream. I'm not exactly sure, but wouldn't having that help compliance with some things? Would it be possible to have QuEnc write this end code?

manolito
26th May 2006, 20:54
@Zarxrax
You worry too much about strict enforcement of max bitrate. In my experience it is less important than many people think. There was a lengthy discussion here about this problem by the end of last year, and I suggest you take the time to go over this thread. The posts from Sir Didymus are especially interesting, here is a link:
http://forum.doom9.org/showthread.php?p=743503#post743503
I agree completely with Sir Didymus that one very reliable DVD compatibility test is to use Muxman for muxing / authoring. If Muxman reports no errors then you can be 99.9% sure that any standalone will play this DVD, even if the max bitrate limit has been exceeded. Mplex on the other hand can cause stutter even if the encode was well below the max bitrate limit.

Cheers
manolito

Zarxrax
26th May 2006, 21:37
Well, honestly right now I am trying to create files that will play back on hardware decoder cards such as the Netstream 2000 or Hollywood+
So far, I have been fairly unsuccessful with getting my QuEnc encodes to work. I don't own this hardware myself, so I basically have to try various settings and then send my encodes to the person with the hardware. So far he keeps saying that the file just dies about halfway through. This would make me think its the bitrate, but this still happened even with a file well under the maximum bitrate that he claims, 16mbps.

I need to write a guide which will allow others to reliably encode files that will play back on these types of hardware. So far it has been assumed that people can use TMPGenc, but the 30 day expiration is a problem for many people. I have my eye on QuEnc for the guide because its an all in one video/audio/muxing tool, and is so easy. I just can't reliably make files that will work :\

Mug Funky
27th May 2006, 16:57
interesting... bloke at work played a CQ 1 encode through a netstream 2000 (or was it 3000?) and it worked in the DVD Station software that comes with it.

CQ1 obviously doesn't enforce max bitrate, and in fact the video in question resembled DV more than DVD, bitrate wise :)

YMMV of course.

@ DragonGodz: get well soon, buddy.

Zarxrax
27th May 2006, 20:12
Hmmm. Interesting that it could play CQ1! Well, I just picked up a netstream 2000 off ebay, so in a few days I'll start testing it myself :)

dragongodz
2nd June 2006, 17:14
just a quick note.

i am slowly getting better but not there yet.

my system decided to screw up aswell in a rather major way. so i have had to start rebuilding it from scratch. that means basically i have windows and firefox running at the moment. so all the development stuff is going to have to be reinstalled and re-setup etc etc etc. should only take a week. :eek:

Mug Funky
3rd June 2006, 05:24
eeks... get well soon (that goes for your computer too :))

dragongodz
3rd June 2006, 13:32
eeks
you have no idea. going through cds trying to find where i put things like csdiff(for example) and then saying bugger it and redownloading it anyway. not fun.
finding and installing all these little utils is damn sloooow.

DocDragon
5th June 2006, 06:23
you have no idea. going through cds trying to find where i put things like csdiff(for example) and then saying bugger it and redownloading it anyway. not fun.
finding and installing all these little utils is damn sloooow.
have you thought of using norton ghost to create an image of your working configuration? i'm using 3 dvd+rws to save my windows configuration/installation and can revert back to whatever config was most stable, which comes especially handy when installing new vga drivers. man, some of those nvidia drivers in the past were so buggy they wouldn't work properly with a dual-core cpu -- whole system got messed up. after re-installing windows so many times and finally figuring out the source with the help of other forums, i just had it and bought norton ghost pretty cheap with mail-in rebates. hehehe, no more juggling with driver and program discs. my installation time went down from nearly 1 week to barely a couple of hours.

good luck and thx for all the hard work!

DD

Koepi
5th June 2006, 09:04
Why buying software when you can get similar tools for free?

SystemRescueCD: http://www.sysresccd.org/Main_Page
uses PartImage: http://www.partimage.org/Main_Page

Those work just fine for me -- though I didn't backup my current installations yet... that happens if you get lazy. ;)

Cheers
Koepi

dragongodz
6th June 2006, 11:21
create an image of your working configuration?
actually i did. unfortunatly the last time was about two and a half years ago. a lot changed since then so if i had put that on i would have been uninstalling and updating software like crazy anyway.

DocDragon
6th June 2006, 20:46
Why buying software when you can get similar tools for free?

SystemRescueCD: http://www.sysresccd.org/Main_Page
uses PartImage: http://www.partimage.org/Main_Page

Those work just fine for me -- though I didn't backup my current installations yet... that happens if you get lazy. ;)

Cheers
Koepi
yes, i've seen that before ;), but i'm linux-illiterate... does it allow volume spanning, ie. backups over several DVDs/CDs?

one additional good thing about norton ghost is the included disc doctor to repair broken files and surface scan the HDD for defects. for around 30 bucks including partition magic (which SystemRescueCD has also), it's not such a big "loss" ;).

but thanks for the tip!

actually i did. unfortunatly the last time was about two and a half years ago. a lot changed since then so if i had put that on i would have been uninstalling and updating software like crazy anyway.
:eek: 2.5 yrs??? with all the software you're developing? i hope you're not working *professionally* on any time-sensitive projects *grin*.

DD

ps: we shouldn't expect a 0.71 version anytime soon, then? *LOL*

jano22
6th June 2006, 22:56
yes, i've seen that before ;), but i'm linux-illiterate... does it allow volume spanning, ie. backups over several DVDs/CDs?
A free DOS solution may be partition saving (http://damien.guibouret.free.fr/en/index.html). Donīt ask me about it, i never used it.:rolleyes:

dragongodz
7th June 2006, 11:04
we shouldn't expect a 0.71 version anytime soon, then? *LOL*
well i have pretty much all the dev stuff on now .. i think. so i could start but i want to make sure everything is ok first and then back it up. then i will try and get back to actually working on QuEnc. :)

Zarxrax
9th June 2006, 22:08
interesting... bloke at work played a CQ 1 encode through a netstream 2000 (or was it 3000?) and it worked in the DVD Station software that comes with it.

YMMV of course.
Hmmm, YMMV indeed! I got my netstream 2000 and have been trying various encodes on it. The bitrate is definately a factor in it. That CQ1 video that your bloke friend encoded must have been quite simple video, because it starts dying for me around when i set average bitrate to 7000 and max to 10,000. I'll have to do some extensive testing and see exactly whats going on here.

Zarxrax
10th June 2006, 00:02
Alright, I finally see what is going on here.

QuEnc's muxing is totally screwed up (i'm sure dragongodz is tired of hearing this from me ;) )

[These are all mpeg-2 encodes, being played back on Netstream 2000 hardware decoder card]

- If I make an encode with a max bitrate of 9000 in quenc, it will play fine.
- If I make an encode with a max bitrate of 10000 in quenc, it will die.
- If I use tmpgenc to make an encode with a max bitrate of 15000, it will play fine.
- If I use quenc to make an encode with a max bitrate of 15000, then mux it with tmpg instead of quenc, then it plays fine.

I would be willing to bet some money that this is directly related to the troubles I have had with the mpeg-1 muxing in quenc. I hope you have all your stuff working well again and can take a look at this sometime soon, Dragongodz, if you aren't fed up with me by now :D

dragongodz
10th June 2006, 13:51
QuEnc's muxing is totally screwed up
well really this would be ffmpegs muxxing to be exact. hmm i know there was problems ages ago but most of that should have been fixed.
does that mean muxxing will be as good as Tmpgencs ? not at all. i have created mpegs with other programs and then remuxxed with Tmpgenc and seen the size change etc. however is it an invalid mux because the netstream has a problem ? well that would be a big call. i would really need more having problems, such as multiple authoring programs, before saying the muxxing was actually screwed up.

I hope you have all your stuff working well again and can take a look at this sometime soon, Dragongodz, if you aren't fed up with me by now
probably about 98% done. there just seems to be little programs i have forgotten about that keep springing to mind or i see when going through cds etc. some of these i didnt think about until i needed them. :)

and no i am not fed up with you. the frustration i get some times is trying to replicate problems, especially when its ok for some footage bu shows a problem with specific ones etc.

Zarxrax
10th June 2006, 17:36
Well as you know, so far as MPEG-1 went, I have had playback issues with many different directshow based decoders. I haven't had so much trouble with directshow-based mpeg-2 decoders, but maybe they are more resilient or something, I don't know.

But here is one more fact for you: I load the mpeg muxed by Quenc into the program MPEG-2 Validator, and it says:
*Program Mux Rate = 9843 Kbps, Min. Recommended = 10607 Kbps
*PTS underflow (Mux Error)...!!
*DTS underflow (Mux Error)...!!
Total PES packets = 63573
PES Packet Lenght Max. = 2028
When I load the same video muxed by tmpgenc, it says
Program Mux Rate = 15291 Kbps
Total PES packets = 63053
PES Packet Lenght Max. = 2028

Maybe this will help.

Mug Funky
13th June 2006, 05:16
@ zarxrax: the Q1 encode i mentioned was an elementary stream :) i find most authoring tools prefer elementary streams so i've barely tried quenc's muxing...

dragongodz
13th June 2006, 20:12
2pass, VBR, AVG Bitrate 6000, Max Bitrate 8000:
- real max: 9 128 159
- real avg: 6 298 218
- real min: 1 064 919
i did a quick test. i got similar figures except the real max and real min were lower. HOWEVER this was with audio, which is also what you appear to be doing, and that makes up the bitrate. that is demux the video and i got around(give or take a BPS) the average i entered. so try demuxxing those tests you did and see if the bitrate is correct(or very close to).

But here is one more fact for you: I load the mpeg muxed by Quenc into the program MPEG-2 Validator, and it says:
i got no complaints of this kind with 2 pass encoding. the only complaints it gave were ones showing the limitations of mpeg2 validator such as complaining about 480(as in 720x480). :)
with CQ i would not be totally surprised though because it is not max bitrate constrained. infact from what you say the CG encode hit 15000bps. so yes i would reccomend doing CQ as elementary stream for sure.

Well as you know, so far as MPEG-1 went, I have had playback issues with many different directshow based decoders.
as i said before this seems to be very footage dependant aswell. that is i can encode 1 clip and it plays back perfectly but encode another, such as that sample you gave me, and it can show imperfections in either picture quality or smoothness of playback etc. it does seem limiting ones self to encoding closer to the limits set for things like dvd are ok though and its large frame sizes with high bitrate that is where these problems are. i have doubts anyone on the ffmpeg crew is going to work on mpeg1 any time soon(at all ?) ,unless you can convince them of the problem. good luck. ;)

Zarxrax
14th June 2006, 00:11
http://zarxrax.kicks-ass.net/surfing-short.mpg

Here is a 6 second mpeg2 clip that I encoded with QuEnc that shows the problem. I encoded with a max bitrate of 15,000. You should be able to reencode this clip yourself and get the same results. I know MPEG2-Validator is probably not the best program for checking this kind of thing, but I haven't found anything else which can provide the infos that it does.

I just found the tool BBINFO.exe from the bbmpeg project, and it also gives me some useful information. It mentions many underflows in the clip I have provided.

dragongodz
14th June 2006, 12:19
i re-encoded the first 7 seconds(bloody stupid splitter shows grey after that while MPC's inbuilt splitter handles it fine) at 2900 and max set to 9000. that went fine.

so can you please try the original footage without audio and also with the audio set to 224 and not 384 ? then see how they go, demuxxing if needed to be sure of the real video bitrate.

Zarxrax
14th June 2006, 18:14
I'm confused, because the clip was only 6 seconds long :p

And my point is that the muxing is not performed properly when the bitrate is higher than DVD compliant bitrate. Within DVD limits everything seems to be fine. Sorry if I didn't make this clear.

In any case, this "program mux rate value" reported by MPEG2 Analyzer seems like it is surely the problem, and this same problem exists both in the mpeg-2 and mpeg-1 encodings. It seems to me that this value should grow as a function of the maximum bitrate, but depending on the mux profile that is selected, it may not.

Selecting DVD profile the mux rate seems always locked to the maximum dvd bitrate. This seems to make sense, but what profile would one use to encode high bitrate content? With the SVCD profile, the mux rate does indeed seem to grow proportionally with the total bitrate, but on the single test encode I made, the mux rate still fell short of what it needed to be (the video stuttered a bit on my hardware card but not anywhere near as bad as with the dvd mux profile).

As far as the mpeg1 profiles, I can't be sure of what is going on with the mux rate, as I know of no tool to analyze this data.

In any case, I think a decent formula for setting the program mux rate would be Maximum video bitrate + audio bitrate + 1000. Does this make sense?

dragongodz
15th June 2006, 04:42
I'm confused, because the clip was only 6 seconds long
hmm load it in to dgindex(for example) and it says 8 seconds long. :)
i think part of the problem is the audio with what i was seeing though. you know 384 for audio is a bit funny and i am pretty sure i said that value shouldnt be used for mp2 uadio.

And my point is that the muxing is not performed properly when the bitrate is higher than DVD compliant bitrate. Within DVD limits everything seems to be fine.
which is not that surprising when you think that its set to dvd muxxing. thanks for this anyway as i am thinking of seeing if changing it fixes any of these problems.

As far as the mpeg1 profiles, I can't be sure of what is going on with the mux rate, as I know of no tool to analyze this data.
well high bitrate mpeg1's, including done by other programs, i have looked at seem to be seen or reported(by things such as mpeg streameye and from memory i think bitrate viewer aswell) as mpeg2 muxxed. they are not of course but it seems that mpeg1 muxxing is not expected to be that high.

_leech_
18th June 2006, 08:57
Hey, i'm doing some DVD upconverting and i'm having an annoying issue with QuEnc. No matter what settings i use or how high i set the bitrate, i always get color banding that's not present in the source. Is there any way to fix this?

Mug Funky
19th June 2006, 03:12
depends what decoders are being used.
banding often happens because of RGB->YUV->RGB conversions, so if you keep these to a minimum you'll be fine.

quenc doesn't inherently cause banding, though all 8x8 block based codecs can do it on very gentle gradients (like flat blue sky, no grain). usually it's all good though.

so yeah, check your decoding, both before quenc and after...

_leech_
22nd June 2006, 08:01
Ok, here are the steps i'm doing:

1. Run AviSynth script through VirtualDubMod and save a small clip with huffyuv. I've looked at the script results and the huffyuv file and am perfectly happy with the results.

2. Pop the huffyuv file in QuEnc with high quality settings and a bitrate of 12000kbps (this is 720p material, remember).

The result is always banding. I've even increased the bitrate to ridiculous levels and i still get banding that's not present in the AviSynth generated video or the huffyuv file. I can post screenshots if necessary.

dragongodz
22nd June 2006, 12:20
I can post screenshots if necessary.
yes please. that would make it easier to understand what you mean.

also a full list of what settings you are using would be helpful.

_leech_
22nd June 2006, 22:05
Hey, you guys were right! Turns out that while i was taking screenshots i had to turn off overlay in WMP, now everything looks like it should. For some reason it was using overlay mode while playing the generated MPEG2 file but not while playing the huff file.

Thasp
28th June 2006, 15:10
I ma having a problem with QuEnc.

Regardless of what settings I have used, the nominal bitrate always comes out to be about half of what I set it to. I use the same avisynth script for quenc that I use for CCE, and CCE has no issues. I tried 2 pass, 1 pass, trellis, no trellis, cbr, vbr, slow and extreme, no slow and extreme, now I just give up. All my script does is point to the d2v, lanczosresize, and decimate.

If anyone has advice on how to fix this, do tell. I need to be able to use queenc since I can't run multiple instances of CCE, and since it only uses 50% of the CPU for HDTV --> DVD compliant MPEG2 encodes, it's a real waste of my dual core opteron.

dragongodz
29th June 2006, 02:32
please post your actual script and if possible a small sample.

Thasp
29th June 2006, 16:03
The b version fixed it. I thought I had the newest version because of the 0.70 number.

masscamp24
6th July 2006, 13:08
The b version fixed it. I thought I had the newest version because of the 0.70 number.

Where can I find the link for 0.70b?

dragongodz
6th July 2006, 14:10
Where can I find the link for 0.70b?
in the very first post in this thread. when you download you should see the name contains 70b. if it doesnt but just 70 then clear your cache and try again.

GeorgeT
15th July 2006, 09:59
Hi! Dragongodz
You did a great job! Thank you very much.
When I converted a movie to MPEG-1, if the max bitrate higher than target bitrate, I got a VBR MPG even though I hadn't check "Use VBR". Please fix this bug. Thanks.

dragongodz
18th July 2006, 04:57
Please fix this bug.
thats a "bug" in libavcodec. i do plan to try and improve things with that. i am currently working on other areas such as better VBR etc so it wont be at the moment.

dragongodz
8th August 2006, 12:33
QuEnc 0.71 released.

not as many changes as i had planned but been pretty busy. so thought i would get these changes out now. :)

go to first post in this thread for download link.

dirio49
8th August 2006, 14:39
thanks for the new version

M4ST3R
8th August 2006, 21:28
Thanks, will try it!

tamahome
9th August 2006, 11:45
thx new version :)
it's me or it encode more quickly with the selected extreme mode ?

Mug Funky
10th August 2006, 02:59
thanks for the update :)

the timed error message thing looks to be a real timesaver... nothing more annoying than setting off a long batch and being greeted with an error and nothing done the next day.

dragongodz
12th August 2006, 05:34
well the timed error is of course only for wrong commands as i stated back in the first (edited)post. its basically so older programs that havent been updated to the command changes ,such as DVD2SVCD can still be used with the newest QuEnc. you just need to make sure QuEnc is set up correctly first so the unused commands are not needed.

hmm the page has had over 150 visitors since this new release, not bad since its not announced on the main doom9 page or other places(videohelp etc). surprised i havent got any more comments about if its ok etc yet though. guess it must be working ok since nobody is jumping up and down complaining. :D

Mr_Odwin
12th August 2006, 07:48
No complaints here, just enjoying the great product you've let us all have. :thanks:

manolito
12th August 2006, 12:38
Yeah, when something is broken, everybody jumps at your throat, but not much feedback if everything just works!

And QuEnc 0.71 does just that for me. It has become my standard encoder for all of my captured AVI to DVD conversions. One pass VBR, no HQ, Scene Change ON, basically the fastest settings. Just as fast as CCE, and no complaints about artifacts whatsoever.

A BIG thank you to Nic and DGZ for this wonderful piece of software!

Cheers
manolito