Log in

View Full Version : QuEnc 0.51 (AVS->M2V/M1V Encoder)


Pages : 1 2 3 4 [5] 6 7 8 9 10

r6d2
30th March 2004, 16:18
Originally posted by DDogg
Also, could you just mention the point about the desire for decimal quants to the ffmpeg guy/s for consideration? I figure you must have a line into them. Of course, no problem if that is not feasible. AFAIK, quantization values are integer in nature. They reflect the scaling that is done to the signal to make it fit into less bits. The fact that some MPEG-4 encoders support non integer quants has to do with a sort of average calculated on a per GOP basis, but block by block, quantization is always integer.

This procedure could be imitated with an MPEG-2 encoder, I think, but I don't know if it would be simple to do.

bilu
31st March 2004, 18:16
Originally posted by Amenophis
:vratetol=1835: the tolerance of the rate control algorithm. a low value will 'smooth' the bitrate-curve, while a high value will lead to a lot of ups and downs. this value seems to be ok

:vrc_buf_size=1835: buffer size for dvd (=224*8*1.024) for svcd it should be 917.
@Amenophis

Any particular reason for setting vratetol=vrc_buf_size?
I think VBV specifies the maximum bitrate variation, someone please correct me if I'm wrong. So smaller variations should be compatible too. Probably even vratetol=0 is a good value.

I have to play with this parameter, never played with it before :)


Bilu

Amenophis
1st April 2004, 02:06
Originally posted by bilu
@Amenophis

Any particular reason for setting vratetol=vrc_buf_size?
I think VBV specifies the maximum bitrate variation, someone please correct me if I'm wrong. So smaller variations should be compatible too. Probably even vratetol=0 is a good value.


No, there's no reason for taking exactly the same value for vratetol. Nevertheless a value between 1500 and 2000 seems to be ok. When using 5000 or even 8000, Scenarist didn't like my files anymore, but the 1835 seems to work, so i thought 'never touch a running system'.

bilu
1st April 2004, 12:11
FFMPEG
=====
`-b bitrate'
set the video bitrate in kbit/s (default = 200 kb/s)
`-bt tolerance'
set video bitrate tolerance (in kbit/s)
`-maxrate bitrate'
set max video bitrate tolerance (in kbit/s)
`-minrate bitrate'
set min video bitrate tolerance (in kbit/s)
`-bufsize size'
set ratecontrol buffere size (in kbit)

Mencoder
======
vratetol=<value>
approximated filesize tolerance in kBit. 1000?100000 is a sane range. (warning: 1kBit = 1000 Bits) (default: 8000)

vrc_buf_size=<value>
buffer size in kbit (pass 1/2). For MPEG1/2 this also sets the vbv buffer size, use 327 for VCD, 917 for SVCD and 1835 for DVD. NOTE: vratetol should not be too large during the second pass or there might be problems if vrc_(min|max)rate is used
By crossing docs between FFMPEG and Mencoder I got to the conclusion that vratetol(-bt), much more than the vqcomp(-qcomp) or vrc_eq(-rc_eq) settings, is the parameter that will let enforce the average bitrate behaviour.

Lowering vratetol(-bt) will make the filesize much more predictable, but it will still be VBR encoding, not CBR as if vrc_minrate=vrc_maxrate (-minrate=-maxrate).

Would like your feedback on this.


Bilu

Nic
1st April 2004, 13:29
@bilu:

That's very correct (to a certain extent). However, it's deciding the size of bit tolerance. Narrow it too much, and you get deadly accuracy, but almost a CBR stream. Start increasing it even a little, you get VBR (but only slightly) and already have filesize out. I think, I've got it balanced ok though in the next release.

Also there is a problem in the ratecontrol, where the bitrate starts out massive (and then falls down). Although, I've fixed that (kind of ;) ) in ratecontrol.c. Ill release a new version when I have some more time...

-Nic

bilu
1st April 2004, 14:02
Originally posted by Nic
Also there is a problem in the ratecontrol, where the bitrate starts out massive (and then falls down). Although, I've fixed that (kind of ;) ) in ratecontrol.c. Ill release a new version when I have some more time...

-Nic

Will you post your fix at ffmpeg-devel mailing list? ;)


Bilu

micattac
1st April 2004, 15:38
Just wanted to let you know: great work. Just finished doing a custom VBR SVCD and it worked quite good.

I used Version 0.43
Max Bitrate was 3070000 instead of the expected 2400000 bps, but as I read above, that problem will be taken care of
Picture is crips, sound with toolame is good too.

I like it.

Is there any better way to mux than to use bbmpeg?

Cheers
MicAttAck

Nic
1st April 2004, 16:40
@micattac: I get asked this alot...might add some basic muxing like in ReJig to QuEnc (using mplex). You could try mplex...I think you can find an executable for it in the dvdauthor package (and elsewhere). Try dvdauthor.sf.net

@bilu: Isn't really a fix...far more like a hack ;) Trust me, they, wouldnt want it.lol

micattac
2nd April 2004, 16:08
dvdauthor? haven't thought about that, will look into it.

How about a little feature request. Can you make a CLI switch to set the taskpriority (like "-prio idle")

btw. I am getting this dubious error

[quenc_error.JPG] (http://members.yline.com/~micattack/quenc_error.JPG)

When encoding with e.g this commandline:

D:\Video\quenctest>QuEnc.exe -i "e04.avs" -o e04.m2v -b 1092 -2 -aspectratio "4:3" -auto -close

I think on my System I always get it? I am running XP Pro German with all patches and Norton Antivirus.

HarryM
6th April 2004, 08:57
"Pulsation" is back! :mad:
I used Quenc with DVD Rebuilder and observe any noticeable pulsation...

lithoc
10th April 2004, 01:11
Are we getting a newer version of QuEnc? :(

Axlemar
10th April 2004, 01:14
;

BruceL
10th April 2004, 21:46
Are we getting a newer version of QuEnc?

Doesn't sound like much of a motivational request.

Perhaps a message such as "Nice work Nic, appreciate your hard work. Have you found time in your busy schedule to make any advancements? Please let us know as we anxiously await any updates you would be willing to SHARE with us."

PS Thanks for a terrific new tool Nic. I have been following this thread, but have just recently found the time to try.

HarryM
11th April 2004, 09:27
Originally posted by lithoc
Are we getting a newer version of QuEnc? :(

All is O.K. now.
I forget to erase a old Quenc's registry entries (from old version). :p

dragongodz
11th April 2004, 12:30
Nic is busy at the moment. just little things like work, real life and unreal tournamount. :)

he has already said though that he will continue to work on QuEnc and Rejig so patience my freinds. its easter so enjoy and let Nic do the same. :D

djan
11th April 2004, 15:56
Originally posted by dragongodz
Nic is busy at the moment. just little things like work, real life and unreal tournamount. :)

he has already said though that he will continue to work on QuEnc and Rejig so patience my freinds. its easter so enjoy and let Nic do the same. :D And Championship Manager ;)

TheXung
12th April 2004, 04:19
Forgive me for not remembering all that was said in this thread but I was wondering if anyone else has run into the following problem.

A 7 min video clip avs loads perfectly fine in Virtual dub. When QuEnc encodes it, the file seems to be parsed fine as well in the sense that all the frames get encoded and are in the output file. However, it's like the time stamps are incorrect or so because every player thinks it's only a 1:17 min clip. It plays at normal speed, it just continues playing after the status bar reaches 1:17. There's also a problem that only 1:17 minutes of bits at the set bitrate were used for the video.

This was with QuEnc .45 and the movie was Fightclub (NSTC)

To be clearer, all the segments of the whole movie exhibited this problem of being percieved as too short.

DMagic1
14th April 2004, 01:11
Finally got around to trying this. I'm very pleased with the results. I tested this with Fellowship and got results that were better than I excepted.

DMagic1
14th April 2004, 18:06
Nic there seems to be a problem with QuEnc and very small video files. Problem appears when using a avs that creates a m2v thats only about 1 frame. QuEnc creates a m2v thats unplayable and is only 4 bytes in size.

vlada
14th April 2004, 20:33
Hello,
thanks for the great program. It's small simple and produces good quality. But shouldn't there be a switch for interlaced source? It seems to me, that the program treats all movies as progressive. Also the aspect ratio 1:2.35 (or 2.33?) should be added, maybe instead of 2:2.1. And the last question: Are there somewhere the different parametrs explained? Thank You, Jech

Fl0ppy
15th April 2004, 23:15
@Nic: Where i can found the sources of this program? I want to add a new version of libavcodec (ffmpeg)

G00d work

wmansir
17th April 2004, 06:49
I haven't used QuEnc, but I plan to try it out soon. My post is concerning the DVD-Rebuilder Settings guide. As you may know jdobbs added the following options for QuEnc at a user's request. I added the following to the Settings guide based on some quick searches on the subjects:

QuEnc Options
Trellis Quantization
A encoder option that improves quality, but nearly doubles encoding time.
KVCD "Notch" Matrix
The KVD "Notch" Matrix is optimized for space/quality, and to reduce artifacts on low lit/dark scenes. Some image detail is effected though, so it is only recommended if you are using a low video bitrate. Check here (http://www.kvcd.org/portal/articles.php?lng=en&pg=20&prt=1) for the specifications.

If that is in any way incorrect, or you have some more details to add, please let me know. I would specifically be interested in how much of an improvement Trellis quant makes, and how much it slows encoding. (I said doubles encoding based on jdobbs' comments, is that accurate?)

Thanks.

JDay
17th April 2004, 09:52
On my (embarassinly slow) machine, Trellis Quant reduces the encoding speed from abot 14 fps to 9. Quality looks slightly better to my eye, but I haven't thoroughly compared the results.

DMagic1
17th April 2004, 18:01
I didnt see any improvements with Trellis. It took my encode from 330mins to 530mins. The main problem I still see is in the dark areas. Lots of blocks. I'm going to try the KVCD that is suppose to help dark areas. I wondering how much detail lose were're talking?

Amnon82
19th April 2004, 11:55
Is there a way uncheck all settings in QuEnc for batchencoding?
In my batch I set for each encode the settings.

is there a swich for VBR and HQ?

DMagic1
19th April 2004, 15:55
Just wondering what happens when Trellis and KVCD are checked?

Wimpy
19th April 2004, 23:11
Hi Nic,

I am feeling much love for QuEnc and have been using it for encoding my scuba diving shoots for a home made DVD, with great results considering the footage was shot underwater :-) I have also tested it in conjunction with DVD-Rebuilder and have also been very impressed with the output.

I am not trying to be a git and nor do I expect anything, but... I was just curious if you have a status update for us on the new version of QuEnc? The only 'issue' I am having is undersized encodes making it difficult to accurately fill my DVD with quality aquatic loviness :-)

Anyway, thanks for a funky encoder and I look forward to what the future may hold!

dapipa
21st April 2004, 10:27
Originally posted by DMagic1
Just wondering what happens when Trellis and KVCD are checked?

now that's what i want to know too...

Nic
21st April 2004, 12:32
I can't be sure exactly...It will work, i.e. dct_quantize_trellis will use the KVCD matrix, but if it will produce a good result or not I don't know. But I would have thought so.
Trellis definitely improves the encoding, but maybe it isn't worth using due to the slow down....

-Nic

dragongodz
22nd April 2004, 13:41
Nic - since you have made trellis selectable whether to use or not people can try it for themselves and decide. :)

jeffoz1
23rd April 2004, 03:07
I really like the speed of QuEnc and its simplicity. I've had some probs muxing the m2v with an AC3 in DVDLab but I think it is more to do with the AC3. The thing I noticed however was that DVDLab's bitrate viewer showed the m2V occasionally peaking at 13,000kb/s. I had the bitrate set at 3000 kb/s in QuEnc. Should this be happening?

Nic
23rd April 2004, 10:08
Does it only peak at that start of the M2V? If so that's a bug, which can be fixed in the next version. It shouldn't cause much of an issue, but it is a bug in libavcodec where the bitrate starts off very high before settling.

-Nic

jeffoz1
23rd April 2004, 11:38
This may have been a false alarm Nic. The bitrate viewer I applied was to the file after pulldown which bumps up the bitrate considerably. However, the .mv2 direct from Quenc (fps=23.976) spiked at the very end to only 9,900kb/s. Interestingly, since it is the pulldown file that gets authored, should the DVD standard apply to this file? If so 13Mb/s will exceed it? Sorry for my ignorance.

jeffoz1
24th April 2004, 04:53
Both DVDLab and VOBEdit had a problem with muxing the pulldown m2v file and stopped compiling towards the end. When I trimmed the last few seconds which had the 13Mb/s spike, it compiled no problem. So it is thing to watch for progressive NTSC. Let me know if I am missing something.

Nic
25th April 2004, 14:35
http://nic.dnsalias.com/QuEnc.exe

An update at last ;)

Changes:


Now has "extreme" options, mainly for my own testing, but should provide quality over speed

New Command line options for turning options off as well as on ;)
( view with QuEnc /? )

Now "should" have interlaced encoding for encoding interlaced material.

Now "should" have better bitrate control...hopefully it won't have huge undersize/oversize problems.


Hasn't had full testing yet, but should be an improvement. Please let me know of anything I've missed.

Cheers,
-Nic

Paced
25th April 2004, 14:44
Originally posted by Nic
http://nic.dnsalias.com/QuEnc.exe

An update at last ;)

Changes:


Now has "extreme" options, mainly for my own testing, but should provide quality over speed

New Command line options for turning options off as well as on ;)
( view with QuEnc /? )

Now "should" have interlaced encoding for encoding interlaced material.

Now "should" have better bitrate control...hopefully it won't have huge undersize/oversize problems.


Hasn't had full testing yet, but should be an improvement. Please let me know of anything I've missed.

Cheers,
-Nic

Thanks Nic; just ran a few tests, and it is 110% more accurate (at hitting the correct file size) than 0.45 was - at least for me anyway. Great job as always :D

//Edit

After more tests, it appears that QuEnc has much better accuracy when "Extreme & Slow Settings" is ticked. When I have it off, QuEnc seems to be oversizing the output (not by much, for example, the bitrate I set was 3250, the output turned out to be 3350).

//Edit 2

Actually, I take that back, for some strange reason it's dead on accurate now - after I rebooted my computer.

JDay
25th April 2004, 15:22
Just ran a test on some interlaced material, and it turned out great. Thanks Nic! However, I still ran into problems when trying to encode a single-frame avs. It creates a 4k file that (needless to say) cannot be played back. That may or may not be an improvement over 0.45 which made 0k files ;).

Nic
25th April 2004, 15:36
@JDay: Set B-Frames to 0. Then it will work. Although quality of such a bit of video will be low, (as libavcodec's ratecontrol needs time to settle and normally ruins the first frame a little :( )

JDay
25th April 2004, 16:35
I tried encoding several very short clips with and without b-frames. With 2 b-frames enabled, and they all came up a few frames short: (avsframes->encodedframes) 1->X, 2->X, 3->1, 50->47, 100->97, 1000->997, 10000->9999. These all encoded with the correct number of frames when b-frames were set to 0.

jdobbs
25th April 2004, 16:44
Originally posted by JDay
I tried encoding several very short clips with and without b-frames. With 2 b-frames enabled, and they all came up a few frames short: (avsframes->encodedframes) 1->X, 2->X, 3->1, 50->47, 100->97, 1000->997, 10000->9999. These all encoded with the correct number of frames when b-frames were set to 0. So where is the line? At what point (in numbers of frames) should b-frames be set to 0?

dragongodz
25th April 2004, 17:14
JDay - can you give more information about your source ? is it interlaced ? if yes then are you deinterlacing and how exactly ? what did you use to determine the amount of frames ? that kind of thing.

Nic
25th April 2004, 17:21
Well spotted JDay :)

http://nic.dnsalias.com/QuEnc.exe

Fixed: Not encoding the correct number of frames when using B-Frames.

-Nic

ps
Bug: "Interlaced Encoding" May not work with MPEG-1. Works fine with MPEG-2 so far in testing...

JDay
25th April 2004, 17:46
Wow, that was fast. Works perfectly now, including single frame clips! Thanks!

Edit: Another thing: not a big deal since I'd never turn these off, but -(no)vbr and -(no)hq don't seem to be available via command line (or if they are, they aren't referenced in the "/?" screen and don't go by that syntax).

LigH
25th April 2004, 22:22
In my opinion, interlaced encoding was not written into the MPEG-1 specs, field based encoding is not supported before MPEG-2. Or was I wrong here?!

APF_Gandalf
25th April 2004, 22:29
It seems that treillis is giving me "inverted blocks" since 0.46.

settings:
video 640~432 (always the same anime episode from NTSC Z2 DVD)
mpeg2
bitrate: 1200 ->> and I'm getting ~210 MB for a 25 minutes episode.
VBR
HQ
Treillis
2 pass
KVCD Notcch matrix
Gop size 12
2 max B-frames
16/9 aspect ratio
"Extreme & slow settings" on and off
-already tested with and without it since I was testing with it the first time these blocks appeared.

I'm trying without treillis and with "Extreme & slow settings" right now. I'll update un a few minutes since it encodes at about 40 fps.

/Edit
the inverted blocks are there even without treillis and with "Extreme & slow settings".
without the 2 of them, it's ok.
/end of edit

/edit2
ok, I think I found the culprit: when desactivating the KVCD matrix, I can use treillis and/or "Extreme & slow settings" without any problem in Quenc 0.47.
/end of edit2

I'm also getting the same problem as TheXung:
Originally posted by TheXung
Forgive me for not remembering all that was said in this thread but I was wondering if anyone else has run into the following problem.
It plays at normal speed, it just continues playing after the status bar reaches 1:17.


I haven't tried to remux video yet, maybe it'll solve the problem.

jorel
26th April 2004, 02:01
@ nic
first, thanks for the new version, great work ! :)

audioslave did some tests comparing quality from Mencode-me 0.21, QuEnc 0.47 and TMPGEnc 2.521.

the pictures:
http://hea.port5.com/Comparisons/Comparisons.htm

and audioslave posted:
Quality wise, QuEnc has the best looking sample - except for the color screw-up - with less artefacts (gibbs) than the other two samples.

nic, we all know that your target is to encrease the QuENC quality more and more, that tests can help a little.
if you want to see all details, please read the first post here:
http://kvcd.net/forum/viewtopic.php?p=75525#75525

regards!
:)

dragongodz
26th April 2004, 06:34
the blue tint problem is easily fixed.

when using an avi source dont use AviSource() with avisynth but DirectShowSource(). you should now find the colours are normal.


LigH - yes mpeg1 was originally designed for just progressive encoding but i think you will find most encoders can output interlaced mpeg1 nowdays. whether you use it or not depends on your intended purpose and playback format/device.

jorel
26th April 2004, 07:40
Originally posted by dragongodz
the blue tint problem is easily fixed.

when using an avi source dont use AviSource() with avisynth but DirectShowSource(). you should now find the colours are normal.


thanks for that dragongodz.

i don't encode avis,divx/xvid, only encode from dvds sources (cartoons and musicals) then i don't need to use DirectShowSource(), right?
i did 2 cartoons and the colors (everything) is ok!
do you have some recomendations for mpeg2source("D:\cartoons\??.D2V")
using .avs script in QuENC to encrease the quality?

all hints are welcome,thanks in advance!

JDay
26th April 2004, 08:30
I encoded R1 Barton Fink using QuEnc (and DVD-RB) and was quite impressed. Granted, this isn't the most difficult movie to encode (low motion, largely monochrome), but it turned out quite well. The differences I noticed, was that the the QuEnc output was slighty lighter than the original and that the borders between different shades was more abrupt, since the original used dithering in these areas (this can be seen on the ceiling in the second picture). So, here are some comparisons of the original avs to the QuEnc output.

First frame: Original (http://apotheosis.tv/files/avs1.png)|QuEnc (http://apotheosis.tv/files/quenc1.png)
Second frame: Original (http://apotheosis.tv/files/avs2.png)|QuEnc (http://apotheosis.tv/files/quenc2.png)

Nic
26th April 2004, 09:46
@LigH: You are right. Forgot about that! No wonder interlaced encoding doesn't work with MPEG-1 ;)

@JDay: They reported a slight color problem in kvcd.net with mencoder and QuEnc. Must be a libavcodec, ill try and see if there is a work around.

@Jorel: Thanks for the feedback :)

@APF_Gandalf: Extreme settings automatically turn on Trellis even if you have selected it off. So basically, Trellis and KVCD aren't compatible in libavcodec at present (it seems, although I didnt see the problem when testing). Ill see what I can do.
EDIT: I can't replicate this problem. The files I create with those settings don't display these blocks... ?

I'm also working on adding higher than 8 bit DC precision to libavcodec, but it's not very straightforward...

-Nic