QuEnc 0.60 Released! [Archive] - Page 8

Ebobtron

24th March 2006, 18:13

@dragongodz
yes, I thought the ac3 levels issue had been bounced around. It has been so long I remember it not.

@Rockas
I can only offer this caution. QuEnc has some kind of limiter or clamp working, but shows no signs of normalization for low or high level input. My ears tell me some clipping begins if I push the input level to high.

I believe, and my tests show that the max output of QuEnc's ac3 encoder is -10db. You may input +20db, I think you will find a -10db out which sounds clipped. If you input -10db your result will be -20db.

dragongodz’s suggestion to normalize would make more sense.

But I think for know -10 is all we are going to get.

Rockas

24th March 2006, 18:29

I made a few tests with "AmplifyDB(9)" and it didn't look like cliping is occuring... I just released my new SynthEditor with AmplifyDB(9) enabled... can you try it for a little?

In the mean time I'll try with some more different sources.

dragongodz’s suggestion to normalize would make more sense.
ummm... I don't know about that... if QuEnc encodes -10db then the sound will always get a lower level... maube it can help a little but...

thank you

Zarxrax

24th March 2006, 20:36

Would it be possible to implement DV encoding in QuEnc? Unless I'm mistaken, its just a specific case of mpeg-2, right?

Rockas

24th March 2006, 20:38

At this point SynthEditor is supposed to encode DV using AviSynth... QuEnc for audio and QuEnc/HC for video... target size will be accurate... I hope :D

Zarxrax

25th March 2006, 03:31

At this point SynthEditor is supposed to encode DV using AviSynth... QuEnc for audio and QuEnc/HC for video... target size will be accurate... I hope :D

Oh, interesting :)

communist

25th March 2006, 08:00

Would it be possible to implement DV encoding in QuEnc? Unless I'm mistaken, its just a specific case of mpeg-2, right?
No its more like an "advanced MJPG".
Since QuEnc uses libavcodec a LOT of formats could be added but I dont think thats what everyone wants - since implementeng / testing / bug-fixing etc. them will take quite some time.

Sagittaire

25th March 2006, 21:14

@ dragongodz

Libavcodec (and QEnc) seem buggy for quant value only for MPEG2.

OSD for ffdshow show x2 real scaling for quantizer (only 2,4,6,8 ... etc etc)

dragongodz

26th March 2006, 01:46

Sagittaire - can you explain in a bit more detail what you mean ?

Zarxrax

26th March 2006, 02:34

Sagittaire, I believe it is probably a bug in FFDshow. Try with a different encoder. Using TMPGenc at the highest bitrate settings FFDShow says its using Quant 2.

Also examining the files (mpeg1 only, there should be no difference though) in MPEG_Stat, reports that the frames are encoded at Quantizer 1.

dragongodz: can we maybe expect a new beta version soon, I hope? :)

Sagittaire

26th March 2006, 13:08

Sagittaire, I believe it is probably a bug in FFDshow. Try with a different encoder. Using TMPGenc at the highest bitrate settings FFDShow says its using Quant 2.

1) I'ts wrong : TMPGEnc max quality (CQ100) done quantizer 1 for each macroblock without vbv limitation. FFDShow OSD macroblock quantizer show that only for Libavcodec MPEG2. MPressionist MPEG-2 Analyzer seem show same quantizer than FFDShow.

2) In fact Libavcodec show internaly that it use 1, 2, 3 ... etc but in fact Libavcodec apply x2 scaling for quantizer and use only 2, 4, 6 ... etc for each frame or macroblock if you use adaptative quantisation.

You can make little experience too:
Libavcodec constant quant encoding q2 done approximatively the same bitrate than all other MPEG2 encoder (HC, TMPGEnc, CCE ... etc) at q4 with same source, matrix, dc ... etc

In fact Libavcodec can't simply use impair quantizer for MPEG2 (for frame or macroblock) and use only pair quantizer. This "bug" can explain for example saturation for Libacodec at very high bitrate because use quantizer 1 is simply impossible ... ???

dragongodz

26th March 2006, 13:35

Libavcodec constant quant encoding q2 done approximatively the same bitrate than all other MPEG2 encoder (HC, TMPGEnc, CCE ... etc) at q4 with same source, matrix, dc ... etc
confirmed. something is a bit screwey here. frames are marked as quant 2 but macroblocks are quant 4. will add it to the list of things to see if i can fix.

can we maybe expect a new beta version soon, I hope? :)
well as you can see theres still some things need fixing. add in all the things Rockas has raised and you will see there is still a bit for me to do. :)

wmansir

26th March 2006, 16:36

Hey guys, I'm updating the DVD-RB guide for Doom9 and I have a question about QuEnc.

DVD-RB has two options for QuEnc 1-pass mode. CQ VBR (which DVD-RB figures out the CQ, like CCE 1-pass), and QuEnc's 1-pass, which I have no first hand information about. Besides the method used, are there any major differences between them in terms of speed, quality or size prediction?

From a quick search of this thread it seems QuEnc's 1-pass is pretty good, so is DVD-RB's CQ 1-pass more of a legacy option? Or are there situations where it is preferred?

Rockas

26th March 2006, 22:21

Well I guess that "1 pass CQ" will always deliver a better quality than 1 Pass VBR.
CQ (as you know) will be an Encode based on the Q value... found after Rebuilder's analisys.

1 Pass VBR is used the same way the 2 passes VBR but it will do just one, of course :)

I don't know this is the kind of answer you were expencting but...

Inc

26th March 2006, 22:52

dragongodz

27th March 2006, 00:10

Well I guess that "1 pass CQ" will always deliver a better quality than 1 Pass VBR.
i would have to disagree with that. it can be very bitrate and source dependant. for example if you are encoding to a small size you may end up with a CQ of say 8(just for example). however 1 pass VBR will vary the quants and use lower sometimes when it thinks it needs it and higher when it thinks not much difference is lost. so 1 pass VBR can have better looking parts in such a case.

also of importance is that CQ with QuEnc is not max bitrate restrained. that gives the potential for exceeding legal max bitrate for dvd(again for example) if its very low quant.

Mug Funky

27th March 2006, 04:03

CQ is very good for credits - for whatever reason (subpel accuracy or lack of?) credits can be given massively high quants and still look good, but by the same token, both 1 and 2-pass ratecontrol (in any encoder) seems to give them far too high a bitrate, usually around max bitrate if there's more than a few words on the screen.

so CQ is good in these situations, especially if you wish to shave a couple of hundred megs off an encode without damaging anything :)

credits usually still look good up to (linear) quant 8-12. you could go further, but there's a point of diminishing returns when the credits are already so small that hitting them harder will only buy you an extra meg.

dragongodz

27th March 2006, 04:09

both 1 and 2-pass ratecontrol (in any encoder) seems to give them far too high a bitrate, usually around max bitrate if there's more than a few words on the screen.
i think you will probably find its because most encoders see all that moving text as high motion.

Sagittaire

27th March 2006, 17:04

Due to Quants (some postings from Sagittaire before)

TmpgEnc, CCE --> Non-Linear Quantization
Libavcodec --> Linear Quantization

Do search of some posts from PeterCheat ....
http://forum.doom9.org/showthread.php?p=564629&highlight=linear#post564629

If BV shows in a libavcodec encoding a Q of 2 then its comparable to a Q of 4 in TmpgEnc,CCE etc. FFdshows Q parser output imho only is capable to provide integer values. So if a float of 3.x results, fdshow repots 4 --> Imho

And IMO Bitrate Viewer simply sucks here because BV read simply frame header and don't make real stream analyse. FFDshow and MPressionist MPEG-2 Analyzer done same result.

1) Libavcodec can use adaptative quantisation in two mode:
- Macroblock Rate Distortion
- Macroblock masking (lumi, dark, spacial, temporal, inter masking)

for example:

Libavcodec encoding
http://multimediacom.free.fr/Video/LAVC-AQ.jpg

Like you see:
- Macroblock quantizer is not constant
- FFDShow OSD show real frame average quantizer
- Libavcodec use only pair quantizer (4,6,8,10 and 12 in this frame) and never impair quant

CCE encoding
http://multimediacom.free.fr/Video/CCE-AQ.JPG

Like you see:
- Macroblock quantizer is not constant
- FFDShow OSD show real frame average quantizer
- Libavcodec use only pair and impair quantizer (7,8 and 10 in this frame)

2) I think that actually all MPEG2 encoder must always done approximatively same size for same quantizer if comparable setting are used (matrix, DC precision, good ME level ...) and certainely not half size. Size variability is difference between optimisation like ME search function, Rate Distortion, trelli : gain can be perhaps 5, 10 or 25% for size between MPEG2 encoder but certainely not 50% ...

Mug Funky

28th March 2006, 06:27

hmm. try an encode with CQ set to > 31/2. it seems the macroblock quants are wrong somehow, and the frame quants are (more or less) correct.

i tried CQ 17 (number plucked from BV's average frame quant for a 1-passer) and ffdshow was reporting block quants at 34. i wouldn't think that's possible.

[edit]

CQ 20 came out with block quants reported as 40...

dragongodz

28th March 2006, 12:20

i am glad people read this
http://forum.doom9.org/showthread.php?p=805102#post805102

anyway i sort of have it working better, well size wise.
test = small clip at constant quant 17

HC 0.17 = 2.79mb
QuEnc 0.62 old = 1.55mb
QuEnc 0.62 new = 2.45mb

as for mb quants QuEnc encodes both show 34 while HC shows 28 ???

tested HC at quant 20 and it shows 40 ????

result = i will leave the change i just made for now since it seems to me to closer equel expected sizing.

hank315

28th March 2006, 16:54

IMO quants for Quenc and HC are both correct.
The next table shows the difference for Quenc (linear scale) and HC (non-linear scale).
quantiser linear non-linear
0 (forbidden)
1 2 1
2 4 2
3 6 3
4 8 4
5 10 5
6 12 6
7 14 7
8 16 8
9 18 10
10 20 12
11 22 14
12 24 16
13 26 18
14 28 20
15 30 22
16 32 24
17 34 28
18 36 32
19 38 36
20 40 40
21 42 44
22 44 48
23 46 52
24 48 56
25 50 64
26 52 72
27 54 80
28 56 88
29 58 96
30 60 104
31 62 112
The quantizers are written in the bitstream, the choice for linear/non-linear is written in the Picture_coding_extension.
Programs like ffdshow will read both, make the proper conversion and output the linear/non-linear quantizer_scale values.
So Q=17 will show 34 for Quenc and 28 for HC.

dragongodz

30th March 2006, 12:20

my concern was more with the rather huge size difference. however ,as i said, i have reduced that difference so this should no longer(hopefully) be an issue.

tin3tin

8th April 2006, 08:15

Will there be commandline acces to the maxbitrate function in the next release?

Mr_Odwin

8th April 2006, 10:24

There is in 0.61 so I would assume it would stay. For example, -maxbitrate 8000

dragongodz

8th April 2006, 13:40

or from CLI you can just go
QuEnc.exe -?
and see a nice little poppup list of CLI commands. :)

tin3tin

8th April 2006, 14:34

Ehm, I'm sorry. :o I meant 'Auto max bitrate'.

Ebobtron

8th April 2006, 17:56

(maxbitrate = 0) == auto

manolito

9th April 2006, 18:31

Would it be hard to split up the "Interlaced" setting into separate settings for the scan method and for flagging the stream as progressive or interlaced?

Explanation:
Most of my conversions are analog TV captures of Hollywood movies. While the movie itself is purely progressive most of the time, the end credits usually are interlaced. When I encode these clips as progressive, the end credits look really bad (jagginess, jerky movement). Of course I could just encode the whole movie as interlaced, but this is not good for compressibility, and it also is much slower.

For this kind of encodes I get the best results if I encode the whole movie as progressive (zigzag scan), but flag the whole stream as interlaced tff. For reasons I do not completely understand my standalone (PAL Cyberhome 402, connected to a standard CRT TV via SCART) does display a progressive stream differently depending on whether the stream is flagged as interlaced or progressive.

For CCE and HC it is possible to set the scan method and the flags independently, so it would be very nice if QuEnc could also do this. The reason I'm asking is that right now QuEnc (0.62 Alpha5) in 1-pass VBR mode is my encoder of choice. IMHO right now no other encoder beats it in terms of quality vs speed.

Cheers
manolito

DarkFoon

10th April 2006, 00:10

Sounds like a complex feature (as in dumb users might screw something up if they stumble onto it and don't know what it does), which me thinks means it wont get added.

dragongodz

10th April 2006, 03:53

possible to set the scan method and the flags independently
well it was discussed some time ago and concluded that setting the wrong scan order lowered quality. so thats why they are set to the appropriate setting to the encode type automatically.

have you tried just deinterlacing the end credits ? that would seem the easiest solution to me.

note to make the change to flag setting you are suggesting probably means i would have to change it in avcodec and then again every time i wished to update it. as it is the change for pulldown and another experimental change which isnt in alpha 5 already require this. the less i have to change in that way the better. so at the moment i am leaning towards not making that sort of change. i would definatly not count on i for the next release.

Mug Funky

10th April 2006, 04:33

one could always encode the movie and the end credits separately, then join later with their authoring program... this will give you better quality than messing with flags.

"zones" would be useful, but that would possibly complicate the program too much.

manolito

15th April 2006, 13:07

It turned out my problem was not the "Interlaced" flag, it was the TFF flag. For a progressive encode QuEnc does not set the TFF flag which causes my standalone to send out the fields as BFF. Please have a look here: http://forum.doom9.org/showthread.php?p=813844#post813844

Since I am totally unfamiliar with the DVD specs I would like to ask what the correct behavior for an encoder is when encoding as progressive: Should the TFF flag be set (like CCE does) or not (like QuEnc, FreeEnc and HC)?

Cheers
manolito

dragongodz

15th April 2006, 14:19

first off progressive encoding means there are no fields but whole frames. fields are interlaced encoding.

this is sounding very much like the problem discussed here
http://forum.doom9.org/showthread.php?s=&threadid=75923
and here
http://forum.doom9.org/showthread.php?t=80636
please completely read them to understand them.

as for correct behaviour well if you are encoding progressive then field order is totally irrelevant because as i said its not fields. the only exception is when pulldown is being done, as mentioned in those threads, because its being treated mnore like interlaced and fields. note that CCE even has an option called progressive which will do exactly the same as QuEnc and HC etc do. it just defaults to being off all the time.

my advice is to do as already mentioned, encode all as interlaced or deinterlace the credits and encode all as progressive or encode the credits separatly as interlaced and join the footage later.

manolito

15th April 2006, 15:46

first off progressive encoding means there are no fields but whole frames. fields are interlaced encoding.
Yes, I know that. But when my standalone DVD player talks to my standard CRT TV set, it has to disassemble these frames into fields before sending it to the TV. And the order in which these two fields are sent does seem to change according to the TFF flag. For true progressive content this does not matter of course, because the two fields have been shot at the same moment in time, but it does matter if some interlaced stuff happens to be in the stream.
as for correct behaviour well if you are encoding progressive then field order is totally irrelevant because as i said its not fields. the only exception is when pulldown is being done, as mentioned in those threads, because its being treated mnore like interlaced and fields. note that CCE even has an option called progressive which will do exactly the same as QuEnc and HC etc do. it just defaults to being off all the time.
I live in PAL country, so no pulldown is involved here. And for encoding with CCE I actually do set the "Progressive" option. When I analyze this stream with ReStream, it shows that the "Progressive" and the "TFF" flags are set. Streams encoded with QuEnc, FreeEnc and HC also have the "Progressive" flag set, but the "TFF" flag is not set. And only the stream encoded with CCE does not have the jerky vertical movement for the end credits.

And I also do know how to "correctly" encode hybrid content. It's just that I am lazy, and it is not so easy to find out if end credits (where there is no horizontal movement usually) are actually progressive or interlaced. So for me the method of choice is the one that is the fastest and covers all source formats. In my case this means just flagging the whole stream as "TFF" using ReStream. This takes care of the credits while not doing any harm to the main movie, and it also is quite fast.

Cheers
manolito

Mug Funky

16th April 2006, 18:07

it doesn't take long (even for the lazy like me) to open the avs in virtualdub and seek to the end...

FWIW, i'd like to be able to set TFF and progressive. even if it doesn't make sense in a perfect world, there is always a chance that there's interlaced sections that just can'y be found without watching the thing all the way through. in these cases, setting the field-order flag to the correct input field order can mitigate the problem. however, such interlaced frames encoded as progressive will most likely be complete crap to look at - chroma will be mashed and quants will be high, but that might not get noticed on an interlaced screen as much as flipped fields (plus all the other problems) would be.

manolito

16th April 2006, 18:58

it doesn't take long (even for the lazy like me) to open the avs in virtualdub and seek to the end...
True, but if there is no horizontal movement, there will be no combing, even if the source is interlaced.
FWIW, i'd like to be able to set TFF and progressive.
I absolutely second that. Without elaborating too much, I did a couple of tests which show that artifacts from encoding an interlaced source as progressive are much less visible on my standard CRT TV than artifacts caused by flipped fields.

Some other findings from my tests:

CCE 2.67 always flags progressive encodes as TFF

TMPGEnc Plus 2.5xxx flags progressive encodes as Interlaced and TFF

After a quick glance over the QuEnc source code it seems that only one line in the AdvOptionsDlg.cpp has to be commented out to achieve this:
// Only allow TopFieldFirst if interlaced encoding
m_btnTopFieldFirst.EnableWindow(m_bInterlaceEnc);

Maybe DGZ can be talked into modifying QuEnc to let us set the Progressive and TTF flags at the same time, even if it might not be strictly DVD compliant...

Cheers
manolito

dragongodz

17th April 2006, 07:17

And for encoding with CCE I actually do set the "Progressive" option.
i just reinstalled the 2.67 trial version. yes you can set progressive frame flag but it is not possible to set the progressive sequence flag .. at all. where as QuEnc, HC and Tmpgenc 2.54 all set it for for progressive encodes. how weird is that. :)

TMPGEnc Plus 2.5xxx flags progressive encodes as Interlaced and TFF
sorry but 2.54 does not but according to the other thread where you asked about this 2.53 and below did. i just checked that aswell with 2.54 and it did exactly the same as what QuEnc and HC did.
ok i just checked MainConcept aswell, want to guess what it does ? yes it doesnt set TFF either when set to progressive encoding.
so the only encoder mentioned so far(anyone care to test Procoder ?) that does things differently with setting TFF for progressive encoding is CCE.

no pulldown is involved here.
this case is about telling the decoder to treat the stream slightly differently than its been encoded, hence my pointing out the pulldown threads by the way.

Maybe DGZ can be talked into modifying QuEnc to let us set the Progressive and TTF flags at the same time
hmm maybe. thats if avcodec even really will do it. unfortunatly not right now though as i am setting up footage because i am going to run some tests on ... oh cant mention that yet. :D ;)

Mug Funky

17th April 2006, 08:46

True, but if there is no horizontal movement, there will be no combing, even if the source is interlaced.

sure there will be... it'll just look different. interlaced credits are usually easy to spot. combing isn't an exclusively horizontal phenomenon (though it is much harder to deal with when motion is vertical and slow - comb detection often fails because the 2 fields are completely identical and the mismatched frame can actually give lower metrics than the correctly matched frame).

the good news is that if you can't see any combing, it's most likely safe to encode it as progressive... in this case TFF flagging would indeed be useful, but there'd be little to no perceptible difference.

dragongodz

22nd April 2006, 06:42

Maybe DGZ can be talked into modifying QuEnc to let us set the Progressive and TTF flags at the same time
i tested this by the way. no good. it still doesnt flag the TFF so i guess it must have to be changed in libavcodec aswell.

After a quick glance over the QuEnc source code it seems that only one line in the AdvOptionsDlg.cpp has to be commented out to achieve this:
// Only allow TopFieldFirst if interlaced encoding
m_btnTopFieldFirst.EnableWindow(m_bInterlaceEnc);
actually theres 3 or 4 places that needed to be changed. :)

manolito

22nd April 2006, 14:21

Anyways, thanks for testing it. I hope I haven't wasted too much of yor time.

And I still prefer QuEnc 0.62 Alpha5 1-pass VBR over CCE OPV, even if it takes about 10 additional minutes to restream the encode to add the TFF flag.

Cheers
manolito

dragongodz

23rd April 2006, 02:12

I hope I haven't wasted too much of yor time.
no thats ok. it did take a little time to make sure i found all the places that needed changes for it so its abit disapointing it didnt do anything. i wont worry about digging in libavcodec with this version/release as that will take even longer. however in the future, when i do an update of libavcodec, i will probably see what i can find about this.