QuEnc 0.55 [Alpha]

[Peter Cheat]

The VBV buffer underflow treatment is sort of like what I have done (same concept, different implementation). It's good, but slow too (for loop within for loop within for loop isn't nice!). VHQ for b-frames would be very good. Anyone game enough to try implementing that into ffmpeg? The only thing I could have a go at porting to ffmpeg are the optimised sad compare functions to speed up encoding. I'll have another (really good) look at the current xvidcore and see if I can put this rate control into ffmpeg.

@dragongodz or koepi
What are the major advatages of xvid's current rate control over its previous rate control, and the method used in ffmpeg? In my modifications I fixed the small I big B problem. Maybe my scaling is a bit slow, but it targets filesizes well (probably better than original ffmpeg as I am not using "bitrate tolerance" parameter).

@fabrice
Put your mouse over the save symbol. It will show the matrix being used. (Clicking on it will let you save it). "Standard" means you want to change to the standard matrix (a bad idea if you didn't encode with the standard matrix).

[fabrice]

Hi,

@Peter cheat: I know that. It's only that qenc don't use a custom matrix, because I was doing something wrong:

According to qenc source (file avsenc.cpp), the "use QLB matrix" checkbox have to be checked to use a custom matrix file.
So the correct sequence to use a custom matrix is first check the checkbox, and then choose the matrix file... (I was only choosing the matrix file).

Don't seem logical, don't it? I think (but I could be wrong) that it would be more logical using a custom matrix if the filename is present (wihtout looking for checkbox) , and use the qlb matrix if the chechbox is checked...

Thanks,
Fabrice

[Peter Cheat]

You are correct. This is a little bug (or maybe the box should say "choose custom matrix" and default to QLB). Not hard to fix.

[Nic]

Well spotted Fabrice :) I forgot about that. :) Should just be a if ( csMatrixFile.IsEmpty() == FALSE ) for the matrix file thing...I'll revise that in the next release.

My girlfriend is disappearing off to Cuba for 2 weeks, so should be able to get lots done after this weekend.

Keep the suggestions, tips, bugs, etc coming :)

-Nic

[damian_dimitri]

small question;

are quenc's settign stored in the registry?
Just asking because i had 2 quencs on my hdd and they seem to have the same settings afther i changed one.
IS it possible to put the settings in a *ini file instead of the registry?

no big deal...just curious


Damian

[dragongodz]

What are the major advatages of xvid's current rate control over its previous rate control, and the method used in ffmpeg?
xvids old rate control could spike like crazy. as expected giving very good quality to scenes that need it. it is however not exactly hardware player freindly such as with divx profiles which a lot of players use/support.

there are some reports about(and the other options) it mixed in here
http://forum.doom9.org/showthread.php?threadid=84039

also here is a bit from when gruel first commited the VBV code
http://list.xvid.org/pipermail/xvid-devel/2004-June/004310.html

to get the 1.1 branch you need to do a cvs checkout of course.

[Nic]

@damian: Yes they are held in the registry (local_machine\software\QuEnc). I really dislike .ini files, so I doubt i'll support them. But maybe I'll come up with another solution.

-Nic

[damian_dimitri]

hi Nic,

don't worry...i can (or must..lol) live with it.
Love your tool..so it is eassy to accept.
I was just curious

have a good night

Damian

[Peter Cheat]

Originally posted by dragongodz
xvids old rate control could spike like crazy. as expected giving very good quality to scenes that need it. it is however not exactly hardware player freindly such as with divx profiles which a lot of players use/support.

Understood. But the new changes check for VBV underflow while initial scaling, and not again (should really be checked again just before encoding to make sure...)

Originally posted by dragongodz

there are some reports about(and the other options) it mixed in here
http://forum.doom9.org/showthread.php?threadid=84039

Ok thanks.

Originally posted by dragongodz

also here is a bit from when gruel first commited the VBV code
http://list.xvid.org/pipermail/xvid-devel/2004-June/004310.html

Ok. As I said above, another check would probably be necessary to be absolutely sure that VBV will be ok, but I haven't tested this so maybe it is not a problem.

Originally posted by dragongodz

to get the 1.1 branch you need to do a cvs checkout of course.
I've done this and have started to convert it over to ffmpeg. This is going to take some time, and I'm not sure it will work well. Especially the assymetric curve compression, I tried this already a while back and the result was poor (those who gave feedback confirmed this). Give me a few days on this one, and we'll see how it comes out.

[dragongodz]

As I said above, another check would probably be necessary to be absolutely sure that VBV will be ok, but I haven't tested this so maybe it is not a problem.
possibly it will or should need another check. its still relativly new code so really needs much more testing to be tweaked and refined. the stricter scaling option may help aswell. unfortunatly reports of results are limited thus far but thats generally true of most programs. people like to use them but 99% dont want to report findings, just "it doesnt work".

This is going to take some time, and I'm not sure it will work well.
at the very least it may help give you ideas how to improve/speedup/whatever your own code. so worth investigating at least.

[Amnon82]

@fabrice: You can use the external matrices by checking QLB and then open Your Matrix.txt. Then the QLB-Checkbox will get grayed and QuEnc uses Your Matrix.

@Nic: Can't wait for Your next release ;)

[Nic]

The code is coming along quite nicely...Might get it finished tonight, depending on how I feel. :)

At present it will work like this: if given an AVS File that has no audio it will work the same as it does now. If it does have audio then it will encode the video and audio together into a system or program stream (depending on whether it's MPEG-1 or MPEG-2 respectively).
(I suppose I should also make it if it just has audio, only encode a raw audio stream)

The strange thing is, now I've written this code, it makes it very very easy for QuEnc to be an AVS->[Any format ffmpeg supports] type app. Rather than just a MPEG-1/MPEG-2 encoder. But I'm not sure quite what to do with/about that yet.

Let me know your opinions on how you think I should design it....

Cheers,
-Nic

ps
Might release two versions with the next release, one as a standard libavcodec release and one as a Peter Cheat modified libavcodec. So we can contrast and compare. etc :)

[dragongodz]

makes it very very easy for QuEnc to be an AVS->[Any format ffmpeg supports] type app. Rather than just a MPEG-1/MPEG-2 encoder. But I'm not sure quite what to do with/about that yet.
i personally would rather see all the mpeg encoding(including audio) done before worrying about any other output types. we could probably branch other than mpeg to a different program later down the line. so QuEnc = mpeg encoder and ????? = other types encoder.

[damian_dimitri]

hope you feel well to night
I can rub your back... :D jk :p

looking forward to your release

damian

[Mug Funky]

hmm... any ffmpeg codec. that would be pretty cool, but would break the simple and rather elegant interface that QuEnc has. also it would mean having to allow all those extra options that would probably break encodes.

a separate app would be interesting, but there's always ffdshow for that.

there's definitely more of a need for a CCE killer than an ffmpeg GUI. people still work in MPEG-2 for now. i say keep it as it is.

[rambling] it would be kinda cool to see something similar to LAME's --preset standard et al for ffmpeg. that's probably something for the ffmpeg devs to decide. it'd also need some rigourous testing to determine good settings at each quality level. a program with so so many options and not-so-great explanations as to what they all do needs a good set of presets (it's nigh-on impossible to explain the complexities of so many codecs in a simple manual, especially in a way that n00bs will actually understand).

then we could all say to n00bs "use the presets!".

[dragongodz]

a separate app would be interesting, but there's always ffdshow for that.
Ffdshow is only a codec though and if i am reading Nic right he means not only the codecs but output format(as in containers) aswell. yes you could do some things like that using Ffdshow with VirtualdubMod for example(as in different output containers). still it is interesting for a seperate program.

would break the simple and rather elegant interface that QuEnc has. also it would mean having to allow all those extra options that would probably break encodes.
agree 100%. thats why i also said i would prefer to keep QuEnc mpeg 1/2 only. :)

[Peter Cheat]

Definately keep it as MPEG1/2 only for now. Adding other codecs will only add problems, and besides, the other codecs in ffmpeg are not that great (ffmpeg MPEG-4 vs. XviD, you all know which is the better of the two). The new Snw codec might be interesting but it is still under development and probably very dodgy atm. Keep with what we know for now.

btw Nic, if you want my modified sources send me a PM for the latest. I make changes almost daily :D.

My next release NuEnc (coming out tomorrow maybe) was going to have both rate controls available (user chooses old or modified). I'm not sure I'll have time to throw it in, and might be no point if Nic will make two versions.

[Nic]

Ok, I've kept it pure MPEG-1/MPEG-2. It all works well...It's all finished, but want to test it more first.

Also has the option of loading in Wav and AVI files as input (all this does is create a temporary AVS file with WavSource or AVISource and loads that instead). It supports both AC3 and MP2 (although I don't know if it will work with channels >2...I doubt it will)

Cheers,
-Nic

ps
I've PM'd you Peter. :)