QuEnc 0.72 [Archive] - Doom9's Forum

dragongodz

7th May 2006, 08:50

new version is 0.72.

QuEnc 0.72
----------
.fixed separate not working with -close
.changed will not encode pulldown when interlaced disabled but pulldown enabled
.small tweak to 2 pass ratecontrol

changes from 0.70 to 0.71
-------------------------
.added 448kbps for audio encoding
.changed CLI parameter error message to timed(4 seconds), compatability with older programs
.added settings, changlog and PSP-IPod texts
.restricted MP2 and MP3 to encode to a maximum of 256kbps even if set higher
.small 2 pass ratecontrol tweaks

changes from 0.61 to 0.70
-------------------------
.improved 1 pass ratecontrol
.improved 2 pass ratecontrol
.improved ac3 encoding low volume problem
.fixed last frames at constant quant
.fixed if max bitrate higher than target bitrate
.fixed 24fps video encoding
.changed ac3 downmix levels to -3dB and dialnorm to -27dB (Dolbys reccomended settings)
.changed mpeg2mux(cli option) to automatically sets QuEnc to mpeg2 mode
.changed extreme setting to not use trellis, tick manually if you want that aswell
.changed other extreme settings
.changed auto max bitrate to x2 if over 3000kbps
.added mpeg1mux cli option ,automatically sets QuEnc to mpeg1 mode
.added mpeg4mux cli option ,automatically sets QuEnc to mpeg4 mode
.added pulldown option(must use interlaced encoding)
.added mpeg4 video mode(specifically PSP profile compatible)
.added aac audio encoding with mpeg4 mode
.added mp3 audio encoding with mpeg4 and snow modes
.added audiocodec cli options aac and mp3 for mpeg4 mode
.added separate mux option to mpeg2 encoding and mpeg2mux(cli)
.added source properties detection to some better display options
.removed -mpeg1 and -mpeg2 cli options, use their mux options instead
.increase mpeg1 buffer size to 224 if max bitrate over 1800kbps or constant quant
.increased buffer size to 392 if max bitrate over 9800kbps(DVD max)
.exposed snow mode (not reccomended for anything but experimentation)

a small note on the cli error change. while what QuEnc thinks is wrong commands, meaning starting with a - , will use a timed error gui plain rubbish will not. so for example
QuEnc.exe -abcd = timed error gui, QuEnc still runs
QuEnc.exe abcd = non-timed gui, QuEnc reports rubbish on the commandline

warning. do not expect me to answer questions on SNOW or MPEG4. i may do but dont expect it.

QuEnc 0.72 binary and source code can be found here(self extracting archives)
http://quenc.bitburners.com/
QuEnc 0.72 binary and source code can be found here(self extracting archives)
http://dragongodz2.googlepages.com/home

the source code to ffmpeg on bitburners is compressed with a different archiver(to self extracting archive). if you have any problems with it please report so and try the other from my googlepage.

enjoy.

buzzqw

7th May 2006, 09:28

:thanks: :thanks: :thanks:

very nice additions !!

BHH

Axed

7th May 2006, 13:07

Wow, amazing work! Thanks to all who worked on it!

Rockas

7th May 2006, 14:46

Thank you so much... I can't wait to test all the new stuff :)

A_T

7th May 2006, 15:25

thanks

danpos

7th May 2006, 15:39

@Dragongodz

Man, how much work you spend over this version ??? A lot of things was done ... Hmmm, I will give a it a try for sure! :)

Many thanks for yours time and efforts to deliver it to us.

Kept up,

Mug Funky

7th May 2006, 17:04

cool! i'll try this out ASAP (it's a bit late so i should probably not try it out just yet).

last frames @ constant quant fix sounds good.

[edit]

-mpeg2 from commandline doesn't seem to work anymore? has it been removed?

not a big deal. i changed my auto-batch already :)

Revgen

7th May 2006, 17:08

Looks like somebody is jealous about HCEnc 0.18.:D

Seriously, thanks for the hard work. I'll definitely be trying this out.

dirio49

7th May 2006, 17:41

NIce
thanks

Zarxrax

7th May 2006, 18:20

Wheeeee! I've been waiting for this :D

Now, here is some problems I'm still having with MPEG1:
I get these strange blocking artifacts at low quants: http://zarxrax.kicks-ass.net/quenc-error.png
This problem seems to have been in the old version too. Trellis and extreme are both disabled. Is this something that could maybe be fixed, or is there a specific quantizer at which these artifacts might begin to appear?

Other than that I still have the same old problems with buffer overflows. I'm getting them even with max bitrates as low as 1800! 1800 can be a decent bitrate for VCD-resolution material, but sometimes I would like to make an mpeg-1 at 640x480 or maybe even higher, and not have to use such a low bitrate that it looks like crap :(

Sagittaire

7th May 2006, 19:52

There are very good new function in libavcodec:
- new adaptative bframe decision
can save 4-6% of size
- new bframe refine
can save 2-4% of size

example at constant quant q3 (I,P and B)
reference at 2 no adaptive bframe: 2484 Kbps
new adaptative bframe: 2330 Kbps
new bframe refine: 2409 Kbps
combinaison: 2261 Kbps

Combinaison of new adaptative bframe and new bframe refine can save 6-10% of size (more than RDO ... !!?) with exactly the same quality ... :eek:

Moreover adaptative bframe is really good for visual quality with less bframe in high motion part. With that you can (IMO you must) choose higher ratio/offset for bframe and higher curve compression quantizer: overall visual quality will be really better. Personnaly for best visual quality I choose light ratio/offset at 0/1 for bframe and Adaptative Quantisation for intra/inter with inter quantizer masking at 25%. For example if intra are q4 then inter block for pframe will be q5 and bframe q6.

Sagittaire

7th May 2006, 19:59

Now, here is some problems I'm still having with MPEG1:
I get these strange blocking artifacts at low quants: http://zarxrax.kicks-ass.net/quenc-error.png
This problem seems to have been in the old version too. Trellis and extreme are both disabled. Is this something that could maybe be fixed, or is there a specific quantizer at which these artifacts might begin to appear?

What did you use like CQM?
What is your quant for this frame?

Zarxrax

7th May 2006, 21:50

What did you use like CQM?
What is your quant for this frame?

Here is the settings used:
http://zarxrax.kicks-ass.net/quenc-settings1.png
http://zarxrax.kicks-ass.net/quenc-settings2.png

Looks like it happens at quant 1 and 2. I haven't seen it so far on quant 3 or lower.

Darksoul71

7th May 2006, 22:02

Thnx, dragongodz,

new testing stuff for my multicore / multi CPU frontend for QuEnc :)

I´ll report back if I feel like I tested enough :D

dragongodz

8th May 2006, 00:56

Thanks to all who worked on it!
that would be Nic and i with the pulldown code from mean. :)

-mpeg2 from commandline doesn't seem to work anymore? has it been removed?
i quote from the change log in the first post ;)
.removed -mpeg1 and -mpeg2 cli options, use their mux options instead

here is some problems I'm still having with MPEG1
i do plan to play with mpeg1 more just not at the moment, so dont think i have forgot. :)

EDIT:
Looks like somebody is jealous about HCEnc 0.18. :D
what a strange idea. especially considering
http://forum.doom9.org/showthread.php?p=811201#post811201
and if you read the thanks.txt that comes with HC you will see me mentioned aswell. :)

danpos

8th May 2006, 03:49

@Dragongodz

*Source: I cut off a small clip of AVI in order to test this new release out. It has: 8123 frames / 23.976 fps / XviD / MP3

*QuEnc settings: GOP 15 / B-frames 2 / Interlaced encoding (in order to enable built-in pulldown) / Aspect Ratio 4:3 / Max bitrate 9800 Kbps / Default QuEnc matrix / Profile DVD / Audio codec AC3 128 Kbps / 2 pass VBR - average bitrate 2180 Kbps.

*AVS Script:

AVISource("D:\Testes\clip.avi",true,fourCC="XVID")

eedi2().turnleft().eedi2().turnright()
BlindPP(quant=8, cpu2="xxxxoo", moderate_h=45, moderate_v=55)
Blockbuster(method="noise",detail_min=1,detail_max=3,variance=0.1,seed=1)

aSharp(2.5,4.5,0.25,hqbf=true)
YlevelsS(0,1.6,255,0,255)

LanczosResize(704,352,0,0,1280,704)
AddBorders(0,64,0,64)

*Author DVD: ended up the encoding, I just used the Author DVD tool built-in into QuEnc and it delivered to me the folders AUDIO_TS and VIDEO_TS.

*Playback of authored DVD:

- WinDVD: it plays fine but the time showed was 05 minutes 42 seconds instead of 05 minutes 38 seconds.
- VLC: it plays fine but the time showed was 01 minute 20 seconds instead of 05 minutes 38 seconds.
- MPC: it plays choppy, with several stuttering to long whole movie.

*Bitrate graph:

http://img481.imageshack.us/img481/7215/shot429vq.jpg (http://imageshack.us)

We can see that didn't happen any bitrate spike over the maximum for DVD spec (9800 Kbps) !!! :) So, the MPEG2 videostream is in compliance with DVD spec. ;)

*Quality of image: amazing! :)

This is the first time that I used this encoder since ages. The last time that did use it it wasn't really so good as much as now. I really liked of audio encoding integrated with video one, the quality of AC3 delivered, the built-in DVD author tool (good for simple authoring).

I consider this release a HUGE one and in fact QuEnc 0.7 is worth a try for sure.

My R$ 0,02 ... ;)

Kudos,

Mug Funky

8th May 2006, 03:57

one thing to note: bitrateview is not at all accurate in determining max bitrates. it gets the quants about right, but gives such variable results for bitrate spikes that it's only useful as a guide.

for example, all results displayed by it are /1.024. so your actual max is 9837.568... not too shabby though.

however, when you put that in an authoring app it'll probably report a much lower max rate...

@ DGZ or nic:

.changed ac3 downmix levels to -3dB and dialnorm to -27dB (Dolbys reccomended settings)

would it be possible to make these numbers accessible via command line? those are the values i usually use anyway, but sometimes a louder source comes along, or a really quiet one...

ricardo.santos

8th May 2006, 12:32

Hi everyone!

Thanks Nic and Dragongodz for this new beta, ive made some tests and altough im not an expert everything seems ok, no playback problems on most players, AC3 sounds ok to me altough as i live in Pal land i use Mpeg2 for audio on my conversions.

Just a quick question:

when converting to dvd i have to use avisynth or fitcd to resize to dvd resolution, isnt it possible for Quenc to resize?

Rockas

8th May 2006, 13:27

when converting to dvd i have to use avisynth or fitcd to resize to dvd resolution, isnt it possible for Quenc to resize?
No... you really need to use an AviSynth script.

dragongodz

8th May 2006, 13:56

danpos - yes the playback time is a known problem. the funny thing is not all players/filters/codecs have the problem. try burning it to a dvd-rw and see if your real dvd player can tell the real time or not. or you could even try authoring with something else and see if that changes it.

also max bitrate with pulldown should always be lowered and thats with all encoders. i know its been discussed a few times in the past how setting a high max bitrate has caused playback stutters with real dvd players, again this is not just QuEnc. so i would reccomend setting a max of something like 8000 or maybe even slightly lower.

isnt it possible for Quenc to resize?
as Rockas said QuEnc uses Avisynth for its input. so to add resizing in QuEnc aswell would be simply repeating what Avisynth can already do and bloating QuEnc.

manolito

8th May 2006, 18:47

Thanks DGZ for this new version. My favorite encoder ATM.

I just tested it with DVD-Rebuilder 0.97 free and DVD2SVCD 1.23 build1. DVD-RB works as usual (with the exception that the free version shuts down custom matrices), but DVD2SVCD bombs out with a "bad parameter" error. This is due to the now nonexistent -mpeg2 parameter.

Could you please change QuEnc's behavior for the next version so that it just ignores the -mpeg1 and -mpeg2 parameters without throwing an error? It is quite unlikely that there will be an updated version of DVD2SVCD in the forseeable future, and it's author went out of his way to add full support for QuEnc 0.61 to the current version (with a little help from myself).

For now I wrote a small wrapper for QuEnc 0.70 which makes it compatible with DVD2SVCD. Have a look here: http://forum.doom9.org/showthread.php?p=825017#post825017

Cheers
manolito

Revgen

8th May 2006, 19:42

what a strange idea. especially considering
http://forum.doom9.org/showthread.php?p=811201#post811201
and if you read the thanks.txt that comes with HC you will see me mentioned aswell. :)

I was kidding. I thought the smiley was a good hint.

dragongodz

9th May 2006, 04:48

Could you please change QuEnc's behavior for the next version so that it just ignores the -mpeg1 and -mpeg2 parameters without throwing an error?
yes i can do that. to be honest i knew it worked with DVD-RB but i didnt think about any other program.

I was kidding. I thought the smiley was a good hint.
hahaha yes i know you were just having a little dig so i decided to play back. thought the smiley i put at the end was a hint aswell. ;)

kevin23

9th May 2006, 05:27

Was trying the new version , quality is excellent though when Trellis Quant is enabled i had these wierd horizontal lines in some frames.

Eg

http://img325.imageshack.us/img325/9303/bscap0007hm.jpg

Here is without Trellis Quant

http://img325.imageshack.us/img325/1094/bscap0028pn.jpg

dragongodz

10th May 2006, 02:43

Trellis Quant is enabled i had these wierd horizontal lines in some frames.
can you show it with the actual same frame ? that is load the clips in to something like the mpeg2 version of virtualdub and save off the exact same frame. also what type of frame is this ? can you show I and P frames ?

upon a litle inspection trellis seems to be giving a lower file size while in 0.61 it pushed size up slightly. whether this is because changes made for ratecontrol or because its a newer version of libavcodec i cant say at the moment. i will have a look at this later and see if i can improve it. until then i probably wouldnt worry about using trellis.

leiming2006

10th May 2006, 07:22

That's very good.
Thanks for offering such good software.

Trixter

10th May 2006, 17:50

Revgen

10th May 2006, 20:22

Not one that's free.

There are commercial ones that cost into the $100's.

Revgen

11th May 2006, 00:18

I just recorded a 2hr 4 min movie at 4500kbps and 23.976fps. It came out at 3.20GB. Is this the right size? It seems too small to me.

Here are my settings:

quenc -i J:\star\star.avs -o J:\star\star.m2v -b 4500 -maxbitrate 8500 -dc 9 -priority 3 -2 -hq -vbr -scene -notrell -nocgop -nointerlaced -noextreme -gopsize 18 -maxbframes 2 -noqlb -nocmatrix -aspectratio 16:9

Rockas

11th May 2006, 09:33

dragongodz

11th May 2006, 13:13

It came out at 3.20GB. Is this the right size? It seems too small to me.
yes for that bitrate it should have been something like 4gb. if you get the time could you see what QuEnc 0.61 does aswell with that same source ?

Is there a better tool out there for this sort of thing, or is bitrateview it?
mpeg streameye is much better. if you hunt around you should be able to find version 1.1 or you could download the very short period trial version 2.

rhys87

12th May 2006, 11:25

I used the following aviscript
AVISource("C:\movie.avi")
LanczosResize(720,576)
AssumeFPS(25.000, true)

and used the following settings
http://img135.imageshack.us/my.php?image=quenc7gt.jpg
http://img135.imageshack.us/my.php?image=quenc26sf.jpg

The end result was a mpeg file which was 0kb, any help would be appreciated :)

dragongodz

12th May 2006, 13:23

can you try playing the .avs with MediaPlayerClassic or similar player ? is it ok ?

also you could probably throw a converttoyv12() on the end of the script to make sure nothing has gone wrong there.

Mug Funky

12th May 2006, 15:43

@ revgen:

that's 3695 kbps... bit undersize. but that could mean the encoder is saturated (this is likely on a smooth source, possibly letterboxed, and when the QLB matrix is used). it could also mean an undersized encode too. though i don't like bitrateview, it will tell you which is which - if it's at quantiser 1 for most of the movie, you know that te encoder is saturated and a different matrix is needed (or you could apply some sharpening filters to the movie - that'll make it use more space).

@ rhys87:

it's possible quenc is crashing on the second pass - it'll re-load the script at the beginning of the 2nd pass, and any instabilities will result in a crash.

it you have virtualdubmod (the one with an avisynth script editor) you can try load a script, open the script editor, then hit F5 to re-load and seek to current frame. generally, if virtualdub crashes here, then it's not safe to do a 2-pass encode with quenc either. you're using a pretty basic script though... so i'd be worried. usually it's plugins that cause the crashes (smartdecimate does it for me, so i can only use it for 1-pass encodes...).

good news is that at the bitrate you've specified, 1 pass will look perfectly alright and save you a bunch of time :)

Revgen

12th May 2006, 16:00

Zarxrax

13th May 2006, 03:16

Dragongodz: I got that MPEG Streameye program that you mentioned, and noticed that on MPEG-1 files, if I enable the "use vbr" option, the final frame is always VERY large. Is this a known problem?

dragongodz

13th May 2006, 13:02

if you downloaded QuEnc 0.70 please redownload it. it should have 70b in the filename. this is for a very minor change which , for whatever reason, helped increase the bitrate on Revgens film. strangely enough it also increases the speed back to QuEnc 0.61's speed where the first 0.70 was running slower.

and noticed that on MPEG-1 files, if I enable the "use vbr" option, the final frame is always VERY large. Is this a known problem?
not unless it makes it go above max bitrate. i havent seen any problems mentioned about it so until then i have to assume its ok.

Zarxrax

13th May 2006, 16:44

not unless it makes it go above max bitrate. i havent seen any problems mentioned about it so until then i have to assume its ok.

Yes, it was indeed well over the max bitrate. But you know what? Since I just downloaded the .70b, I can't reproduce the problem anymore, so maybe its fixed now :)

Edit: Nevermind, a new file I encoded just had the problem. Ill keep testing to see exactly what is causing it. Im not so sure its just the VBR switch anymore.

Edit2: It seems to be the MP2 audio bitrate causing the problem. If I set it to 256 or lower, its fine. Setting it to 384 though causes the last frame to be huge.

dragongodz

14th May 2006, 06:24

Edit2: It seems to be the MP2 audio bitrate causing the problem. If I set it to 256 or lower, its fine. Setting it to 384 though causes the last frame to be huge.
how strange. the audio bitrate should have no effect at all on the video bitrate. will look in to this later.

Revgen

14th May 2006, 21:02

how strange. the audio bitrate should have no effect at all on the video bitrate. will look in to this later.

It could be a muxing issue. The decoder may be analysing both video and audio bitrate when it should be only doing video. This may make it appear to be larger than maxbitrate to this app. Remember that computers are dumb.:D The fact that the issue occurs at the end of the video only reinforces my suspicions.

jul059

16th May 2006, 05:41

Hi, and thanks for the great release!

I have found a minor "bug" that you might want to correct. when you pause the encoding for a while, it seems the encoder keeps counting the time, even though it is not actually encoding. This leads to a huge FPS drop when the process is resumed.

But anyway, thanks for this awesome encoder!

petermg

17th May 2006, 16:15

Zarxrax

17th May 2006, 17:51

http://forum.doom9.org/showthread.php?p=824601#post824601

Can someone respond to the buffer overflow problem? I love the quality of this application, but I stopped using it because my DVD MUXING would fail due to the buffer overflow issues. I'd love to know how to avoid this problem, is it a bug with the application or a simple DVD COMPLANCE settings issue that must be configured by the end user?

For right now, I think about all you can do is use a lower max bitrate. If you are using mpeg2 with pulldown, use a max bitrate of 8000... without pulldown I think you can do about 9800, maybe a little less. For MPEG-1, you need to stop around 1500.

manolito

17th May 2006, 18:01

In my experience the buffer overflow problems for MPEG2 are completely solved since the rate control tweaks DGZ made in 0.62 Alpha5. There is the occasional hickup when I use Mplex for muxing, but this is most certainly the fault of Mplex. Muxman sometimes reports a max bitrate of about 10500, but it never complains about buffer problems. And if Muxman does not report problems, then the encode is DVD compliant...

Cheers
manolito

Zarxrax

18th May 2006, 03:15

I have a question regarding field order.
I used a 23.976 fps progressive source as input, and in QuEnc settings, I disabled interlaced encoding.

When I put the resulting MPEG2 file into dgindex, dgindex says it has "corrected" the field order. Does this mean there is a problem with my encode? Is it due to my settings?

dragongodz

18th May 2006, 07:59

Can someone respond to the buffer overflow problem? I love the quality of this application, but I stopped using it because my DVD MUXING would fail due to the buffer overflow issues.
the link you gave is about mpeg1 specifically. its a strange problem because i can not replicate it always. that is i can encode some things high bitrate mpeg1 and they are fine. however 1 test clip i got from Zarxrax doesnt work as good.

When I put the resulting MPEG2 file into dgindex, dgindex says it has "corrected" the field order. Does this mean there is a problem with my encode? Is it due to my settings?
hmm since you are encoding progressive i dont know offhand why it would be complaining about field order. try doing the same with some other encoders such as HC etc and see if you get the same message.

Zarxrax

18th May 2006, 17:11

Ok, I have figured out what is happening here, and it looks like a QuEnc bug.

- Interlaced box unchecked > Pulldown box "disabled" but still checked -> Causes dgindex to report the error.

- Interlaced box unchecked > Pulldown box unchecked -> No error.

- Interlaced box checked > Pulldown box checked -> Error.

So basically, when interlaced is not checked, it doesnt seem to disable the pulldown option automatically, even though the box is gray.

Also, it would seem that there is a problem with QuEnc's pulldown code, as dgindex reports an error when I use the pulldown in Quenc. If I do pulldown with Pulldown.exe, there is no error reported.

dragongodz

19th May 2006, 00:33

Zarxrax - thank you for narrowing that down. i will look in to that.

Mug Funky

19th May 2006, 01:08

the only samples that cause quenc to spike are of the "uncorrelated noise" type in my experience.

unfortunately this can include real video, like particle effects, bubbling water with strong reflections, and the "gateway" sequences in Cowboy Bebop.

i think quenc or most probably ffmpeg needs to allow (more?) skipped blocks in these cases. in the special case of bitrate above max, it can be assumed that quality is no longer important and all that matters is getting the bitrate down. this can look ugly i imagine...

Zarxrax

23rd May 2006, 03:00

I recently found an old encoder based off QuEnc called NuEnc. It has some really awesome features, such as the status window that shows lots of useful statistics. Could some of this stuff be added into QuEnc? Especially some things like Peak bitrate, overflow count, and psnr. Those would be really useful. Also it lets you specify the VBV buffer size. It seems like that would be a useful thing as well.

I have noticed that QuEnc often overshoots the max bitrate that I specify, so being able to see this as it encodes is a lot more handy than having to load the mpeg2 up in some external program to check the bitrate after its done.

Also one other tiny request, its really more of an annoyance than anything else. When you are typing in the bitrate, could it be made to not throw up an error message until you change the focus from the bitrate text area? A lot of times I will delete the bitrate to type in something different, and as soon as i backspace over the last number it pops up an error message and i have to click on it.

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

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

Rockas

12th August 2006, 12:51

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.

Sorry mate!
I've been extremely busy on the last weeks (months?)... I really didn't had the chance to test it yet... but I will... as soon as my vacations start :)
But... knowing you... I'm pretty sure that it can't be worst than the last release.

keep it UP

A_T

12th August 2006, 21:44

I always use QuEnc to re-encode my dvds. The results are always of terrific quality but the final output size can vary greatly. No too much of a problem when it's undersized but a pain in the backside if it's even a lttle too large.

But thanks anyway. :D

dragongodz

13th August 2006, 01:46

I'm pretty sure that it can't be worst than the last release.
umm thanks, i think .... that was a compliment wasnt it ? ;)

Yeah, when something is broken, everybody jumps at your throat, but not much feedback if everything just works!
haha ye the wonderful world of free software. :)

Rockas

13th August 2006, 11:14

umm thanks, i think .... that was a compliment wasnt it ?
Of course!
You know that I'm a big fan of your devotion to the "cause"! :)

haha ye the wonderful world of free software.
See what I mean?

People that develop freeware applications only have two ways!

1st - They're completly out of their minds

2nd - They're great people that can't support the idea of not sharing knowledge and that everything worths money...

On this one... I'll let you choose LOL LOL LOL

ljpp

14th August 2006, 20:32

Okay, QuEnc is about to get a new home - right next to HC Encoder here at http://quenc.bitburners.com/ . The page(s) are still very rough around the edges, as they were constructed in extreme hurry.

However, the binaries are there waiting for downloaders.

dragongodz

15th August 2006, 06:06

On this one... I'll let you choose LOL LOL LOL
i am sure i would get votes for both. ;)

updated the first post with bitburners page link. thanks to ljpp for providing hosting.

easyfab

15th August 2006, 20:38

Thanks for this tool.

For info is it multithreads optimized? or possible ?
Because it's based on ffmpeg and i see in ffmpeg a "-threads 2" option.

I tried with setmtmode(2) in avs script and it give me only ~2fps faster 24fps->26fps.

Boulder

15th August 2006, 23:16

easyfab

16th August 2006, 10:59

Thanks :)

dragongodz

17th August 2006, 08:50

For info is it multithreads optimized?
currently QuEnc is not multi-threaded.

note i have now uploaded the ffmpeg source used by QuEnc on the bitburners page. i have used a different archiver which compresses even better than 7zip. if you have any problems then try the version on my googlepages but also please report here aswell.
note the one on bitburners is meant to be only for windows 2000/xp.

Nic

17th August 2006, 10:30

It's a sad state of affairs when I'm far more interested in that KGB Archiver than I am the new version of QuEnc :(
Thanks for keeping QuEnc alive Dgz :)

-Nic

EDIT: Ahh, KGB is based on PAQ6. Nothing new & interesting there then :(

dragongodz

18th August 2006, 07:06

Thanks for keeping QuEnc alive Dgz :)
not a prob and nice to hear from you Nic.

Ahh, KGB is based on PAQ6. Nothing new & interesting there then :(
well its open source and compressed the ffmpeg source files down more than 7zip(about 600k smaller using medium setting). so less for me to upload on a slow upload speed account.
of course it is as slow as all hell archiving and even decompressing which is why i only used it on the ffmpeg source.

kyuuketsuki

18th August 2006, 15:34

dragongodz,

I was looking for your email but can't find it anywhere. Anyway, just wanted to let you know that I belong to a community that has been using QuEnc for a long time. I personally think it is the best free encoder out there. I would not be exaggerating to say that thousands of us are using it. Since we are also using dvd2svcd and QuEnc became incompatible with 0.70, we've been anxiously awaiting the next version.

Thanks for the fixes and upgrades.

Boulder

18th August 2006, 15:40

Doesn't the latest version work? At least manolito reported in the DVD2SVCD section here that it does work (he had created a batch file that was a workaround for the problem).

kyuuketsuki

18th August 2006, 20:58

I haven't actually tried it yet since I am still at work, but I will try tonight. I assume that it does work though since it was reported by manolito.

Sorry for any confusion. When I said "next" version, I meant next after 0.70. I should have said "this version".

MrC

29th August 2006, 16:40

It seems that 0.71 version brings back some file undersizing problems (solved in previous versions) when 2pass encoding.

Feeded with the following AVS script:

Video = DirectShowSource("clip.avi")
Audio = DirectShowSource("clip.avi")
AudioDub(Video, Audio)
ConvertToYV12
LanczosResize(720,576,0,0.5)

(clip.avi is a 640x480 1114kbps 25fps DivX5 + 128kbps CBR 2ch MP3)

and with following settings:

VBR on, HQ on, 2pass on, Extreme off, GOP off, Matrix off, 4700 avg bitrate, 6700 max bitrate, DC 10, 4:3, Audio AC3 192kbps, DVD mux profile

Theroretical -> 1,580,204,032 byte
QuEnc 0.70 -> 1,489,737,728 byte
QuEnc 0.71 -> 940,064,768 byte

:confused:

Bye
________
head shop (http://headshop.net)

GeorgeT

2nd September 2006, 21:57

Dragongodz
QuEnc0.71commandline refuses my mpeg1 option. Would you please recover it? Thanks.

Mr_Odwin

2nd September 2006, 22:32

Dragongodz
QuEnc0.71commandline refuses my mpeg1 option. Would you please recover it? Thanks.

The command line arguments have changed. You need to use -mpeg1mux instead. Run quenc /? to see all the commands.

GeorgeT

3rd September 2006, 07:20

The command line arguments have changed. You need to use -mpeg1mux instead. Run quenc /? to see all the commands.:) :)
Mr_Odwin, Thanks for your reply.
Because QuEnc0.61 acccept mpeg1 but can't accept mpeg1mux, so I never try mpeg1mux on QuEnc0.71.
Thank yoy very much. Mr_Odwin, you did a great help!:D :D

tamahome

3rd September 2006, 14:44

which is the command line to use a matrix custom?
-cmatrix and?
an example of command please :)

Mug Funky

3rd September 2006, 16:00

-cmatrix "drive:\path\matrix.xcm"

or -nocmatrix (for MPEG-standard)
or -qlb

dragongodz

4th September 2006, 01:21

QuEnc0.71commandline refuses my mpeg1 option
which is the command line to use a matrix custom?
good thing i didnt waste my time writing text files such as QuEnc_changelog.txt and QuEnc_settings.txt as i have a feeling nobody would read them if i did. :devil:

GeorgeT

5th September 2006, 14:32

Hi! Dragongodz, Ask for your help! Please!
I got twinkle-like images; when I used QuEnc(any version) convert the enclosed sample DVD clip to VCD. May I ask how to setting or any methods to solve this problem. (In mpeg-1, cbr, 1150kbps, and maxbitrate 1150)
If somebody can help me to handle this, I am appreciating for your help too.
Sample DVD clip. Name: DVD.7z Size: 9MB (Choose one of two)
http://www.sendspace.com/file/g7q2ng
http://files.filefront.com/DVD7z/;5466148;;/fileinfo.html
#-------------------------------------------------------------------------
LoadPlugin("C:\Program Files\AvPack\AviSynth 2.5\plugins/DGDecode.dll")
MPEG2Source("DVD.d2v")
Sharpen(0.2)
LanczosResize(352,240)
ConvertToYV12()
#-------------------------------------------------------------------------

DDogg

6th September 2006, 01:30

dragongodz, as you might remember, back in the dark-ages, I had a habit of deriving the bitrate from a 1% CCE OPV encoded at an empirical Q (say 28) using (((Sample_Size_In_Bytes*(100/Sample_Size_Percentage))*8)/1000)/(Total_Frames/Frame_Rate)

This DABR gave me some fingerprint data on the complexity of the source and allowed some general projections of the bitrate requirements needed to contain the source complexity.

I would like to do something similar with QuEnc0.71 for experimentation purposes, but I am having a little trouble with the docs. Could you recommend your command line syntax that would be appropriate?

I do realize CCE's opv mode is unique to their proprietary product, but generally I am looking for a constant quant type of thing that will allow the source complexity to control the bitrate within some low/high legal limits.

I only need it to create the 1% sample, not the full encode. I'll use 2 pass for that.

I've been away from this stuff a long time, so I hope you can bear with my post being less than precisely worded. I also understand my theories linked in my sig, if you could call them that, were not universally accepted. However, they worked for me and I would like to see if they could also do so with this rather extraordinary thing called Quenc.

Rhetorically speaking, who would have ever thought a free mpeg encoder would rival multi-thousand dollar software? Real nice job you guys have done.

Mug Funky

6th September 2006, 04:00

hmm. that would work, but:

- i'm not sure if quenc supports floating point constant quant, so you'd have to round upward to avoid oversizing (FYI, enter any bitrate lower than 31 and it'll go into constant quant mode).

- max bitrate isn't enforced in constant quant mode, meaning you're likely to get incredibly high peak bitrates unless your CQ value is really high.

manolito

6th September 2006, 14:01

Hi DDogg,

long time no see...
max bitrate isn't enforced in constant quant mode, meaning you're likely to get incredibly high peak bitrates unless your CQ value is really high.
I believe that this is the main obstacle. HC does have a CQ mode which does enforce the max bitrate setting, but QuEnc does not. You're asking for major trouble in the muxing / authoring stage.

I suggest to check out QuEnc's one pass VBR mode. I am not sure how this mode is implemented, Nic was not very clear about it. Probably start with a fixed quantizer and at certain time intervals analyze file size and adjust the quantizer accordingly? All I know that this mode always reaches the target file size, and the tweaks DGZ made in the current version make for a surprisingly good rate control. So far version 0.71 never gave me an encode that Muxman would refuse.

Cheers
manolito

DDogg

6th September 2006, 14:12

(FYI, enter any bitrate lower than 31 and it'll go into constant quant mode). That's what I needed, thanks very much.- max bitrate isn't enforced in constant quant mode, meaning you're likely to get incredibly high peak bitrates unless your CQ value is really high. Shouldn't be a problem with what I am doing as it is used only as a general indicator. Say you have 4 encodes to put on one dvd - The simple way is to calc a group bitrate for all the sources to hit the size target. But, for conversation purposes, say 2 of the 4 sources are Matrix and SPR. SPR requires 3 times the BR of Matrix. That is going to be a problem. If we can do the sample and calc the DABR of the samples we then have a number to indicate how to better allocate bitrate to SPR and steal some from Matrix. We can still use a bitrate based final encoding method to keep the size under control, but we also have a way to generally control the viewing quality of the disparate sources.

/add: clarification - each individual sources might use a different bitrate, but the average of those individual bitrates used will still be the same as the average that was calculated originally to fit all 4 sources on the DVD. The total bitrate available is simply better distributed to where it is needed.

Hopefully this will work with QUenc as it does with CCE. I'll play around with it and see.

Mug Funky, thanks again for your reply. I've learned a lot from your posts in the past.

DDogg

6th September 2006, 14:30

Hi DDogg,

long time no see...

... HC does have a CQ mode which does enforce the max bitrate setting, but QuEnc does not. You're asking for major trouble in the muxing / authoring stage.
manolito ...Hey buddy! Yep, life has a way of getting in front of my hobbies :)

Actually I want the QUenc encoding method that most triggers a higher bitrate when it encounters a higher source complexity, even if the rates are crazy. This gets me a sample DABR that tends to mimic the source complexity. I was actually worried the CQ mode might have been throttled which would mess me up. Any suggestions? These non bitrate based methods don't seem to be documented too heavily. I suppose it is a form of self protection for the authors :)

manolito

6th September 2006, 16:05

@DDogg
Hey, I should have reread the link in your signature before answering...

CQ mode in QuEnc really is hardly documented at all. Probably because you cannot really use it for making compliant DVDs. But for your method it seems to be ideal.

I normally use a method very similar to yours when I am not sure if I will be able to get a decent quality for a very long encode. The actual conversion is done with QuEnc one pass VBR, but before this I use D2SRoBa with CCE 2.70.02.10 trial to find out which Q value I would get. This CCE version has no logo embedded in the output, so the result should be comparable. If my Q is not satisfactory, then I can do something about it, and if it is, I go ahead encoding with QuEnc. Certainly not scientifically correct (because I assume that CCE and QuEnc have similar characteristics), but so far I always had success with this method.

Cheers
manolito

MrC

11th September 2006, 12:37

It seems that 0.71 version brings back some file undersizing problems (solved in previous versions) when 2pass encoding.

Feeded with the following AVS script:

Video = DirectShowSource("clip.avi")
Audio = DirectShowSource("clip.avi")
AudioDub(Video, Audio)
ConvertToYV12
LanczosResize(720,576,0,0.5)

(clip.avi is a 640x480 1114kbps 25fps DivX5 + 128kbps CBR 2ch MP3)

and with following settings:

VBR on, HQ on, 2pass on, Extreme off, GOP off, Matrix off, 4700 avg bitrate, 6700 max bitrate, DC 10, 4:3, Audio AC3 192kbps, DVD mux profile

Theroretical -> 1,580,204,032 byte
QuEnc 0.70 -> 1,489,737,728 byte
QuEnc 0.71 -> 940,064,768 byte

Am I really the one having this kind of problem? Or it is well known and will be fixed with next release?

:confused: :thanks:

Bye
________
cheap volcano vaporizer (http://vaporizers.net/volcano-vaporizer)

manolito

11th September 2006, 12:50

Am I really the one having this kind of problem? Or it is well known and will be fixed with next release?

:confused: :thanks:

Bye
No, you are not the only one. Take a look here:
http://forum.doom9.org/showthread.php?p=864296#post864296
And in your case the reason for undersizing could be the same as in the other thread. Your source was already heavily compressed, so QuEnc really had no use for the much higher bitrate you specified. Suggestion: look at your quantizer values. If the average quant is 1 (or close to 1) then you already have the maximum quality QuEnc can deliver for this source with this matrix. The only way to avoid undersizing would be padding, but this is not desirable.

Cheers
manolito

MrC

11th September 2006, 14:59

Thanks Manolito for your clear answer. :)

One more thing I cannot figure out: why QuEnc 0.70 was closer to target in filesizing than QuEnc 0.71? There is really a big difference! 0.70 did padding?

:confused:

Bye
________
hemp marijuana (http://marijuanahemp.com)

manolito

11th September 2006, 16:07

changes from 0.70 to 0.71
-------------------------
.small 2 pass ratecontrol tweaks
This is something you will have to ask DGZ about. I mostly use QuEnc in 1-pass VBR mode (quality is amazing, on my standard CRT TV I could never see a difference between 1-pass and 2-pass), so I'm not affected by these ratecontrol tweaks.

Cheers
manolito

Mr_Odwin

13th September 2006, 14:24

I'm not sure if this is a bug - to me it is.

This:

http://img241.imageshack.us/img241/930/nopullqt8.jpg

and this:

http://img145.imageshack.us/img145/5958/pullqe1.jpg

result in different files. (All options are the same except that pulldown is greyed-out selected in the lower image.)

As a consequence of the above, I think either pulldown should be turned off when interlaced encoding isn't selected, or provide a command line option for it, -nopulldown perhaps?
I noticed this because Muxman was saying that the files I was inputting weren't dvd compliant. (GOP too large, 45 instead of 36.)

dragongodz

19th September 2006, 06:42

Am I really the one having this kind of problem?
it only happens that bad some times. you should notice though that some bad frames/low quality issues were fixed even at the lower average rate. yes i will look at this when i get time to readjust the bitrate distribution.

I'm not sure if this is a bug
yes a very small one. it was already reported so i do plan on fixing it.

P.S.
just so people know, i have been trying to update LAVC + LAME + FAAC. LAVC and LAME both compiling fine and LAME being found etc. however FAAC doesnt want to compile properly even after i updated all of cygwin (158mb download). comes close but still no go. so i may give updating a miss for now because it is driving me batty.

Mntneer

5th October 2006, 17:43

Is there a reason why QuEnc would stop encoding after the output file reaches 1GB? I'm trying to go from HDTV to DVD, following the instructions on the "HDTV to DVD" guide, http://eswrite.50megs.com/hdtv2dvd.html, and have tried running the encode twice, but both times the encoding stops part way through.

Could it be a problem with the source MPG?

Any suggestions on going from .TS to DVD compliant .MPG?

Mug Funky

6th October 2006, 08:13

there's no size-limit reason, so it might just be a crash in your file.

try open the part-finished file in virtualdub or similar, seek to the last frame, and then open up the script and seek to just before the same spot. advance a few frames and see if the program crashes... (do not hit play - virtualdub might disappear and leave an overlay window stuck in the screen with no way to close it... happens to me a fair bit and i have to reboot to fix).

Affar

6th October 2006, 08:25

Hi

I have little problem with this command line:

quenc.exe -i "C:\avs001.avs" -o "C:\sample.mpg" -b 1600 -maxbitrate 2500 -dc 10
-priority 4 -1 -mpeg2mux -nohq -novbr -noscene -notrell -nocgop -nointerlaced -noextreme
-gopsize 15 -maxbframes 2 -nocmatrix -aspectratio 4:3 -mpeg2mux separatepases -audiocodec mp2 -audiobitrate 160
-auto -close

If i use -close setting, quenc only compress video.

Thanks :)

Mr_Odwin

6th October 2006, 09:29

Looks like you have separatepases instead of separatepasses.

Mntneer

6th October 2006, 14:14

GeorgeT

8th October 2006, 20:55

maxfu

26th October 2006, 11:16

Any batch processing GUI tool for QuEnc.71?

Affar

3rd November 2006, 03:28

The -mpeg2mux appearance twice.

Yes, but if i try this line, i have same problem

quenc.exe -i "E:\avs.avs" -o "E:\1.mpg" -b 1600 -maxbitrate 2500 -dc 10 -priority 4 -1 -hq -vbr -scene -notrell
-nocgop -nointerlaced -noextreme -gopsize 15 -maxbframes 2 -nocmatrix -aspectratio 4:3 -mpeg2mux separate
-audiocodec mp2 -audiobitrate 160 -auto -close

Only compress video. But if i exclude -close option, audio and video are compressed ok.

Thanks

Mr_Odwin

3rd November 2006, 11:50

You have separate instead of separatepasses.

Affar

4th November 2006, 03:01

You have separate instead of separatepasses.

Command Line options in Quenc 0.71

-mpeg2mux *** = MPEG-2 Mux Profile( dvd, svcd, novideo, noaudio ,separate)

Really problem is in -close. without this option, the compression of audio and video is correct.

Thanks

dragongodz

4th November 2006, 04:26

problem is in -close. without this option, the compression of audio and video is correct.
confirmed. will look at it when i get time. had absolutly no time recently though so can not say when.

thanks for finding it though. :)

Affar

4th November 2006, 19:52

confirmed. will look at it when i get time. had absolutly no time recently though so can not say when.

thanks for finding it though. :)

Thanks for your work with Quenc :)

maxfu

5th November 2006, 08:57

Any batch processing GUI tool for QuEnc.71?

Finally got one. Named KuuEss.

Heini011

11th November 2006, 00:02

Hi,

i have a undersize problem with QuEnc 0.71 too.

my .avs script: 720x576p, 25 fps for pal dvd. 328586 frames total

the following QuEnc job should deliver 7,20 GB mpeg2 video file, but the result was only 3,94 GB and dosn't look good.

hc encoder with the same bitrate and matrix hit the target size and finished with an average quant of 3,1.

D:\DVD-Tools\codecs\QuEnc\QuEnc.exe -i v.avs -o v.m2v -b 4708 -maxbitrate 9500 -dc 9 -priority 4 -2 -hq -vbr -scene -trell -nocgop -nointerlaced -extreme -gopsize 15 -maxbframes 2 -cmatrix D:\DVD-Tools\video_enc\matrix\heini-dvd.xcm -aspectratio 16:9 -mpeg2mux dvd

PS: chapter support (keyframe times via text-file import) would be great too...

dragongodz

12th November 2006, 12:15

try turning off extreme, trellis and even hq.

but yes i know the ratecontrol still needs more work. this is a terrible time of the year to try and get anything done though. :)

MrC

20th November 2006, 13:27

Hi,

i have a undersize problem with QuEnc 0.71 too.

I have solved turning back to QuEnc 0.70, which has a better filesize control when encoding in VBR 2 pass mode.

;)

Bye
________
vaporizers (http://vaporizers.net/)

dragongodz

27th November 2006, 05:37

QuEnc 0.70, which has a better filesize control when encoding in VBR 2 pass mode.
though can throw some bad quality frames with tight max bitrate restrictions where 0.71 doesnt.

sorry i have been busy changing ISP amongst other things. will have to get back in to updating QuEnc soon. just cant say exactly when yet. :)

MrC

27th November 2006, 13:37

...[cut]...get back in to updating QuEnc soon. just cant say exactly when yet. :)

We will stay tuned!

Always :thanks:

Bye
________
Honda CBR250RR (http://www.cyclechaos.com/wiki/Honda_CBR250RR)

MrC

27th November 2006, 13:39

Another question, maybe yet asked....
DGZ, are you planning to introduce some kind of H264 encoding in future versions of QuEnc?

Bye
________
Suzuki SV1000 (http://www.cyclechaos.com/wiki/Suzuki_SV1000)

dragongodz

28th November 2006, 03:33

are you planning to introduce some kind of H264 encoding in future versions of QuEnc?
its possible. i havent made any plans to at the moment though. maybe if enough people want it i may add it to the list.

Guest

6th December 2006, 17:26

I used Quenc to encode a 24fps AVS script. The resulting MPEG2 file had a frame rate of 23.976. Why did it change the rate and how to I stop that? Thank you.

dragongodz

7th December 2006, 02:54

The resulting MPEG2 file had a frame rate of 23.976.
sorry but can not confirm. i just tested a 24fps clip and it came out 24fps mpeg aswell.

after you load the AVS in QuEnc can you press the "i" button next to the "Source AVS file" line ? that will give you the information QuEnc is getting about the clip/source from Avisynth.
if that says 24fps and still encodes to 23.976fps then can you please give details on what settings etc you are using ?

vlada

6th January 2007, 16:57

Hi, recently I tried to encode a movie in 1368x720 resolution. Unfortunately I received an undersized result (4300 kbps instead of 6000 kbps). I had the absolutely same problem with a standard DVD-Video encode (720x576@25fps) last week. I hoped the rate control will be improved in 0.71, but I'm still getting undersized movies. I have checked VBR, HQ, Trellis, 2-pass and Auto Max Bitrate.

Is there anything I could do to improve this? Thank you.

MrC

12th January 2007, 14:01

Mug Funky

15th January 2007, 08:10

hmm. i haven't had any undersize (or oversize, or max bitrate spikes) with 0.71

perhaps trellis should be turned off? the settings i tend to use are HQ, DC precision 10 bits, closed GOP (12, 2 bframes). matrix doesn't seem to matter here, and interlaced or progressive give the same results wrt ratecontrol.

i almost exclusively encode PAL.

MrC

16th January 2007, 14:30

To me 0.71 gives *always* undersizing problems with this kind of configuration:

2 pass ON
VBR ON
HQ ON
Trellis OFF
DC 10
GOP 12
B-Frame 2
Interlaced OFF
Auto Max BitRate OFF

:(

Same configuration but QuEnc 0.70, almost no undersizing problems....

;)

Bye
________
C200 (http://www.cyclechaos.com/wiki/Honda_C200)

Mug Funky

18th January 2007, 00:10

Auto Max BitRate OFF

if this is so, what number is entered for Max bitrate? 9800? 8500?

because that may have something to do with it, though i admit it's a bit of a straw-clutching effort on my part.

dragongodz

18th January 2007, 10:58

ok i have already said this previously but i will say it again.

yes QuEnc 0.71 can sometime undersize more than 0.70. HOWEVER 0.70 can also throw the occasional bad frame(very high quant) especially when max bitrate is close to target bitrate. the undersized 0.71 should look more pleasing than those bad frames to most people.

Mr_Odwin

18th January 2007, 12:47

I discovered a small thing (really small). The ac3 files generated when a bitrate of 32k is selected seem to be unplayable.

dragongodz

18th January 2007, 13:11

The ac3 files generated when a bitrate of 32k is selected seem to be unplayable.
only if 2 channels or more. 32k mono does work though it doesnt sound that great, as should be expected. really why would you want to use such a ridiculously low bitrate though ? the only time i would ever even think of using that low is if the soundtrack was purely beeps. for anything like voice or music people should use a more sensible bitrate.

MrC

18th January 2007, 13:52

if this is so, what number is entered for Max bitrate? 9800? 8500?

Usually I use 2000+Avg if Avg<5000 and 1000+Avg if Avg>5000

:)

Bye
________
FJR1300 (http://www.cyclechaos.com/wiki/Yamaha_FJR1300)

vlada

19th January 2007, 08:29

dragongodz
What is the problem with bitrate control in QuEnc? Other encoders usually don't have such problems. I had undersized movies and exceeded max bitrate with basically all QuEnc versions. Why is it so difficult to make it work properly?

Mr_Odwin

19th January 2007, 10:46

This may be a foreign language thing but your post comes over as kind of aggressive. I think if the issue was simple then dragongodz (who appears to be a proficient coder) would have it completely sorted by now, but it's clearly not trivial.
Even if it was trivial, it's free software and the author can get around to fixing it whenever he wants.
As it stands, I love QuEnc and use it pretty much every day. If I ever notice anything amiss it's because I use it so much.

dragongodz

19th January 2007, 10:48

Other encoders usually don't have such problems.
ok so i wont mention how CCE has been known to go over max bitrate. i wont mention how Mainconcept has been known to undersize. i wont mention how HC has been known to undersize etc etc etc etc etc etc etc etc etc etc etc.

Why is it so difficult to make it work properly?
any time you feel like rewriting the rate control please go right ahead. or if you would rather i will stop right now and people can go and use those "other encoders" and i will bin QuEnc instead of me obviously holding a gun to peoples heads and waisting my time.

vlada

19th January 2007, 12:47

Mr_Odwin, dragongodz
I'm very sorry if I sounded agressive, I didn't mean to. I was just interested in the issue from a technical point of view. I appreciate your hard work and I know that you're doing it for free in your spare time. Unfortunately I'm not a C/C++ programmer so I can't help with the development.

I remember that many encoders had problems with wong output size, but most of them work correct now. At least I never had any problems with 2-pass in XviD, x264 or HC.

Mug Funky

20th January 2007, 18:15

one problem with max bitrates is how they're calculated.

one example that springs readily to mind is Spruce - they made authoring software and a hardware encoder to go with it. all are specifically for making DVDs.

between maestro's bitrate viewer, it's DVD muxer and the encoder you have 3 different ideas of what a compliant max bitrate is. set the max to 8500 and you'll sometimes get spikes over 12mbps. the bitrate profiler shows the spikes, but the muxer doesn't throw any errors. sometimes the muxer will abort a compile when the profiler doesn't show any problems.

...and that's with hardware and software that were designed to work together. the same happens with Scenarist and streams produced with Sonic encoders - scenarist will reject streams made by it's own encoder.

now take something like QuEnc. scan it in BitrateView (the green one with the green quant graph and yellow bitrate graph) and a quenc 2-pass encode will show it going over the max bitrate by a lot. scan the same stream again and you'll have different numbers that follow the same curve. then you could scan the stream in Moonlight Streameye and it'll report a max bitrate well within what you set in quenc.

so which software is lying? quenc, bitrateview or streameye? the trick is that it's all open to interpretation and really it's a matter of luck as to whether there'll be playback issues or not - because every decoder or chipset or standalone player will have different ideas on how high is too high.

FWIW, 2-pass in quenc hasn't given me any problems. 1-pass has a tendency to spike in 2 particular situations, but if you lay off the custom matrices and just set the max bitrate maybe 500 kbps below what you normally would (and well above the average or you might as well go 1-pass or CBR), even these situations are no problem (for those interested - hard cuts between no-motion, bugger-all detail scenes to very complex ones, and bursts of pure white noise are the only situations i've seen that cause problems in 1-pass).

dragongodz

25th January 2007, 15:46

small update. QuEnc 0.72. see first post in this thread.

sorry but the last couple of months have been very busy. hopefully mid february should see things settling back down.

feedback welcome of course.

Fishman0919

25th January 2007, 16:38

Very Good dragongodz.... Thank You very much. I'll give it a try tonite.... got a few thing that need to be encoded.

Guest

25th January 2007, 18:09

When making an HD sized encode, QuEnc should set the high level indication in the stream. Without that, many players cannot play the resulting stream. I had to hack a tool to fix the M2V in that regard. But QuEnc should do it.

dragongodz

26th January 2007, 01:57

When making an HD sized encode, QuEnc should set the high level indication in the stream.
it appears some work on that has just begun with ffmpeg so hopefully that should be done with the next QuEnc release aswell.

Ebobtron

27th January 2007, 19:15

dragongodz,May I add my thank you to the list? I would like to add extra thanks for the additional information in the last couple of versions.

Some time ago, we were discussing AC3 encoding and the audio levels. My Recent work with the encoder suggests you really hit the mark with two channel encoding.

-3db in -3db out two channel.
The source for this test was orchestral music 4 minutes long

A six channel encode gave the following results

-3db in 0db out 6 chan.
-9db in 2.9db down a 3.1 db gain.
here I used white noise one channel at a time for channel identification. Each channel excluding the LFE was amplified some 6db +-.3

You have reached unity in the first case, which is way cool. :cool:

Fearing that a white noise test was as far from reality as one could get
An active six-channel source that is 2.7db down gave the following.

-2.7 db in -.2db down
that is more like it, the two peaks where both held off the rail.

Not at all unity but I can deal. Great work.

So now that I have buttered you up a little.

a = WAVSource("DMC_2point7db_down.wav")

l = GetChannel(a, 1)
r = GetChannel(a, 2)
c = GetChannel(a, 3)
lfe = GetChannel(a, 4)
rl = GetChannel(a, 5)
rr = GetChannel(a, 6)

MergeChannels(l, c, r, rl, rr, lfe)

My POV is very simple, AviSynth's audio output is a wav file. One needs do nothing with the stream to save it. Figure out how many bytes, write the header chunks. A wave file.
This should have the channel order l, r, c, lfe, rl, rr.

To support my argument I offer NicAc3Source which decodes to the wave file order (all hail Nic :) ).

My point:
Shouldn’t QuEnc take a six-channel wave format and output a properly ordered ac3 file?

Great work thanks again

Rob

dragongodz

28th January 2007, 03:06

My POV is very simple, AviSynth's audio output is a wav file.
but is it really ? i mean does it always output to wav order or does it simply use input(decoder) order to the same output order ? that really should be tested, especially with different decoders, to see if any do not reorder to wav format. if any do not then it leaves the same problem of having to reorder in avisynth anyway.

Shouldn’t QuEnc take a six-channel wave format and output a properly ordered ac3 file?
actually this has been suggested on the ffmpeg list several times and its flatly rejected for whatever reasons.
as i have stated previously, the less i have to change in ffmpeg source the better since anytime i want to update that means going back through and finding and redoing all the changes.
however if you can show me, or i can not find otherwise, that all decoders output to wav format then i will definatly consider making the changes.

Ebobtron

29th January 2007, 16:05

dragongodz,
Well I read your post, put my Don Quixote on and Poncho and I went out upon the internet tilting at ambiguity. Sadly, I lost my Aldonza (my passion). Quote:
My POV is very simple, AviSynth's audio output is a wav file.
but is it really ?
Yes, it is. A PCM data stream using 16 bit samples has the first 16bits as channel one and the second as channel two. If the next 16bits are channel one again we have a two channel stream, but you know this.

And considering the results of my quest, my point of view, irrelevant. Relevance requires reality.

FFMPEG doesn’t make a six channel wave from a six channel anything. The current change log did not describe a change. So like if you do not make a 5.1 wave. You can ignore that it exists.

BeSweets ac3encod.dll is based on “FFMPEG'S AC3ENC“. AC3 channel ordering required. BeSweet will decode ac3 to a properly (???) channel-ordered wave file or not if you prefer. At least they know that the 5.1 spec exists.

ac3tool not do it, proper ac3 -> ac3tool -> incorrectly ordered PCM stream

headac3he not either proper ac3 -> headac3he -> incorrectly ordered PCM stream

Aften do it correctly, 5.1 Wave -> aften -> decoder -> correctly ordered PCM stream
5.1 wave in 5.1 ac3 out, cool.

As for the rest. Sorry, the data does not support a conclusion at this time.

the first six channels has been well described

Multiple Channel Audio Data and WAVE Files
Updated: December 4, 2001 (http://www.microsoft.com/whdc/device/audio/multichaud.mspx)
Not exactly new information.

actually this has been suggested on the ffmpeg list several times and its flatly rejected for whatever reasons.
There it is.

You could reorder the stream and leave the ffmpeg code alone, would be a bit slow. But why should you be the only one? I can not ask this of you.

"I am one of many. I choose to be different, very different." me

Horse ran away……… Poncho left too………

I think I will take my sword and go home….

Nothing left to do but sing the damn song…. :o

Thanks :)

Espio

30th January 2007, 07:48

I just encoded two videos of exactly 24 minutes in length and got 271Mb for the first and 342Mb for the second. The audio and muxing are done outside of QuEnc, but I don't think they would give such varied results. Also, the audio is CBR at 128kbps. And the source resolutions are the same, and the sizes, etc.

Settings are:
MPEG-2
avg bitrate - 1800kbps
max bitrate - 8000kbps
use VBR - on
HQ - on
Trellis - off
2 pass - on

Just did another video of same length, etc and got 236Mb.

Ebobtron

30th January 2007, 09:24

Why would you expect them to be the same? With vbr on the bitrate will vary. Different pictures require different encoding different motion requires different encoding. :)

Fishman0919

30th January 2007, 13:01

@ Ebobtron
24 min of video is about 34,525 frames.... it wouldn't matter if you were encoding clip A, clip B or clip C.... if you tell the encoder to encoded 34,525 frames @1800k you should get a video file about 323mb... A+B=C...it's math (formula shown is not intended for real uses) ;-)

Settings are:
MPEG-2
avg bitrate - 1800kbps
max bitrate - 8000kbps
use VBR - on
HQ - on
Trellis - off
2 pass - on

VBR is the type of encoding,but MPEG2 uses ABR (average bit rate), meaning using VBR make the ABR of the encoding @1800k

Edit: Sorry, unless you were doing a 1-pass VBR... then clip differences would matter.

@Espio

Are you comparing sizes before or after you are muxing the audio

Ebobtron

30th January 2007, 18:23

@ Fishman0919Well,
I was being a bit of a butt. :) Sorry. :o

I guess Espio wants us to assume what other settings he may be using. He needs to provide dragongodz with more info.

With the settings he provided I can't make the filesize vary more than about 2 percent between high motion and low. Is he NTSC or PAL? Is he ... ??

Fishman0919

30th January 2007, 18:58

With the settings he provided I can't make the filesize vary more than about 2 percent between high motion and low. Is he NTSC or PAL? Is he ... ??

NTSC or PAL wouldn't matter, you will get diff size between ntsc and pal but from clip to clip you will get the same size.

24 min of video is 24 min of video, NTSC or PAL, 3 diff encodings in PAL of 24 min should be about the same size, footage won't change the fact, and the same for NTSC

Sorry, I'm not trying to come across harsh and if I am... I am sorry, but 24 min at 1800k = same result

I did 4 encodings of 24 min @1800k, 2 with HC and 2 with CCE (1 Basic and 1 SP2), all came out to be right around 323mb.

No encoder is going to be right on target but the vary he is getting is a bit much

Ebobtron

30th January 2007, 19:45

Those things may matter to the program. If the program has an error it may only occur when using certain setting.

Affar

30th January 2007, 20:11

dragongodz

30th January 2007, 20:28

put my Don Quixote on and Poncho and I went out upon the internet tilting at ambiguity.
sorry Ebobtron you lost me a bit with this post. i must have been transfixed by the windmills. ;)

24 min of video is 24 min of video, NTSC or PAL, 3 diff encodings in PAL of 24 min should be about the same size, footage won't change the fact
actually it can. are all 3 clips the same type of footage(action, still, grainy, smooth - meaning compressability) ? whats the resolution ? whats the average quant results ? so little information to go from that post.
oh and QuEnc doesnt pad of course. :)

No encoder is going to be right on target but the vary he is getting is a bit much
to which i would need much more information to know why there is such a variance.

Fishman0919

30th January 2007, 21:20

Sorry, and I am assuming that the res is the same for all the clips being encoded.

Espio

2nd February 2007, 22:10

Okay, the video is all one type (anime, and of the same series), the sizes are after the audio is muxed, but the audio is at 128kbps CBR, so that shouldn't matter. The resolution in each video is 768x432, GSpot shows the codec as DivX4 (OpenDivX) average bitrate as 655kbps. I don't know how to find the average quant results so if you tell me how, I'll get you those.

I know QuEnc doesn't pad, which is good, I'm just wondering if that's the reason for the size differences. The audio encoding program is BeSweet v1.5b31. Hope this helps.

dragongodz

3rd February 2007, 04:57

anime, and of the same series
can you say which series and which 3 episodes ? i am a big anime fan aswell so if its something i have i can test specifically against that. ok mine would be PAL but its something to start with anyway.

768x432, GSpot shows the codec as DivX4 (OpenDivX) average bitrate as 655kbps
oh dear. why do i have a nasty feeling that doesnt look real good(smoothed, lost all fine detail etc) ? that is nowhere near high enough bitrate for that resolution, atleast for standard anime.

I don't know how to find the average quant results so if you tell me how, I'll get you those.
there is bitrateviewer(can be a bit dodgy with what it reports i find) and elecard streameye. either of those should be able to give you the average quant of the encoded mpeg. that is the part to find out.

Ebobtron

3rd February 2007, 11:02

@dragongodz,To understand you must take up the quest (helps if you’re a little senile).

I had asked you to reorder the six channel ordering of QuEnc’s ac3 encoder. Your reply suggested a number of issues, and your remark about a more convincing argument sent me galloping off upon my high horse in search of that.

Background:My personal needs for artificial surround channels is not, and I never work with real ones personally for my projects. It should be no surprise to anyone that I know little about ac3 encoders.

My work with avsFilmCutter prompted the sudden interest when I discovered that writing wave files from AviSynth sources was child’s play as long as you maneuver around the 64-bit math landmines.

When you offered “72” I remembered the audio issues and I wondered how that had or had not progressed. My ability to measure the progress has also improved greatly and when I looked over the two channel data I was very pleased. Having the ability to create clean six channel wave files that I can measure, I tested the six or 5.1 channel gain/loss of QuEnc’s ac3.

This is how I was reminded of the channel order issue which I didn’t fully understand (still don‘t think I do, do not really care either). I did along the way find that the dragon (not you) has ruled for sometime with no attempt to lop off his or her fetid head.

In besweet and ffmpeg and QuEnc, this is a ffmpeg problem.

You said they are disinterested in changing it.I can ask you to take up the sword with me, I believe that would be fruitless for one and confusing for the current users. Or I can do the more informed thing and not.

“getchannel.htm” remark 1, from the AviSynth documentation, to me has a problem.I, me the user, should not have to care about the channel order of the ac3 file or dts file. That is the job of the encoder/decoder.

I do not want to appear ungrateful for the ability to reorder the channels from within the script. I just do not think there is a good reason that I should have to other than I apparently have to.

Of course, all this is my humble opinion. The dragon will die someday or it might live on forever, we still buy software and operating systems from the guys who gave us 640K of continuous RAM and paged the rest.

Well don’t we. :o

Oh and just off hand which dumb butt made the final decision on wave files railing at 0 db. If your reading this, did you ever hear of the term headroom? Can you actually read?
:) Thanks for the interest and your good work.

dragongodz

3rd February 2007, 13:25

You said they are disinterested in changing it.
actually what i said was i am reluctant to make the change as it means having to make it every time i update ffmpeg/libavcodec source.

also
“getchannel.htm” remark 1, from the AviSynth documentation
as you mention shows how different audio formats have different channel orders. and add in the part mentioned at the top of that page
The ordening of the channels is determined by the ordening of the input file, because AviSynth doesn't assume any ordening.
this means its up to the decoder what order avisynth gets the channels in, and thus outputs them. that is does it present them in the order of the format or does it output them in wav order ? if it doesnt re-order to wav order then avisynth doesnt output it as wav order. so you would have to re-order them with avisynth(via script) anyway if wav order is what you or the encoder wanted.

start to see the dilemma ? i do not know which decoders present any of the different audio formats in which order. so if i assume it will always be wav order that could also open up a trap for any that do not.

so i may change it to assume wav order eventually but i would want to test, or be shown tests, of different decoders first to see how they handle it. even just taking AC3 as an example there is multiple decoders(including directshow usage etc).

Ebobtron

3rd February 2007, 20:13

so i may change it to assume wav order eventually but i would want to test, or be shown tests, of different decoders first to see how they handle it. even just taking AC3 as an example there is multiple decoders(including directshow usage etc).That was my first campaign, it was a total loss. There is no consistent data for you to review.actually this has been suggested on the ffmpeg list several times and its flatly rejected for whatever reasons.This "dragon head" is more important to me because if they don't change why should you be any different. QuEnc suddenly being different, would add to the ambiguity. And I don't believe the return for that much additional work is worth it.I, at first, thought the issue much simpler than it appears to be. With what I understand today, I find my request without merit. Therefore I withdraw said request and beg my leave of you, my lord. :) I shall have to find another windmill.

Thanks

Ebobtron

5th February 2007, 05:28

@dgodzDid you see this.http://slideitondvd.com/Supporters.html
Very strange and off putting.

The gentleman who runs this site, addressed the issue.

Espio

5th February 2007, 07:32

Well, it's a TVrip fansub, so the quality isn't all that important, but it looks pretty good for the bitrate and resolution. Anyway, the series is Mushi-shi, subbed by ANBU, episodes 1-3.

I'm assuming the numbers you want are the peak and average Q levels (from Bitrate Viewer), so here they are:

Episode 1: Peak:2.27
Average:2.00

Episode 2: Peak:2.07
Average:1.10

Episode 3: Peak:4.20 (spiked at beginning for some reason)
Average:1.99

Boulder

5th February 2007, 07:39

Those values look like there's encoder saturation - the video is probably so smoothed that there's not much detail left. Try a quant matrix that is meant for high bitrates (such as Fox Home Entertainment) and see if the problem still occurs.

Espio

6th February 2007, 03:26

Sorry to sound dumb, but I don't know how to use quant matrices or where to get them, unless QuEnc has them built-in.

Mug Funky

6th February 2007, 12:10

quenc takes the same matrix format xvid takes. you can load them in if you go to advanced settings.

you can get by with just standard and qlb (for low bitrates) though. of course, if you're getting saturation you should put in something like didee's 6of9 HVS or similar.

[edit]

as for obtaining these matrices,:search:

dragongodz

11th February 2007, 06:09

Episode 1: Peak:2.27
Average:2.00

Episode 2: Peak:2.07
Average:1.10

Episode 3: Peak:4.20 (spiked at beginning for some reason)
Average:1.99
yep thats looking pretty close to saturation. B-frames are a little biased towards up than down so you would probably find they are the greatest area for taking the average above 1. really though they are rather motion dependant so thats not hurting them as much. in other words better to have Q1 I and P etc.

tamahome

19th February 2007, 01:06

personally since the versions 0.7x quenc is unusable, I encode under diko, everything works well with version 0.61, but with the versions 0.7x quenc launches out and cuts themselves 2-3 minutes after without reason: /

Mug Funky

19th February 2007, 12:25

get rid of the -mpeg2 switch, probably.

i've had no problem on the 20 odd computers i've run it on :)

tamahome

19th February 2007, 12:46

get rid of the -mpeg2 switch, probably.

i've had no problem on the 20 odd computers i've run it on :)

No, commandline is correct (quenc would not start with encoder)
i use -mpeg2MUX
Little video of problem
http://dl.free.fr/GuFJqwmT/problem.avi

commandline use -b 1683 -maxbitrate 8000 -dc 8 -priority 2 -2 -nohq -vbr -scene -notrell -nocgop -nointerlaced -noextreme -gopsize 15 -maxbframes 2 -qlb -aspectratio 4:3 -mpeg2MUX -scene -auto -close

tamahome

20th February 2007, 01:21

it would seem that quenc bug with the sources h.264/avc, the problem would come from,
because with the divx/xvid source or dvd he goes well.

as an information I have haali splitter and coreavc to read the mkv/avc (I have to also test with ffdshow same result quenc plant)

Mr_Odwin

20th February 2007, 10:24

Is this more of an Avisynth problem than a QuEnc problem then?

tamahome

20th February 2007, 10:58

I do not think because the same file with hcencoder /CCE passes perfectly

Mug Funky

20th February 2007, 12:29

my bet is on directshow as the problem, but it is strange that it's working in CCE and HC, and older versions.

have you played with setmemorymax, or setlegacyplanaralignment in avisynth? i'm clutching at straws here :)

dragongodz

20th February 2007, 13:15

-mpeg2MUX -scene
mpeg2mux actually requires a value after it, ie. vob. without it it will just use default(vob) anyway.

it would seem that quenc bug with the sources h.264/avc, the problem would come from,
because with the divx/xvid source or dvd he goes well.
can you provide a smallish sample that reproduces the problem so i can test against ?

also what is the exact avisynth script you use ?

shirohamada

24th February 2007, 21:39

is it just me, or quenc don't use any quant 3 and 5, or odd numbers?

hank315

24th February 2007, 22:41

is it just me, or quenc don't use any quant 3 and 5, or odd numbers?No it doesn't, QuEnc uses a linear quantization scale, values 2,4,6,8,10,12 .... 62.

dragongodz

25th February 2007, 01:47

is it just me, or quenc don't use any quant 3 and 5, or odd numbers?
depends. what are you looking at the stream with ?

for example if you look with elecard streameye you can see quant 3 etc frames. however if what you are using just shows quantifier scale then no you wont see quant 3 etc.

tamahome - still waiting on something i can test with. please PM me with more information if nothing else.

shirohamada

8th March 2007, 20:48

too lazy to look for other tools. so i just feed it through ffdshow and turn on osd -_-

MrC

29th October 2007, 13:59

@Nic,DGZ

Any chance to see an update to your wonderful creature? Should we consider the project stopped?

:confused::)

Bye

dragongodz

30th October 2007, 04:29

Any chance to see an update to your wonderful creature?

yes. i had actually planned to have a new version out long before now. unfortunatly real life kept getting in the way. for example in the last week 2 major things have happened, neither good, which means finalising things i was testing in QuEnc is not even in my mind at the moment.

tom942

1st November 2007, 00:52

dragongodz, any advice to avoid blocks in fast action or motion scenes or some of the improvements that you are working on goes this way?.

BTW, thank you for your nice app and hope that your problems go away soon :).

Regards.

dragongodz

1st November 2007, 06:12

any advice to avoid blocks in fast action or motion scenes or some of the improvements that you are working on goes this way?.

using a lower bitrate matrix may help reduce them.

and hope that your problems go away soon

one is nearly sorted out and the other(the death of my mother) will take a little time(funeral arrangements etc).

Boulder

1st November 2007, 07:49

one is nearly sorted out and the other(the death of my mother) will take a little time(funeral arrangements etc).I'm sorry to hear this :( My condolences to you and your family.

MrC

1st November 2007, 14:10

Condolence to you from me too.

Bye

tom942

1st November 2007, 15:06

As Boulder said, I'm so sorry and my condolences to your family and you :(.

dragongodz

2nd November 2007, 21:10

thanks guys.

tom942

3rd November 2007, 00:50

@dragongodz

I have used lower matrices, such as yours QLB or AVAMAT6 & 7, but the blocks are still there.

The truth is, that I can see them just when I play the video frame by frame, not in normal playback.

That's the reason that I asked you if you were tweaking something related with that, but I hope that you "play" with it when you feel better :).

Regards.

Ebobtron

25th December 2007, 07:55

Doing some quick last minute encodes and I suddenly noticed that QuEnc 72 doesn't like avisynth to feed it 24 or 32 bit sound. Result is a rail to rail hiss. 16 bit works just fine. Oddly though I don’t ever remember feeding it anything other than 16 bit sound.

Just needed an excuse to say merry, merry and happy, happy and sorry about your mom.

dragongodz

31st December 2007, 11:22

ok for those interested and feeling a little adventurous i present a little xmas and new years present .... QuEnc 0.75 alpha.

http://w14.easy-share.com/13664921.html

WARNING!!!!! its alpha for a reason. it is not intended for permanant use or to be added to other software collections etc. it is purely for those interested in doing a little testing etc.

changes to test

trellis does not enable trellis, instead enable 2 threads. disabling trellis turns back to 1 thread. this is done this way so you can test it using other programs that have the trellis option when calling QuEnc.

slight possible quality change to normal and hiq modes. hiq you may not see much or even anything. hopefully normal should gain a little though.
if you compare against QuEnc 0.72 with psnr and/or ssim then please compare with your eyes aswell. also please compare the speed, with trellis disabled(so 1 thread) for 0.75alpha.

these are the only 2 major things i left in this release for people to play with.

Ebobtron - i will look at that later. thanks.

Fishman0919

31st December 2007, 11:49

Thank You dragongodz

MrC

31st December 2007, 14:29

Thanks a lot DGZ, I will try it ASAP and I'm looking forward for a stable release to add to AVStoDVD.

A (maybe) stupid question: why 0.75 and not 0.73?

:) :cool:

Bye

dragongodz

31st December 2007, 15:45

A (maybe) stupid question: why 0.75 and not 0.73?

no not a silly question.

basically there have been other alpha/test versions. they were only given to a few people however to test specific changes. so they were numbered differently for my own record of them.

so if i had not released this here the next stable would be either 0.73 if only a few changes were included or possibly 0.80 if it contained many, many changes or something i felt was major enough.

however i felt being the time of year it is it may make a nice little present and also get a bit broader feedback. :)

Fishman0919

31st December 2007, 16:07

Quality seems about the same as .72 with HQ on.... maybe a bit better in high motion scenes. Norm is better for me on same scene.

Speed is slower then .72... same movie .72 avg about 38.5 fps where .75a avg 31 fps

Edit: I just did a 1 min clip from Transformers HD down converting it to SD DVD. It's the opening scene at the military airport... dark and high motion.
The clip is at 3600k with HQ on. To me .75a looks better then .72

manolito

31st December 2007, 23:52

Thanks DGZ for the new build,

just did a short torture test in 1-pass VBR mode, normal quality, AVG bitrate 8500, Max bitrate 9000. I am mainly interested in getting DVD compliant output (if Muxman has no complaints then I assume it is compliant).

With V. 0.72 Muxman reported a max bitrate of 10888, with 0.75 it was 11434. Still Muxman did mux and author it without errors, and of course it did play in my SA without any stutter.

Happy New Year!

Cheers
manolito

dragongodz

1st January 2008, 00:22

.72 avg about 38.5 fps where .75a avg 31 fps

is that normal or hq ? yes i knew there would be a speed hit. quality increases usually come at some sort of cost. hopefully threading should help when not using a program that does multiple encoding processes(meaning splitting the encode and running several instances of QuEnc at once).

1-pass VBR mode

having a quick look there is still a couple of changes that i didnt revert back for this so they may be the cause of the max bitrate increase and not the other changes.

Fishman0919

1st January 2008, 08:34

is that normal or hq ?

HQ mode... the speed loss is not bad for the quality gained.
A few more scene I did with a lot of high motion look better then .72... little... but better.

The couple of clips I did with norm mode look quite better then .72 norm and maybe close to .72 HQ mode

I'm away from home now and using a single core AMD Sempron 3400+ laptop so "trellis" 2 threads is not an option right now.

smok3

1st January 2008, 10:36

dragongodz

2nd January 2008, 01:00

I'm away from home now and using a single core AMD Sempron 3400+ laptop so "trellis" 2 threads is not an option right now.

thats cool. the other feedback/tests is helpful.

similar problem with 1-pass vbr

now repeat after me. ALPHA, AAAAAALPHA. ;)
i did mention why 1 pass may be like that. i may do another alpha with that fixed and maybe a different quality increase(too see get an opinion by others which would be more desirable) on the weekend.

smok3

2nd January 2008, 01:07

actually i was referring to 0.72.

dragongodz

3rd January 2008, 03:44

actually i was referring to 0.72.

ahh you should have been a bit more concise in what you meant. :)

hmm ok 17 downloads and only feedback from a few people. why doesnt that surprise me anymore ? :sly:

Fishman0919

3rd January 2008, 11:59

May a new thread with a "QuEnc .75 Alpha" title... I just happened to see you had posted something in this thread and wanted see what you had wrote. Some people might not be so concerned with .72 and without a new thread title, may not look in.

dragongodz

3rd January 2008, 13:24

well i never expected or wanted mass downloads etc. however i did hope, against expectations, that of those who did spot it and downloaded then hopefully at least half would make some comment.

jeffy

3rd January 2008, 14:21

well i never expected or wanted mass downloads etc. however i did hope, against expectations, that of those who did spot it and downloaded then hopefully at least half would make some comment.
Happy New Year and all the best! It might be good to add the feedback wanted note to the post with the latest link, eg. please post your comments, wishes etc. here.
It might be disappointing for the programmer, but rest assured, some people really appreciate the effort, although they remain quiet.

smok3

3rd January 2008, 14:33

ahh you should have been a bit more concise in what you meant. :)

with this setting iam getting non-compatible dvd output (0.72):
[HKEY_LOCAL_MACHINE\SOFTWARE\QuEnc]
"crBkgColor"=dword:00aaaaaa
"crLtBkgColor"=dword:00bbbbbb
"crVLtBkgColor"=dword:00cccccc
"m_crForeColor"=dword:00000000
"m_nGopSize"=dword:0000000c
"m_nBFrames"=dword:00000002
"m_nBitrate"=dword:0000125c
"m_nCodec"=dword:00000001
"m_bUseHQ"=dword:00000000
"m_bUse2Pass"=dword:00000000
"m_bUseTrellis"=dword:00000000
"m_bUseVBR"=dword:00000001
"m_bUseClosedGOP"=dword:00000000
"m_bQLB"=dword:00000000
"m_bExtremeSettings"=dword:00000000
"m_bInterlaceEnc"=dword:00000000
"m_bSceneDetect"=dword:00000000
"m_bAutoMaxBitrate"=dword:00000000
"m_nMaxBitrate"=dword:00001d4c
"m_nDCPrecision"=dword:00000000
"m_nThreadPriority"=dword:00000020
"m_nAudioBitrate"=dword:00000007
"m_nAudioCodec"=dword:00000000
"AspectRatio"=dword:00000001
"m_bTopFieldFirst"=dword:00000000
"m_bPulldown"=dword:00000000
"m_csCustomMatrixFile"=""
"m_csMuxProfile"="DVD"
"m_nMPEGSel"=dword:00000001
"m_bKVCDNotch"=dword:00000000
that's what i meant :)

p.s. do 'we' really need to use registry for storing setting btw?

dragongodz

3rd January 2008, 15:30

It might be good to add the feedback wanted note to the post

however the simple fact it is an alpha and has a big warning plus mentions whats worth testing should be a pretty clear sign to only download if a person actually plans to test it. if thats a given then it shouldnt be unreasonable to expect/hope that some will then report their finding from their testing.
as i said i have been around too long to expect everyone that downloads it to report anything but it is a little dissapointing that Fishman0919 seems to be the only one willing to go that extra step to test and report on the things mentioned ... and he is not even at home. :eek:

EDIT: no doubt some have been busy and may report later aswell of course.

that's what i meant

out of curiosity did you try anything else besides adobe encore(muxman, tmpgenc dvd author etc) ?

do 'we' really need to use registry for storing setting btw?

is there a good reason not to ?

Fishman0919

3rd January 2008, 17:11

I've done 14 diff clips... ranging from 1 to 5 min's
With every clip .75a looked better then .72

Here is the order I would rank them...

4) QuEnc .72 Norm
3) QuEnc .75a Norm (very close to .72 HQ)
2) QuEnc .72 HQ
1) QuEnc .75a HQ

QuEnc .72 was faster in all clips in both mode but like I said before... the loss is not bad for the quality gained

Sorry I don't have encoding times but busy with real world work stuff and limited with my resources here

Edit: Side note... not sure if it's something you changed or maybe just the movies I encoded but .75a seems to size better then .72

smok3

3rd January 2008, 17:48

out of curiosity did you try anything else besides adobe encore(muxman, tmpgenc dvd author etc) ?
is there a good reason to ?

Fishman0919

3rd January 2008, 17:56

I've had issues with the muxing process of Adobe Encore...where Muxman didn't fail or get a problem.

Just my 2 cents.

Fishman0919

3rd January 2008, 19:07

@dragongodz,

I just finished encoder an HD-DVD clip to SD-DVD and got an debugging error at the end of the 2nd pass that pop-up Microsoft Visual Studio 2008.

I closed it by mistake before I could grab a screenshot. I will run it again later

Tdr

4th January 2008, 12:04

@dragongodz and all,

is there a special Thread, Forum or Helpfile, where a Newbie to Quenc can post some - possible - stupid Questions?

@dragongodz

I`ve tested - as far as I can see - all freeware encoders with libavcodec and I ended allways by your Quenc. Audio inside!, great Work!!!

Is there a list, where I can add some whishes for further versions? (just kidding)

Thanks
Tom

Ps: last used my english about ten years ago, so please ...

dragongodz

4th January 2008, 12:26

got an debugging error at the end of the 2nd pass that pop-up Microsoft Visual Studio 2008.

did the encode actually work or bad file at the end ?

i did install the vs 2008 trial and played with it for a couple of day. wasnt impressed so i removed it except the .net crap.

.net compact framework 2.0 sp2 - 97mb
.net compact framework 3.5 - 86mb
.net framework 2.0 sp1 - 195mb
.net framework 3.0 sp1 - 250mb
.net framework 3.5 - 29mb

man i could save some room removing all that crap. :)

hmm i see i still have crystal reports 2008 installed (188mb). bloody loits of crap vs 2008 installs and you have to uninstall it all separately. hows that for a pain ?

so avcodec was compiled with mingw/gcc and QuEnc compiled with vs 6 with intel compiler. vs 2008 should have had nothing to do with it.

dragongodz

4th January 2008, 12:30

is there a special Thread, Forum or Helpfile, where a Newbie to Quenc can post some - possible - stupid Questions?

right here. :)

if i dont answer others may.

Ps: last used my english about ten years ago, so please ...

no worries. if i dont understand what you mean i will say so and if i misunderstand then i will just ask you to be more precise in what you mean.

Fishman0919

4th January 2008, 13:47

did the encode actually work or bad file at the end ?

so avcodec was compiled with mingw/gcc and QuEnc compiled with vs 6 with intel compiler. vs 2008 should have had nothing to do with it.

Seemed to work fine.
On my laptop vs 2008 pops-up for debugging when a program errors. It made a QuEnc.slh and QuEnc.suo file for debugging. But since I don't have the source... the files are better much empty

ricardo.santos

4th January 2008, 13:48

Source:
Video: 5 minutes VOB = 6200 bitrate
Audio: 6 ChannelAC3 = 448k

Avisinth script: (Thanks MrC)
Video = DirectShowSource("C:\TESTE\VIDEO_TS\VTS_01_1.VOB", convertfps=true, audio=false)
Audio = GetChannel(DirectShowSource("C:\TESTE\VIDEO_TS\VTS_01_1.VOB", video=false), 1, 3, 2, 5, 6, 4).Normalize()
AudioDub(Video, Audio)
ConvertToYV12

====================================================

TEST SETTINGS:
VIDEO BITRATE: 3500
AUDIO BITRATE: 192 AC3

Quenc 0.72 (2 pass, variable bitrate)
Conversion time= 7.50
Final size= 138 megs

Quenc 0.72 (2 pass, High Quality mode, variable bitrate)
Conversion time= 11.15
Final size= 138 megs

Quenc 0.75 (2 pass, variable bitrate)
Conversion time= 12.20
Final size= 138 megs

Quenc 0.75 (2 pass, High Quality mode, variable bitrate)
Conversion time= 16
Final size= 138 megs

I couldnt see any difference between the four videos, not even when watching the videos really close to tv. ill try a lower bitrate later today, any ideas for a bitrate value i should try?

Tdr

4th January 2008, 14:36

@dragongodz,

Thanks for the offer, for first I have 2 Questions:

1.
I have an XVID-Action-Movie and have cut out a sequence of 5 Minutes with VirtualDubMod (Direct-Stream Copy) for testing; I searched for an extrem scene with very fast Cars.

I want to understand the function bitrate (kpbs) and max bitrate (advanced Options), how they effect each another.

In the setting you can find :"QuEnc does not limit it to that maximum though so you are better off setting
it manually for things like DVD or SVCD etc.".

So, for example, I used 2600 in max bitrate (advanced Options), to produce a SVCD.

When the Bitrate (not under Advanced Options) is then set for example to 2500, is this 2500 the max or the average (I can get for example out of Fitcd, I use it for resizing to 480 x 576) bitrate?

When its average, then a setting 2600 in Bitrate and 2600 in the max bitrate would be stupid .

2.
I have tested serveral encoded Films with various Bitrates (1 pass, VBR) and my short clip.

When I use Bitrate Viewer, there is a problem, that I cant understand.

When I encode a complete Film, the Bitrate, used under Advanced Options, is as max Bitrate ok. There are some small peaks (4-5 in 90 minutes) over, but just for 200-300 kpbs. Therefore I can live with.

When I encode my short Action Clip, Bitrate Viewer shows the first 4-5 seconds extrem peaks, over 6000 kpbs, although max bitrate is set for example (for SVCD) to 2600. After 10 seconds the peaks are ok, same as complete film.

On my Standalone I recognised this problem several times, the picture jumps. Its allways the same, when a movie starts very fast with action scenes.

Is this a problem, used by my settings, a bug, or is it the general problem, that libavcodec should have with the ratecontroll.

Or is it a Problem of 1-pass?

Hope somebody can understand the questions.

Thanks a lot
Tom

PS: @dragongodz, would it be much work, to code a shutdown in the Gui? I often encode overnigth.

Fishman0919

4th January 2008, 18:17

I had stated before that QuEnc .75a seems to be sizing better .72 and the encodings I was doing were between 2500k and 3000k.

I just did a few higher bitrates... 4000k-5000k and .75a seems to be running into encoder saturation more so then .72

I ran these test but I tried encoding the Simpsons R1 NTSC with DVD-RB using CCE Smooth Matrix and QuEnc .75a. It undersized a bit 4.02 GB (4,323,149,824 bytes)

I'm running the same movie again thru DVD-RB with .72 now...

Edit: QuEnc .72 = 4.18 GB (4,499,406,848 bytes)

dragongodz

5th January 2008, 03:42

any ideas for a bitrate value i should try?

depends on the source. the more complex(action etc) the more bitrate is usually required.

is then set for example to 2500, is this 2500 the max or the average

the bitrate in the main window is target/average bitrate. the one in advanced is maximum bitrate.

Or is it a Problem of 1-pass?

i would always reccomend 2 pass for tighter constraints such as svcd or for lower bitrate encodes. 1 pass encoding is generally fine for higher bitrate encodes but even then 2 pass will probably look better 99.999% of the time.

to code a shutdown in the Gui?

i may add that later. depends on time and if i think about it. :)

the same movie again thru DVD-RB with .72 now

how did they look in comparison ? was 0.72 better/the same/worse with the higher bitrate ?

Fishman0919

5th January 2008, 12:02

how did they look in comparison ? was 0.72 better/the same/worse with the higher bitrate ?

Very hard to tell... being that it's Anime/CGI... I may want to say .75a is better but after looking at several scenes several times... I'd have to say the same. Being that it's smaller (only a bit smaller) and looks the same is not bad :)

MrC

5th January 2008, 16:37

Avisinth script: (Thanks MrC)
Video = DirectShowSource("C:\TESTE\VIDEO_TS\VTS_01_1.VOB", convertfps=true, audio=false)
Audio = GetChannel(DirectShowSource("C:\TESTE\VIDEO_TS\VTS_01_1.VOB", video=false), 1, 3, 2, 5, 6, 4).Normalize()
AudioDub(Video, Audio)
ConvertToYV12

Glad you are using AVStoDVD even as AVS script generator :cool: :)

@DGZ

I could do some CBR tests with 0.75a (single thread). Right now I will report only "numbers", then I will add some visual comments.

Source file info
Video (simple anime):
AVI (DivX 5) - 951 kbps - 520x384 - 4:3 - 25 fps - PPF - 20:38 minutes - 30966 frames
Audio:
AVI (MPEG-1 Audio layer 3) - 113 kbps - CBR - 44100Hz - 2ch - 20:38 minutes

AVS script
Video = DirectShowSource("clip.avi", convertfps=true, audio=false)
Audio = DirectShowSource("clip.avi", video=false).Normalize()
AudioDub(Video, Audio)
ConvertToYV12
AddBorders(0,3,0,3)
Lanczos4Resize(720,576)
SSRC(48000)

QuEnc CLI
CBR high quality encoding:
-i "clip.avs" -o "clip.m2v" -b 4565 -maxbitrate 4565 -1 -hq -novbr -scene -aspectratio 4:3 -nointerlaced -mpeg2mux noaudio -dc 9 -priority 1 -auto -closeCBR standard quality encoding:
-i "clip.avs" -o "clip.m2v" -b 4565 -maxbitrate 4565 -1 -nohq -novbr -noscene -aspectratio 4:3 -nointerlaced -mpeg2mux noaudio -dc 9 -priority 1 -auto -close

CBR high quality Results
FPS
0.72: 39.4
0.75a: 28.7 (-27%)
Output Filesize
0.72: 706'831'463 Byte
0.75a: 706'741'606 Byte

CBR std quality Results
FPS
0.72: 54.7
0.75a: 36.4 (-33%)
Output Filesize
0.72: 706'846'093 Byte
0.75a: 706'741'606 Byte

Speed is surely impacted by 0.75a. I did not expected so much. I am doing some VBR testing using -trell option. Stay tuned.

:)

Bye

MrC

5th January 2008, 16:54

VBR 2-pass encoding Results
FPS
0.72: 18.6
0.75a (-notrell): 14.2 (-24%)
0.75a (-trell): 20 (+8%)
HCenc 0.22: 30
Output Filesize:
0.72: 706'831'463 Byte
0.75a (-no trell): 617'670'790 Byte
0.75a (-trell): 620'311'886 Byte
HCenc 0.22: 706'849'996 Byte

When going VBR, more undersizing than 0.72... and using 2 threads only +8% speed increase...

:)

Bye

manolito

5th January 2008, 18:24

I couldnt see any difference between the four videos, not even when watching the videos really close to tv.

Same here, so far I have not been able to detect a visual quality difference between 0.72 and 0.75 alpha. But of course this might be due to my specific encoding needs:

1. My sources are usually captured TV movies, either analog or DVB-T. In both cases the source quality is significantly lower than DVD.

2. Average bitrate is never below 4500 kbps, mostly it is higher than 5000 kbps.

3. I watch my movies on a 28" CRT TV. Effective horizontal resolution is probably below 400 lines, and a little blockiness is mostly not even noticeable.

So I would like to lobby for retaining the 0.72 normal mode, maybe as an additional "fast" mode.

Cheers
manolito

hank315

6th January 2008, 20:34

Another test with QuEnc 0.72 vs Quenc 0.75.
CPU: Intel E6600 running XP, SP2

progressive source, 1800 kb
|------------------|---------|---------|---------|
| Encoder | OPSNR | SSIM 2 | Speed |
|------------------|---------|---------|---------|
| QuEnc72 noHQ | 46.78 | 82.20 | 80 sec |
| QuEnc75(1) noHQ | 46.88 | 82.70 | 110 sec |
| QuEnc75(2) noHQ | 46.81 | 82.46 | 75 sec |
|------------------|---------|---------|---------|
| QuEnc72 HQ | 46.57 | 81.55 | 105 sec |
| QuEnc75(1) HQ | 46.61 | 81.80 | 140 sec |
| QuEnc75(2) HQ | 46.55 | 81.64 | 90 sec |
|------------------|---------|---------|---------|
The source has black top/bottom bars so the noHQ encode could skip MBs in B-frames which explains the higher metrics.

interlaced DV source, 7000 kb
|------------------|---------|---------|---------|
| Encoder | OPSNR | SSIM 2 | Speed |
|------------------|---------|---------|---------|
| QuEnc72 noHQ | 40.35 | 79.91 | 104 sec |
| QuEnc75(1) noHQ | 40.46 | 80.41 | 208 sec |
| QuEnc75(2) noHQ | 40.40 | 80.21 | 110 sec |
|------------------|---------|---------|---------|
| QuEnc72 HQ | 40.52 | 80.46 | 174 sec |
| QuEnc75(1) HQ | 40.57 | 80.76 | 280 sec |
| QuEnc75(2) HQ | 40.53 | 80.53 | 150 sec |
|------------------|---------|---------|---------|

The multi-threading works OK as can be seen in the last encode, the first encode had some Avisynth filtering/resizing which isn't multi-threaded.
The bitrate control does a better job in 0.75, better distribution of quantizers, it also looked (marginally) better.
The sizing of the noHQ encodes was very good, all HQ encodes were a bit undersized varying from 1 - 10%.

IMHO 0.75 is better than 0.72 but the visual improvement is small, if the multi-threading could be applied to 0.72 also that would be *very* nice.

ricardo.santos

6th January 2008, 23:28

I couldnt see any difference between the four videos, not even when watching the videos really close to tv. ill try a lower bitrate...

Same here, so far I have not been able to detect a visual quality difference between 0.72 and 0.75 alpha.

using the same script i used before at 2500k video and audio at 192 i couldnt see any difference between 0.72 and 0.75. On my 16" CRT they looked the same, perhaps on bigger screens the difference is noticeble.

final size was the same for all 4 encodes.

Thanks for the new version

dragongodz

7th January 2008, 11:35

ok here is 0.75alpha - 2

http://www.icefile.net/index.php?page=main&id=40e191346&name=QuEnc075a-2.rar

different quality changes.

normal speed should be roughly between 0.72 and 0.75alphas speeds.
quality increase less aswell of course. for example

0.72 - SSIM= 82.888
0.75a - SSIM= 83.392
0.75a2 - SSIM= 83.108

of course please try on multiple different source types. especially hard sources etc where you think quality could be better.

The source has black top/bottom bars so the noHQ encode could skip MBs in B-frames

this version uses some different things for HQ and does allow skipping MB's. speed should be close to 0.72's HQ speed so its really if the quality is roughly the same or not.
again multiple types of source best.

all HQ encodes were a bit undersized varying from 1 - 10%.

yes extreme does that aswell. it seems the better the coding efficiency means saved bits are not always being added back for use.

finally to the guys that were trying 1 pass encodes. try this one and see if thats better. will be slower because the quality changes affect 1 pass aswell but check the sizing etc.

Fishman0919

7th January 2008, 14:31

Thank You.

I'm flying home tonite so I will have more time to do some testing

manolito

8th January 2008, 08:08

Just did 2 encodes with 0.75 alpha-2 in one pass VBR mode, normal quality. Speed was a little under 10% slower than 0.72. Max bitrate overshoot was identical to 0.72, and sizing was identical, too. And again I could not see a visual difference.

Cheers
manolito

hank315

8th January 2008, 23:52

Same tests with the updated QuEnc 0.75:

progressive source, 1800 kb
|------------------|---------|---------|---------|
| Encoder | OPSNR | SSIM 2 | Speed |
|------------------|---------|---------|---------|
| QuEnc72 noHQ | 46.78 | 82.20 | 80 sec |
| QuEnc75A(1) noHQ | 46.83 | 82.42 | 82 sec |
| QuEnc75A(2) noHQ | 46.77 | 82.22 | 68 sec |
|------------------|---------|---------|---------|
| QuEnc72 HQ | 46.57 | 81.55 | 105 sec |
| QuEnc75A(1) HQ | 46.85 | 82.46 | 94 sec |
| QuEnc75A(2) HQ | 46.50 | 81.30 | 93 sec |
|------------------|---------|---------|---------|

interlaced DV source, 7000 kb
|------------------|---------|---------|---------|
| Encoder | OPSNR | SSIM 2 | Speed |
|------------------|---------|---------|---------|
| QuEnc72 noHQ | 40.35 | 79.91 | 104 sec |
| QuEnc75A(1) noHQ | 40.45 | 80.30 | 119 sec |
| QuEnc75A(2) noHQ | 40.35 | 79.99 | 96 sec |
|------------------|---------|---------|---------|
| QuEnc72 HQ | 40.52 | 80.46 | 174 sec |
| QuEnc75A(1) HQ | 40.46 | 80.33 | 162 sec |
| QuEnc75A(2) HQ | 40.39 | 80.07 | 130 sec |
|------------------|---------|---------|---------|

Almost the same quality and good speed, also the sizing with all settings is good.
Only HQ with multi-threading enabled isn't OK, skipping of MBs in P and B frames doesn't work correct.

Best setting IMO regarding speed and quality: noHQ with multi-threading enabled.

Tdr

9th January 2008, 17:25

Would anybody be so kind and post a link, where a newbie can understand the function of constant quant in an encoders.

I just want to understand the basics.

Thanks a lot
Tom

dragongodz

9th January 2008, 21:59

Max bitrate overshoot was identical to 0.72, and sizing was identical, too

so back to normal then ?

And again I could not see a visual difference.

though if you are testing with sub-dvd quality source and reasonably good bitrate one wouldnt expect to see too much difference. :)

dragongodz

9th January 2008, 22:08

Almost the same quality and good speed, also the sizing with all settings is good.

actually the new test HQ is faster than the old so that means i could add a bit more to it. :)
so just comparing single threaded old HQ to single threaded new HQ they look reasonably close ? worth going with the new HQ for the MB skipping(assuming i can fix the problem with threaded MB skipping) ?

others opinions?

dragongodz

9th January 2008, 22:12

I just want to understand the basics.

unless you understand what quantization just telling you that "constant quant" means using the same quant for every frame isnt going to mean much to you.

so you may want to check out places like this

http://www.mpeg.org/MPEG/video/mpeg-video-for-your-eyes.html

if you really want to understand what any of these things mean.

Tdr

10th January 2008, 14:23

@dragongodz

Uuups, I had a lok at the link and I will never ask again (just kidding).

So I guess, it has nothing to do with CQ, I often used former days by tmpegenc?

Tom

Boulder

10th January 2008, 14:39

CQ in TMPGEnc means constant quality, not constant quantization.

Tdr

11th January 2008, 13:18

@Boulder

in extenuation of my Person, just have a look at Nuenc 0.21 (I am not using this, because of audio and its sure out of date), there is a function CQ Quality.

So I thought, Quenc can Constant Quality, but doesn´t offer this in the normal frontend.

Just have a look at the attachment

Tom

Boulder

11th January 2008, 13:21

Yes, the abbreviation differs between programs. QuEnc and HC mean Constant Quantizer whereas TMPGEnc and NuEnc mean Constant Quality. In CCE, there is a constant quality encoding method but it is called OPV.

Tdr

11th January 2008, 16:00

@Boulder

You`re right, but have a second look at the attachment, then You can understand, why I`am a bit confused...

cobo

18th March 2008, 01:28

I have some questions about Quenc encoding of progressive video that I posted here:
How to do pulldown on QuEnc encoded film for compatibility with older NTSC DVD players? (http://forum.doom9.org/showthread.php?t=135990)

bagheera1

23rd March 2008, 15:25

MrC

23rd March 2008, 16:07

I just tried to get the latest ver, but the link is dead
http://www.icefile.net/index.php?page=main&id=40e191346&name=QuEnc075a-2.rar

it seems that they removed the file.

does anyone have a link to the newest version?

Dowload AVStoDVD 1.2.3 (see link in my signature) and in the package you will find QuEnc latest release.

:)

Bye

Underground78

24th March 2008, 21:33

Hello,

It seems that encoding in MP2 with bitrate higher than 256 kbps doesn't work (bitrate stays at 256 kbps even if 448 kbps is selected) in 0.72, is this normal ?

Underground78

cobo

25th March 2008, 01:34

Yes, it's stated in the changelog under QuEnc 0.71:
".restricted MP2 and MP3 to encode to a maximimum of 256kbps even if set higher"

Underground78

26th March 2008, 19:31

Ok, do you know why ?

cobo

27th March 2008, 05:41

No, I don't know why.

Darksoul71

1st April 2008, 06:23

suburbanDK

31st May 2008, 22:20

Audio bitrates above 256 kBit/s make hardly sense for stereo / surround material (which is all that MPEG2 Audio supports). Encoding at higher bitrates would give no audible enhancement. So it´s restricted.

I've been transferring all my old Betamax(!) tapes to mpeg via a PVR-150 capture card using
384 kbps (the max) MP2 and the audio is pretty good via our high end stereo/HT system.
When re-encoding (after DGIndex demux) at a lower bitrate
(lowest DVD on the card is ~3000 kpbs, senseless overkill for the Betamax transfer)
the resultant 256 kbps MP2 audio is so nasty and harsh in the highs as to be unlistenable on the uber system.
Using BeSweet to take the 384 kbps MP2 to 384 kbps AC3 and then mux'ing that to the
reduced bitrate d2v/mpeg solves the problem, albeit it with a bit more work.

So, is AC3 rolling off the hi end or is it actually the higher bitrate that keeps it listenable?

DrDave

Irakli

1st June 2008, 00:42

@suburbanDK

I completely agree with you about the need to use bitrate higher than 256kbps sometimes. In most cases 256kbps MP2 sounds transparent to me. However, I usually need higher bitrate in 2 cases:
1) Extremely complex audio (electronic music, etc.);
2) Transcoding from lossy source.

MrC

10th June 2008, 17:38

@DGZ

Feature request: a cmd line option to set QuEnc window state (hidden, minimized, normal)

Thanks in advance

;)

Bye

45tripp

11th June 2008, 03:21

ahh,
and possibly a pulldown switch in cli

Fallen

30th September 2008, 12:39

First --Great little tool

But I hit a little gremlin

Simplified -- I'm using a short still video -- adding a "longer" audio
output (DVD)
audio is being clipped to video frame length
(I know the workaround -- smear the last frame of the video to the audio length framecount-- but this increases the final output dramatically)

Downloaded the code (can't get it to compile yet)
Could it be as simple as this -- case 3: (I'm probably seriously all wet :stupid:)

int CAVSReader::GetNumFrames(int nCaps)
{
int nRet = 0;

switch ( nCaps )
{
case 0: // Not Requested
case 1: // Only Video
nRet = m_nTotalVideoFrames;
break;
case 2: // Only Audio
nRet = m_nTotalAudioFrames;
break;
case 3: // Both --- whichever is greater
nRet = (m_nTotalAudioFrames > m_nTotalVideoFrames) ? m_nTotalAudioFrames:m_nTotalVideoFrames;
//nRet=m_nTotalVideoFrames;
break;
}

return nRet;
}

Well Thanx for looking

dragongodz

26th September 2010, 17:05

for anyone interested you may see a new version of QuEnc for xmas.

my father lost his 2 and a half year battle with cancer a couple of months ago. estate has all been settled etc.

so i hope to get back in to things soon. will maybe have to blow some cobwebs out and take it slow to start with, so ye heres looking at xmas. :)

hank315

26th September 2010, 18:15

Sorry to hear about your father...
But it's nice to hear from you again :)

Darksoul71

26th September 2010, 21:15

Hey dg,

sorry for your loss ! Cancer is a bad thing and I´ve seen three peoples dieing of it in my family.

I am happily watching out for a new version of QuEnc although I must admit that I haven´t it used as much as a few years ago.

Cheers,
D$

MrC

29th September 2010, 16:55

Hi DGZ and welcome back. It is nice to hear that old good QuEnc is not over. AVStoDVD continues to include 0.75 Alpha in its package. ;) I will contact you shortly for some fixes/improvements.

My sincerest condolences for your father loss.

dragongodz

1st October 2010, 07:13

thanks guys. your thoughts are appreciated.

Yobbo

3rd October 2010, 10:02

dragongodz, Quenc was a great tool! But seems like HCenc nowadays has stolen the throne? I'm just curious where you're thinking of taking this?

Revgen

3rd October 2010, 12:06

^Quenc is open-source and based off libavcodec, while HCEnc is freeware, but not open source.

As long as HCEnc is closed-source, Quenc and Mencoder have a place to stand.

MrC

3rd October 2010, 14:33

I still use QuEnc for many reasons: it does mpeg1 encoding, mpeg2 CBR encoding, it has audio encoding capabilities (mp2, ac3), can output muxed mpg files, can do simple authoring. Very nice app even nowaday. Ok, for complex source footage (dark scenes, fast motion) or for low bitrates HCenc is a better choice.

Some requests for coming release:

1. Multichannel audio mapping is not correct: when encoding 5.1 tracks I have to use GetChannel(1,3,2,5,6,4) to fix it.
2. AC3 output audio volume is quite low. At least comparing to ffmpeg (latest releases) or aften.
3. (cosmetic) Create a proper option for multithread encoding, now Trellis Quant is used as quick alpha workaround.
4. Improve multithread encoding speed: even on a dual core, HCenc 1-pass VBR is faster than QuEnc CBR.
5. Add adaptive quantization for mpeg2 encoding.
6. Add adaptive luma gain (dark scenes) for mpeg2 encoding.

Thanks in advance

;)

Bye

Gromozeka

4th October 2010, 10:33

How add VAQ from XviD to quenc? :o
Dark shikari ask that its possible for mpeg2
sorry me of my English
VAQ:
http://forum.doom9.org/showthread.php?t=135093&highlight=VAQ+xvid

Yobbo

4th October 2010, 11:03

^Quenc is open-source and based off libavcodec, while HCEnc is freeware, but not open source.

As long as HCEnc is closed-source, Quenc and Mencoder have a place to stand.

Sure! I agree! Is HCenc built from ground up (Fortran, I believe)? Not based on any pre-existing encoder (libavc etc)?

If I remember, one problem with libavcodec was the bitrate spiking, but I'm sure dragongodz fixed that in Quenc yes?

Also ability to output muxed mpg files is something HCenc aches for!

I remember I was always VERY pleased with Quenc output quality, the last builds were blemish-free to my eye, very nice!

GO, dragongodz!

manolito

4th October 2010, 13:05

I remember I was always VERY pleased with Quenc output quality, the last builds were blemish-free to my eye, very nice!

GO, dragongodz!
Totally agreed! I still use QuEnc in 1-pass VBR mode very often whenever I have enough bitrate available.

One suggestion for a new version: It would be nice if QuEnc could display the current quantizers during encoding. This would make it a lot easier to make a judgement about the resulting quality early into the encode and possibly start over with a different matrix and/or different filters.

Cheers
manolito