View Full Version : QuEnc 0.60 Released!
Pages :
1
2
3
4
5
[
6]
7
8
DarkFoon
13th October 2005, 01:20
The reason I suggested swapping matrices as opposed to modifying one was because I thought that would be easier.
This is how I thought it would work (with no idea as to how it would be programmed):
Let's say the user specified higher quality as opposed to smallest size. So, when the encoder encodes a frame that is not Q1 (or as high as it can go, like Q2 for 2 pass, first pass) it re-encodes that frame with a different matrix and if that fails, then another, until it exhausts all the ones it can use, and then it picks the best out of those. If it encounters a winner on its second matrix, then it will go with that one, and not even try the others: this would be for speed enhancement. Instead of going through them all and encoding each one, it would just try "the next one" and if the "next one" is better than "the last one" then it sticks with it, even if there are other past it that could od a better job, it doesn't know.
The hardest part, that I can see, is getting it to still respect the bitrate. I mean, if it just picked the largest frame it could every time, then bitrate would be thrown to the wind.
boombastic
13th October 2005, 21:19
is there a command line to use the author dvd feature?
freelock7
25th November 2005, 09:04
Tweaked rate control for 2 pass
I confirm it!
Encoded a movie with QuEnc062Prettyexperimental in 2Pass, VBR=4500, scenechange off, closed gop off and quality is great!
Any more prediction problem (correct). :)
manolito
26th November 2005, 23:27
When I select "Force Closed GOP" in QuEnc 0.61 it seems that the resulting GOP length can only be 1+(multiple of 3). A GOP length of 12 or 15 is not possible, only 10, 13 or 16. When I select a GOP size of 15, QuEnc will change it to the nearest lower value (13 in this case).
Is this normal (or even desirable), or is this something that should be corrected?
Cheers
manolito
dragongodz
22nd February 2006, 12:17
for those interested in doing a little experimentation/testing i present QuEnc 0.62 alpha3.
this should not undersize as bad as the other 0.62 alphas did. it should be closer to 0.61's undersizing, that is not always using quant 1 when it can for high bitrate or easy encodes. however feedback on not only high bitrate encodes but also low bitrate aswell, to see how good that is aswell, would be appreciated.
WARNING this is an alpha experimental version only and should be considered for testing purposes only.
binary(self extracting 7zip archive)
REMOVED. see alpha 4 link and mirror in later posts.
QuEnc 0.62 experimental source code
http://www.megaupload.com/?d=GL62KA1L
communist
22nd February 2006, 13:10
btw, any reason the last GOP on a 2-pass encode seems to get hit too hard? it's been behaving that way since the xvid RC was implemented. same with certain fade-ins and outs - quants just seem to get quite high.
Yes there is a reason the last GOP gets hit hard and I think it's because when we hit the last second some of the functions just stop working as they should. I'll look into it. Should be an easy fix, well spotted though.
Latest alpha still does that (not that it was supposed to be fixed in this version) - any news on that?
Also a temp. mirror for anyone else having trouble with megaupload:
Binary (http://www.stud.uni-goettingen.de/~s304280/D9/QuEnc/QuEnc062-alpha3.exe)
Source (http://www.stud.uni-goettingen.de/~s304280/D9/QuEnc/QuEnc-062alpha-src.rar)
guada 2
22nd February 2006, 13:41
:thanks: communist.
Bye.
freelock7
22nd February 2006, 18:58
Happy to test again:) .
DGZ, there is a problem -a great problem- in the bitrate average setting 2Pass.
At low bitrate <3000, prediction is not correct (oversizing+++)!
If you choose a VBR=2500 (or another value < 3000), prediction is always 4500!
dragongodz
23rd February 2006, 11:57
Happy to test again
thanks. its one of the hardest things to get people to do. ;)
there is a problem -a great problem-
woops. see now thats why i need people to test and with different bitrates etc. :)
this should fix it
http://www.megaupload.com/?d=B3HIFBOZ
Inc
23rd February 2006, 17:58
ehhm ....
I had a look into the sources of AVSEnc.cpp of the Qenc Source package.
In the section where its determined when using the QLB Matrix I found this ...
if ( bUseQLB || csMatrixFile.IsEmpty() == FALSE )
{
CString csQLBIntra, csQLBNonIntra;
csQLBIntra = CString("8 16 19 22 26 27 29 34 ")
+("16 16 22 24 27 29 34 37 ")
+("19 22 26 27 29 34 37 39 ")
+("22 22 26 27 29 34 38 42 ")
+("22 26 27 29 32 36 40 50 ")
+("26 27 29 32 36 40 50 61 ")
+("26 27 29 35 40 50 59 75 ")
+("27 29 35 40 50 59 75 89 ");
csQLBNonIntra=CString("16 17 18 19 20 21 22 23 ")
+("17 18 19 20 21 22 23 25 ")
+("18 19 20 21 22 23 24 26 ")
+("19 20 21 22 23 24 26 28 ")
+("20 21 22 23 25 26 28 29 ")
+("21 22 23 24 26 28 29 31 ")
+("22 23 24 26 28 29 31 34 ")
+("23 24 25 28 29 31 34 38 ");
...
...
..
.
What makes me thinking is this line where its asked IF the user uses the integrated QLB Matrix or if the Matrix is loaded from a given matrix text file.
if ( bUseQLB || csMatrixFile.IsEmpty() == FALSE )
Im very new in C/C++ but ...
"csMatrixFile.IsEmpty() == FALSE" doesnt this mean if I(t)sEmtpy then a boolean true is the result?
(I couldnt find the specific class in the source files thats why Im asking)
So if the user determined as matrix the integrated QLB one then >bUseQLB=true< and if no external matrix has been loaded then >csMatrixFile.IsEmpty() = true< ... did I catch the right?
Cause if yes then even if an external matrixfile is loaded, still the usage of QLB is forced??
But maybe Im too much in Carnaval here in cologne at this moment *lol
Nic
23rd February 2006, 18:04
@Inc: Look just one line lower and you'll see:
if ( csMatrixFile.IsEmpty() == FALSE )
{
// Load XVID matrix file
So then it checks again that the user has given a matrix file, then loads it if so.
Inc
23rd February 2006, 18:16
ah, ok .... as said too much carnaval in here ;)
freelock7
23rd February 2006, 18:36
DGZ, the link doesn't work.
there is a problem...
Sure it's not a critic. I know you're working on it!:o
Zarxrax
23rd February 2006, 23:02
It's been a long time since there was any release of this great encoder!
I was just wondering a few things.
1.) Is the 0.62 alpha 4 by DGZ the suggested version to use?
2.) Are there any known bugs or issues I should be aware of?
3.) Is a new release planned anytime soon?
Thanks.
dragongodz
24th February 2006, 01:19
DGZ, the link doesn't work.
just checked it and its working fine here. see the count down in the upper right ? once that gets low an add covers it, slide the add down and once the countdown ends it turns to the download link.
a mirror aswell incase people do have problems.
http://s12.yousendit.com/d.aspx?id=0LBY9IVIM46IJ19TJ4XIISAOQF
Sure it's not a critic. I know you're working on it!
i didnt takr it as such either. we need people to spot these things so thank you. ;)
1.) Is the 0.62 alpha 4 by DGZ the suggested version to use?
NO. its an alpha and as i said in the alpha 3 post strictly for testing. if it proves to give improvements and not fubar things then a proper release will eventually be done.
2.) Are there any known bugs or issues I should be aware of?
the last 20 odd frames are stuck on quant 9 for some bizarre reason. i want to get RC in general working better before worrying about other things though. easier to concentrate on 1 thing at a time.
3.) Is a new release planned anytime soon?
define soon. :)
there is no point doing a proper release before there is something that makes it worth releasing. thats why i have released this test alpha for example.
Zarxrax
24th February 2006, 02:22
Ah, I didn't even realize that you released that yesterday :p
I was looking down the dates of all the posts, and they are all last year, then suddenly yours was yesterday :p
I have some issues to report:
1. When you uncheck the interlaced option, the pulldown option is no longer selectable. However when you first go to advanced options, pulldown will be available, no matter if interlaced is checked or not.
2. Mpeg-1 files dont seem to work right. If I use the built-in splitter in media player classic, the file seems to stall at the very beginning and then catches up pretty quickly. If I use the default splitter on my system the file will barely play at all. It starts playing then suddenly begins freezing for long periods of time. The longer it plays, the longer it will freeze each time it displays a frame.
dragongodz
24th February 2006, 03:03
1. When you uncheck the interlaced option, the pulldown option is no longer selectable. However when you first go to advanced options, pulldown will be available, no matter if interlaced is checked or not.
something else for me to look at later. pulldown needs the seq headers marked as interlaced even if encoding progressive if you want to use pulldown. if not this has been shown to cause stuttering playback on hardware dvd players and its also been shown CCE does it that way by default. thats all from memory. :)
so i will have to check if the changes for pulldown set the seq headers to interlaced or not. if they dont then pulldown would have to be limited to interlaced encoding for that reason.
2. Mpeg-1 files dont seem to work right.
i just checked a 30 second clip encoded to 1 pass cbr, 1 pass vbr and 2 pass vbr MPEG1. i tested with just MPC splitter, with MPC splitter and decoders and with external splitter and decoder. no playback problems at all.
try MPC with splitter and filters and see how that goes for you because it sounds more like a problem whatever codec is being used has. you can see what codec it is since it will be listed in the filters (right click on playing video) with MPC. mine used MS mpeg1 decoder 2.0.
if that still doesnt work for you then can you list what decoder is being used and what settings you used to encode. oh and try QuEnc 0.61 but i am guessing you will see the same from that.
Zarxrax
24th February 2006, 04:12
My mpeg decoder was just called "mpeg decoder". I switched it to ffdshow and there was some improvement. Playback using mpc internal splitter seemed to work perfectly fine, but using my system default splitter "mpeg I-stream splitter", it was still freezing, but only at about half the rate as before i used ffdshow to decode. CPU is not being maxed or anything.
I blocked that splitter and then it used MainConcept splitter. It seemed to be fine for a while but then it too started stuttering and freezing.
After blocking all 5 million MainConcept splitters that were on my system (damn, it seems like every single adobe app installs a new one), I was left with "Mpeg splitter (low merit). This one actually seemed to play fine with no problem.
But in any case, this isn't how a normal mpeg performs on my system. Just about any of those splitters would play my other mpegs just fine.
At this point, I decided to try QuEnc 0.61. Output was the same. Finally, I tried the "no audio" setting. Finally, it seems to play back perfectly normally. One problem though. The output file is only 30 seconds, and my input was 2:40. It seems it just cut off the last 2 minutes or so.
dragongodz
24th February 2006, 05:34
My mpeg decoder was just called "mpeg decoder"
if you select its you will probably find that is the MS decoder.
can you tell me all the settings you used ? also a small sample clip to test would be helpful aswell if possible.
The output file is only 30 seconds, and my input was 2:40. It seems it just cut off the last 2 minutes or so.
try playing the AVS first to make sure that is full length. next check that it only plays 30 seconds and not just says that at the bottom of MPC but plays full time(i have seen that happen and is not QuEncs fault).
freelock7
24th February 2006, 08:59
Link ok!
At low bitrate (<3000) Alpha4 has no particular difference with Q061 :same Q, same bitrate, same -good-prediction*.
At high bitrate (>5000) Q061 is undersized (5120 )
Alpha4 has a better high bitrate peak control (8900 against 9600 for Q061 with a maxbitrate set=9200) but it's still undersized (5120).
*based on a clip video of 120"
dimzon
24th February 2006, 15:03
thanks. its one of the hardest things to get people to do. ;)
woops. see now thats why i need people to test and with different bitrates etc. :)
this should fix it
http://www.megaupload.com/?d=B3HIFBOZ
All download slots (300) assigned to your country (Russian Federation) are in use.
Please try again later. :devil: :devil: :devil:
dragongodz
24th February 2006, 15:12
At low bitrate (<3000) Alpha4 has no particular difference with Q061
well thats good. :)
still undersized
can you please see what sort of quants its giving ?
All download slots (300) assigned to your country assigned to your country (Russian Federation) are in use.
so does that mean 300 people are already downloading that file or is it 300 slots total from megaupload for RF ? be a bit strange if its the second.
i also gave a yousendit mirror in another post so try that aswell.
freelock7
24th February 2006, 17:49
For a 5500 VBR
Global Q is the same (2.35 against 2.34) but a high bitrate peak shows that:
Alpha4=8706 (Bitrate)-6(Qlevel)
Q061=9170(bitrate)-5.44(Qlevel)
At low bitrate (VBR=2500)
Quantization is very similar (globalQ=4.90 against 4.89) with a little difference in high bitrate peak:
Alpha4=8309(bitrate)- 6.14(Qlevel)
Q061=8.360-5.88
Zarxrax
24th February 2006, 17:51
Ok, I've done a little more testing.
The problem seems to be with the bitrate used. If I set the bitrate to 1000 (max bitrate 9800), the files seem to come out fine and work on all my splitters. If I raise the bitrate for the mpeg-1 to 2000 though, all hell breaks loose.
snherbst
25th February 2006, 02:48
Hi
I've actually have a question regarding MPEG4. MPEG4 supports a varity of audio formats the list includes .mp2 and mp3. So why is there not other formats supported in QuEnc than AAC?
http://forum.doom9.org/showthread.php?t=62723
http://gpac.sourceforge.net/index.php
http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm
Zarxrax
25th February 2006, 20:38
Ok, some more possible bug reports, some questions, and some suggestions.
I am not only getting strange playback errors with MPEG-1 files encoded from QuEnc, but also with MPEG-2 files. It seems there may be some relation with the quantizers used. An mpeg-2 encode using constant quantizer 1 reported a running time of 29 seconds (although the source is 20 seconds). Although it had a reported running time of 29 seconds, it would abrubtly end at about 20 seconds. Encoding again with constant quantizer 2 created a file with the correct running time.
Encoding a quant 1 video as "seperate passes" and then multiplexing them outside of quenc resulted in a correct file. I urge you to check out the multiplexing code in quenc to see if any problems exist.
Next, using trellis with quant 1 causes artifacts. Probably outside of your control, but I had heard this was supposed to be fixed?
Now some questions and suggestions for the interface.
Why is Extreme and Slow settings grouped with GOP and Bframes? This doesn't make logical sense to me.
Since extreme and slow enables trellis by default maybe trellis could be removed altogether? Then move extreme to the main form, replacing trellis. Unless someone likes to use trellis without extreme, I guess.
Next, why is GOP default at 12? The tooltip says for dvd these should be 15 or 18, so wouldnt one of those make a more logical choice for a default?
Finally, is a gui color selector really necessary? I don't really object to it, but it seems unneccessary and would simplify the gui further by removing it.
dragongodz
26th February 2006, 06:11
freelock7 - thanks. its good 0.62 alpha is now so close to 0.61 as the earlier 0.62 alphas undersized worse. now i just have to see if i can push it higher without breaking anythjing. ;)
MPEG4 supports a varity of audio formats the list includes .mp2 and mp3. So why is there not other formats supported in QuEnc than AAC?
i have a really easy out for this ... its Nics fault. :)
Nic added mpeg4 for converting video to play on his PSP. i will look at adding mp3 atleast later. however this is not what i am working on at the moment so it wont be done yet. please also remember that this is the first version that even has mpeg4 and is an ALPHA so its not going to be complete and may contain bugs. this is where testing by others proves helpful to find such problems so they can be fixed and then other things added.
The problem seems to be with the bitrate used. If I set the bitrate to 1000 (max bitrate 9800), the files seem to come out fine and work on all my splitters. If I raise the bitrate for the mpeg-1 to 2000 though, all hell breaks loose.
well i tested with 2500 and plays 100% fine here. i suspect its either your hardware(what cpu do you have ?) or software thats causing problems. without knowing what settings you are using to encode i can not 100% replicate what you are doing of course. even a small encode that shows problems would be something to see if it plays ok on mine or not.
reported a running time of 29 seconds (although the source is 20 seconds). Although it had a reported running time of 29 seconds, it would abrubtly end at about 20 seconds. Encoding again with constant quantizer 2 created a file with the correct running time.
so in other words it played the correct time irrelevant of what the reported time was.
i actually came across this ages ago and reported it in a thread. the thing is i found, after much testing, that it was decoder dependant. that is some decoders reported the wrong time and others didnt. also with one you could set use PTS or frame count, when set frame count it was way out but PTS was nearly right.
i was also able to replicate the exact same problem with other encoders so decided it was really the decoders problem trying to guess the correct total time. nothing i have seen has made me change my opinion on that yet.
Next, using trellis with quant 1 causes artifacts. Probably outside of your control, but I had heard this was supposed to be fixed?
this should only generally happen using custom matrices. there is a way to reduce this from happening but since it reduces the precission the ffmpeg guys rejected it, as they do so much its not funny. if i remember i will fix that when its time for a proper release.
Since extreme and slow enables trellis by default maybe trellis could be removed altogether?
actually no extreme should not enable trellis as it did in early QuEnc versions. this was already meant to be changed versions ago.
Next, why is GOP default at 12? The tooltip says for dvd these should be 15 or 18, so wouldnt one of those make a more logical choice for a default?
another easy out ... Nics fault. he decided the defaults. :D
though 12 is not a bad default really. the 15 and 18 are actually max numbers.
Finally, is a gui color selector really necessary? I don't really object to it, but it seems unneccessary and would simplify the gui further by removing it.
Nic likes the red while i like grey. others may like other colours to more match their desktop. its not a big thing so really doesnt hurt. so its in for the forseeable future.
Zarxrax
26th February 2006, 18:39
so in other words it played the correct time irrelevant of what the reported time was.
i actually came across this ages ago and reported it in a thread. the thing is i found, after much testing, that it was decoder dependant. that is some decoders reported the wrong time and others didnt. also with one you could set use PTS or frame count, when set frame count it was way out but PTS was nearly right.
i was also able to replicate the exact same problem with other encoders so decided it was really the decoders problem trying to guess the correct total time. nothing i have seen has made me change my opinion on that yet.
You replicated the problem on other encoders? Which other encoders does this happen with? I've never seen it from anything else besides Quenc. Plus I have hundreds of mpeg files and I have never seen these issues aside from my own encodes made from quenc.
And if its a problem on the decoding end, it happens with at least half of the decoders I have tried. Perhaps its more of a case of some decoders being more "strict" in what they will accept than others? Plus, note how I found that muxing the video in a seperate program left me with a fine stream, while muxing in quenc did not.
In any case, when someone chooses to make an encode to MPEG-1, they generally choose that because its a universal format that can be played practically anywhere, correct? Well if it can't be played properly by a lot of decoders out there, then there is a serious problem.
Zarxrax
27th February 2006, 19:51
Ok, I think I've FINALLY got some real insight into what the problem is. I got ahold of an old copy of tmpgenc, and I'm using it to mux the files now. It reports buffer underflow errors when I use it to mux the streams. Lots of them. I'm sure this is the main problem. Only by significantly lowering the bitrate will tmpg mux without complaining about buffer underflows.
I also found a program called Multiplex that can mux mpeg-1 files, and it too complains about the buffer underflows.
Hope this helps.
Mug Funky
3rd March 2006, 08:26
yo, just been trying the alpha 4 out for a bit. it's hitting average BR perfectly (unless the file is all Q1 or max BR, but i can't expect better than that obviously), and it's not underflowing. that's on a wide range of higher bitrates - everything from 4000 to 8500 (with max 8500 each time).
from looking at bitrate scans though, it looks like bitrate distribution could stand to be averaged over a longer period (i don't know how long it is right now, but it seems to compensate very quickly for hard scenes). also, it might do well to start with a lower quantizer - it tends to start at around 3, when it could safely start a little lower, especially if there's a fade-up at the start (these get hit rather hard :().
all in all, i think it's ready as it is to go beta or higher. it's almost perfect 1-pass RC.
[edit]
maybe the averaging period could depend on the playing length of the input? does quenc have access to that kind of info? that would mean it could be conservative and compensate quickly if the input length is short (like 1-2 mins), and react slowly if the input is long (like 80 mins or more). hell, this might even be happening already...
mean
3rd March 2006, 11:01
For the last frames stuck at Qz=9
if(framenum<_nbFrames-_roundup)
{
...
}
else
{
if(q<9) return 0;
}
Since we don't have a next half gop to check vbv, it is encoded at cq=9. Could probably use the last Qz as since there is not infra coming in, the risk & damage caused by underflow would be light.
dragongodz
3rd March 2006, 11:48
It reports buffer underflow errors when I use it to mux the streams.
actually this does make some sense. mpeg1 was never made for high bitrate, for example for dvd mpeg1 is limited to 1700(ish) total muxed bitrate from memory. i will have to dig out the specs some time and look at exactly what it says.
Since we don't have a next half gop to check vbv
23 frames(PAL encoding) is more than half a GOP. :)
actually from memory the first period is 1 second so that actually makes sense. i will have to look at and play with that later aswell.
EDIT:
of course a better solution would be to encode this last section to the relevant percentage of the target bitrate. so for example if you have 90% of 1 seconds worth of frames you would target those last frames to be 90% of real target bitrate. you should never need to worry about underflows with that. just my opinion anyway. ;)
Zarxrax
3rd March 2006, 19:24
By the way, my interest in QuEnc is because I am working on an MPEG1/2 guide for a site I frequent, and I would prefer to use a nice free encoder such as QuEnc as opposed to a commercial one like TMPGenc. I just can't recommend a method that might be producing files that won't work properly, when a another method has been working fine for years.
So I hope I don't come across sounding too demanding or anything :D
dragongodz
4th March 2006, 01:26
I just can't recommend a method that might be producing files that won't work properly
the problem is replicating problems. that is you say your playback is bad while i can play it fine. is this then a problem with QuEnc or could it be something more specific to your pc ? so to try and replicate it exactly i need information such as whats your cpu, what exact settings are you using, can you provide a small sample that show the problem etc. i have asked these things several times already but there comes a point where i will simply stop asking when they are not answered.
Zarxrax
4th March 2006, 01:49
Ok, sorry, here is a sample file I have encoded: http://zarxrax.kicks-ass.net/quenc_test.mpg
(16MB)
Settings:
Codec: MPEG-1
Constand Quant: 2
Use VBR
High Quality
18 GOP Size
2 Max B-frames
Force Closed GOP
Auto Max Bitrate
4:3 Aspect Ratio
Mux Profile: MPEG-1 System
Audio Codec: MP2
Audio Bitrate: 224
Edit: Oh, and my CPU is an old Pentium 4, 2.26ghz.
dragongodz
6th March 2006, 01:29
had a quick look and yes that stutters a bit. then again the average bitrate is 6305507 and maxes at 10941323 and thats just video. so not the sort of bitrate mpeg1 was designed for as i said.
i will however look at making some changes that may help fix that anyway. unfortunatly some real life things have come up which means most of this week i am going to be away from my pc.
Mug Funky
6th March 2006, 01:31
constant quant modes don't respect max bitrate settings (unless something's changed recently?)... so there might be a difficult part in that video that's causing underflows at q2. most software splitters wont care about this, but some could if they're strict about compliance.
try set avg rate = max rate, then you'll essentially get CBR without padding.
Zarxrax
6th March 2006, 01:57
Well, its not even a problem with just using high bitrate like that.
Here is another file I encoded, exact same settings, only I set the bitrate to 3000.
http://zarxrax.kicks-ass.net/quenc_test3000.mpg
This file also stutters badly and reports the playing time wrong. Even VLC player doesnt handle it properly.
In contrast, I have a nearly 10mbps mpeg1 file sitting here that someone made on a different encoder, and I have absolutely no problems playing it. If its as you say, and the bitrate is simply too high, then it makes no sense that my 3000kbit file will break down, while a much higher bitrate file will play fine.
In fact, I must have at least 20 to 30 mpeg files that use higher average and peak bitrates than this file I am posting now, and there are no problems with any of them.
Whats more, I can encode the file in tmpg with an EVEN HIGHER bitrate than that first file was, and it still plays properly.
dragongodz
6th March 2006, 02:24
Well, its not even a problem with just using high bitrate like that.
if you knew what else i was thinking then you would know that yes there is more to it than that but it is the high bitrate being used when its not expected to thats the heart of the problem. :)
In contrast, I have a nearly 10mbps mpeg1 file sitting here that someone made on a different encoder, and I have absolutely no problems playing it.
yes and even without looking i think i know what they are doing. once i get a chance to confirm it then i can make the needed changes aswell. why wont i say what i am thinking ? well i want to be sure i am right first of course. ;)
reports the playing time wrong
i talked about that before. it is a different subject.
Sagittaire
7th March 2006, 19:21
QEnc use libavcodec librairies for MPEG2 encoding. Libavcodec use very advanced fonctionnality like:
- RDO for MB decision
- Adaptative Bframe
- Multi-pass (solve some overflow problem)
- ratio/offset for bframe
- Adaptative Quantisation with various masking like lumimasking
- Rate distorted optimal coded block pattern
- Rate distorted optimal quantization for each macroblock
These setting done very better compression efficiency (Higher metric with smaller size for same constant quant encoding).
Why not use these setting in QEnc ... ???
dragongodz
10th March 2006, 00:11
just a quick note about the problem Zarxrax is having. i have had him test a version with a change that does similar to what both CCE and MainConcept do. it does improve playback. he said he still has some problems with some players though so i will try to look at that later aswell. just so people know things are going on. :)
Why not use these setting in QEnc ... ???
some of those types of settings are used for extreme & slow option. notice the speed of it though ? i could also turn diamond size up to 6 and increase quality but the gain is small compared to a huge speed loss so not really worth it. i will probably tweak the extreme setting though and see what can be hopefully gained without too much more speed impact. its just not high on my priority list at the moment.
DarkFoon
10th March 2006, 03:57
@DGZ
What language is QuEnc programmed in?
Also, couldn't there be a place in the GUI for the user to enter "custom" LAVC options to be passed to the encoder? (kinda like the DivX encoder has the command-line box)
For example, if somebody didn't care about the speed tradeoff and wanted diamond size 6, they could set it there.
Just an idea, I can understand the reasons not to put that in (cluttered GUI, newbies complaining about things not working, etc..) But like any project with something like that, just say it's unsupported and tell them to shutup. :devil:
I, while I like to use QuEnc, don't like being "protected me from myself" which is how I feel lacking more control over the encoding process. Now you'll probably tell me to go use Mencoder, and I don't like Mencoder, so I'm done.
Just my .02$
dragongodz
10th March 2006, 12:19
What language is QuEnc programmed in?
C/C++
Also, couldn't there be a place in the GUI for the user to enter "custom" LAVC options to be passed to the encoder? (kinda like the DivX encoder has the command-line box)
For example, if somebody didn't care about the speed tradeoff and wanted diamond size 6, they could set it there.
the aim of QuEnc though is to be both simple and good. to add the ability to use any and all settings is asking for lots of questions. if people are really that worried about getting the smallest quality difference,which they would probably never see with actual playback, even though it may take a week to encode then they surely should try using something like mencoder or ffmpeg and everything that implies. ;)
while I like to use QuEnc, don't like being "protected me from myself" which is how I feel lacking more control over the encoding process.
the fundamentals are there though so you can trade some speed for a bit extra quality etc. adding in lots more settings will not suddenly make encodes better and infact can cause results to be worse because a lot of people do not know what they are really doing, even though they think they do. and no i didnt mean you by that.
Now you'll probably tell me to go use Mencoder, and I don't like Mencoder, so I'm done.
maaaate, would i do that ? :devil:
DarkFoon
10th March 2006, 15:41
the aim of QuEnc though is to be both simple and good. to add the ability to use any and all settings is asking for lots of questions.
...
the fundamentals are there though so you can trade some speed for a bit extra quality etc. adding in lots more settings will not suddenly make encodes better and infact can cause results to be worse because a lot of people do not know what they are really doing, even though they think they do.
Point taken.
and no i didnt mean you by that.
Of course not, I wouldn't have ever thought that. (no sarcasm) (really I mean it. stupid internet and it's inability to carry tone!)
As soon as a few of the bugs in QuEnc get worked out(fades getting hit too hard, etc...), I'll be using it for my DVD creations.
And, this is the best part, I may be able to help contribute in the future: ("oh no!" I hear you thinking :devil: ) I am taking a C++ class this term. Sure, I won't be C++ master in 10 weeks, but I'll at least be able to read the source and know whats going on, and maybe even help.
dragongodz
11th March 2006, 01:34
(no sarcasm) (really I mean it. stupid internet and it's inability to carry tone!)
ye i know what you mean, which is why i had to say i was not meaning you.
I am taking a C++ class this term. Sure, I won't be C++ master in 10 weeks, but I'll at least be able to read the source and know whats going on, and maybe even help.
any help making QuEnc better is always welcome. as for being a C++ master, well i am self taught so am no master either. now you know why i work so slow. :)
DarkFoon
11th March 2006, 03:25
cool!
Now, I've forgotten where to get QuEnc or its source code (I guess at the same place, right?). Maybe a link?
dragongodz
11th March 2006, 03:36
Maybe a link?
hmm those last links i gave in this thread should still be ok. however i have made a few little tweaks etc so i will bundle up the latest source code etc and PM you a link tonight.
dont anybody else bother to ask since the changes etc are still very experimental. i will give a proper link here when i am interested in having people test out a binary.
Rockas
15th March 2006, 00:56
Hi dragongodz and nic!
During the tests on my SynthEditor I found a few strange behaviour with QuEnc... I'll try to present a full report when I enable video encoding with QuEnc it has to do with size predictions but that is not my main question today :)
on syntheditor I'm using QuEnc to take care of the Audio encoding (video encoding will come next) and that brings my question.... are you thinking about enabling 5.1 AC3?
another question
is it possible to encode video and audio at the same time but output them separate (not program stream)?
Mug Funky
15th March 2006, 03:31
yep, there's a mux option "separate passes". does video then audio.
alternately you could simply run it twice (commandline perhaps) with either "no video" or "no audio" modes. this is helpful for long batches - you feel better about the encode when all the audio gets done at super speed before the long hard slog at the video :)
Rockas
15th March 2006, 10:24
yep, there's a mux option "separate passes". does video then audio.
alternately you could simply run it twice (commandline perhaps) with either "no video" or "no audio" modes. this is helpful for long batches - you feel better about the encode when all the audio gets done at super speed before the long hard slog at the video :)
The problem is that the "separate passes" is not on th CLI documentation... or... I'm not seing right :) - that can happen to :D
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.