QuEnc 0.72

[MrC]

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]

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]

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]

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]

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]

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]

Thank You.

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

[manolito]

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]

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]

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]

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]

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]

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]

@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]

CQ in TMPGEnc means constant quality, not constant quantization.

[Tdr]

@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]

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]

@Boulder

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

[cobo]

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]

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?

[MrC]

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]

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]

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]

Ok, do you know why ?

[cobo]

No, I don't know why.

[Darksoul71]

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.

[suburbanDK]

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]

@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]

@DGZ

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

Thanks in advance

;)

Bye

[45tripp]

ahh,
and possibly a pulldown switch in cli

[Fallen]

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]

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]

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

[Darksoul71]

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]

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]

thanks guys. your thoughts are appreciated.

[Yobbo]

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]

^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]

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]

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]

^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]

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

[Midzuki]

@Boulder

in extenuation of my Person, just have a look at Nuenc 0.21

Where can we find Nuenc 0.21 today ? :confused:

{

0.01b is easy:

www.64k.it/andres/dettaglio.php?sez=n

}

[manolito]

Where can we find Nuenc 0.21 today ? :confused:
Here:

Cheers
manolito

[Midzuki]

Here:
http://scifi.pages.at/manolito/Nuenc/NuEnc_021.zip

Cheers
manolito

1,000,000 :thanks:

[dragongodz]

MrC - some of those are already on the list. just a decision to best expose and use additions etc.

manolito - i will have to look at that later and see.

Gromozeka - another thing to look at later.

[Gromozeka]

Gromozeka - another thing to look at later.
:thanks:
VAQ economy 10%-15% - best thing

[MilesAhead]

Here:
http://scifi.pages.at/manolito/Nuenc/NuEnc_021.zip

Cheers
manolito

I get a 404 error on that link.

[manolito]

I had no intention to host NuEnc permanently.
Grab it here:

http://www.sendspace.com/file/0oxd51


Cheers
Manolito

[MilesAhead]

I had no intention to host NuEnc permanently.
Grab it here:

http://www.sendspace.com/file/0oxd51


Cheers
Manolito

Thanks. Just curious to check it out. :)