QuEnc 0.54 released

[dragongodz]

this is the official QuEnc 0.54 release.

its released under the GPL so if you dont like that... dont use it. :devil:

changes 0.52 -
.some more tweaking to settings.
.added pass text on main window.
.notch matrix completely replaced by QLB(Quenc Lower Bitrate) matrix.
.the kvcd cli commands replaced with QLB ones.

changes 0.53 -
.properly replace notch matrix.
.minor tweaks.

changes 0.54 -
.aspect ratio should be working properly now ;)
.bad parameter window tells you what the bad one was now
.version of exe changed to 0,0,5,4 so jdobbs can pick it in DVD-RB :)
.dll version is cvs 12th july as reccomended over 0.49pre1, found on ffmpeg homepage

.QLB commands changed to cmatrix and nocmatrix (custom matrix) in the -? but not actual command line yet.

0.54 is compatible with DVD-RB 0.57.

i do ask that if you do any modified releases please identify them as such and not up QuEncs number. meaning please dont change a few things and release QuEnc 0.55 etc. i got permission from Nic to bump the version and it would save a lot of confusion if others didnt do so without asking him aswell first.
also if you change the matrix please say it in your release. one of the reasons notch matrix was removed was because it has big problems with trellis being used. i have no interest in answering questions about problems caused by other peoples changes.

i put a text in with the source giving a quick guide on how to compile it. Nic has already warned before that neither he nor i will have the time to go in to detail on compiling it but that should get you well started.

neither Nic or i will be working on this for awhile since avcodec really needs the rate control fixed for it to work 100% properly and we do have other things we want to do.

downloads found at
http://www.pcpages.com/dragongodz2/

mirrors are of course welcome. :D

[Doom9]

here's another download link: http://www.doom9.org/Soft21/Encoders/MPEG2/QuEnc052.zip

[glänzend]

notch matrix completely replaced by QLB(Quenc Lower Bitrate) matrix.

Please correct me if I'm wrong, but after looking at a small encoded clip we just made with your new version of QuEnc, we confirm that the resulting file was created with the KVCD notch matrix tables. :confused: This was also re confirmed by looking at YOUR source code. :confused: :confused:


The following code segment shows clearly the KVCD notch matrix tables:


// dragongodz - brand new custom lower bitrate matrix especially for
QuEnc :)
if ( bUseQLB )
{
CString csQLBIntra = CString("8 9 12 22 26 27 29 34 ")
+("9 10 14 26 27 29 34 37 ")
+("12 14 18 27 29 34 37 38 ")
+("22 26 27 31 36 37 38 40 ")
+("26 27 29 36 39 38 40 48 ")
+("27 29 34 37 38 40 48 58 ")
+("29 34 37 38 40 48 58 69 ")
+("34 37 38 40 48 58 69 79 ");

CString csQLBNonIntra=CString("16 18 20 22 24 26 28 30 ")
+("18 20 22 24 26 28 30 32 ")
+("20 22 24 26 28 30 32 34 ")
+("22 24 26 30 32 32 34 36 ")
+("24 26 28 32 34 34 36 38 ")
+("26 28 30 32 34 36 38 40 ")
+("28 30 32 34 36 38 42 42 ")
+("30 32 34 36 38 40 42 44 ");


pIntraMatrix = (unsigned short*) av_malloc(1000);
pNonIntraMatrix = (unsigned short*) av_malloc(1000);

parse_matrix_coeffs(pIntraMatrix, csQLBIntra);
parse_matrix_coeffs(pNonIntraMatrix, csQLBNonIntra);

c->intra_matrix = pIntraMatrix;
c->inter_matrix = pNonIntraMatrix;
}

Please either give the proper credit due, (there is no problem with that? is there? ;) ) or just remove it and create your own.
ciao
glänzend

[audioslave]

Yep, glänzend, you're right. The so called QLB Matrix IS the KVCD Notch Matrix. :rolleyes:

glänzend wrote:
Please either give the proper credit due, (there is no problem with that? is there? ) or just remove it and create your own.

I totally agree!

Other than that... Thanks for another great release of QuEnc! :)

[dragongodz]

jeez and why dont you guys try giving some credit in return ?

it was an honest mistake when i was cleaning it all up for a clean release. that is i went back over the 0.51 files and made the changes and the matrix accidently didnt get replaced.

i have no interest in taking credit or "stealing" the notch matrix. the fact the source code is there for anyone to check and the fact i have remedied the problem as soon as i have found out(its morning here, couldnt do it in my sleep :) ) should be the proof anyone needs.

[Paced]

Thanks for the new release + hard work dragongodz / Nic, I'm sure it's appreciated by many.

[dragongodz]

thanks Paced. its nice to get a thank you every now and then. :)

Nics working on mpegdecoder.dll(in avisynth forum) and i am working on some other things. so this is the last version for awhile.

[dragongodz]

a quick note about first frames and aspect ratio.

using MediaPlayerClassic's internal mpeg2 decoding aspect ratio is show correct. first frames with high quant(produced by 1 pass and not 2 pass) can show some blocks.
using intervideos mpeg2 decoding through MPC however the aspect ratio was not shown(did 1:1 no matter what aspect the video was) but no blocks for those first frames were obvious either.
using Windvd to play the files had aspect ratio shown correctly and showed no obvious blocks.

fun with pcs. :D

[vmesquita]

About the "keeps increasing the memory usage till there's no memory left yet" thing we were discussing at the FreeEnc thread.
I tried with no filters (just resizing) and still the same result:

Avisource("movie.avi",false)
bicubicresize(704,480)

It's really funny how it behaves differently in different machines... Same thing with FreeEnc. :D

[dragongodz]

hmm ok could you try the same using directshowsource() and see if that does it aswell ?

actually i do know there is 1 problem with using avisource() and QuEnc, no 2 pass encoding. first pass works but second pass gives an error(no yv12 data being sent or such).

hmm i did also turn on the mem align hack for that dll compile so its possible that could have an effect. it shouldnt really as its actually meant to be good for windows.

[vmesquita]

Hi dragongodz,

I tried with DirectShowSource and a very interesting thing happened. I use ffdshow, and it puts that small icon on the taskbar. Well, many icons started popping up, like if QuEnc were opening the scripts in many instances. :confused: And of course the memory usage increased, and increased...
I have a Windows2000 VMWare virtual machine that I set up with only the basic stuff to test FreeEnc crashes, I'll give it a try and let you know.

EDIT:
It worked fine in my w2000 virtual machine. It must be something wrong here.
Also it's good to know you used the hack, I am confident that will fix the crashes in FreeEnc. :D

[dragongodz]

wow that is strange. QuEnc only opens the avs once but maybe they are popping up with each get of a new frame. that sounds more like an avisynth or ffdshow problem and since its ffdshow that keeps reappearing i suspect thats the problem. maybe trying a different version would fix that or changing some of its settings. actually from memory it does have a setting to allow only 1 instance of ffdshow in the codecs settings(thats ffdshows codecs settings and not windows).

as for the mem align hack well i wouldnt count on that fixing the problem with FreeEnc and P4's since Nic didnt use it and from what you said his 0.51 dll works with FreeEnc. worth a try though. :)

[vmesquita]

Originally posted by dragongodz
wow that is strange. QuEnc only opens the avs once but maybe they are popping up with each get of a new frame. that sounds more like an avisynth or ffdshow problem and since its ffdshow that keeps reappearing i suspect thats the problem.

Dont forget that the same problem happens with AVISource, so it's not related to FFDShow. But it maybe avisynth. (I am using 2.54) Looks like something is being loaded again and again in every frame. I still could not test in my machine at work to report back.


maybe trying a different version would fix that or changing some of its settings. actually from memory it does have a setting to allow only 1 instance of ffdshow in the codecs settings(thats ffdshows codecs settings and not windows).]

I'll look for it.


as for the mem align hack well i wouldnt count on that fixing the problem with FreeEnc and P4's since Nic didnt use it and from what you said his 0.51 dll works with FreeEnc. worth a try though. :)
Yes but:
1) QuEnc avcodec parameters are different from FreeEnc default parameters. Maybe some parameters trigger the problem.
2) QuEnc was done in VC++, while FreeEnc was done in MinGW+WxWindows. It shouldn't make difference since the code that crashes is inside the DLL, but...

So far, Peter1234 (one of the happy P4 owners that reported the problem) has had no crashes. I'll keep my fingers crossed.:D

[dragongodz]

same problem happens with AVISource, so it's not related to FFDShow
depends if ffdshow is still the decoder. ok the taskbar icon may not show up but that doesnt completly rule it out as being used. when you change the "only allow 1 instance" in ffdshows settings can you try both ways again ?

as for the mem align hack, well all i was saying is that you have an example of a dll that doesnt use it that works(Nics). so if it then does work with it in your compile then it is probably because of something the ffmpeg guys have changed since Nics compile. the only way to know though is to test that since as you point out QuEnc and FreeEnc are not done the same. :)

[lamster]

QuEnc 0.53 doesn't work with Rebuilder 0.56, since QuEnc dropped support for the -kvcd option, and Rebuilder always passes either "-kvcd" or "-nokvcd". Either of these options results in a pop-up saying "Bad Parameter!"

A couple of suggestions, for whenever this gets updated again:

First, if you're going to complain about a bad parameter, it would be nice if the pop-up specified which one was bad.

Second, if you're dropping a parameter, it might be nice to place it on a separate list, and if the options "-auto -close" are also present, just display a warning and otherwise ignore it, so that people invoking QuEnc via a front-end program won't be left dead in the water.

Thanks.

[dragongodz]

QuEnc 0.53 doesn't work with Rebuilder 0.56
yes and jdobbs has already said that will be fixed with the next version of DVD-Rebuilder.

whenever this gets updated again
wont be for awhile as both Nic and i have other things we are doing. your suggestions are noted though.

[Trahald]

I would also like to thank you for working on this software.

[EpheMeroN]

I've been testing QuEnc v0.53 on a 4:3 source that I captured at 560x420 resolution and am trying to convert it via AviSynth and QuEnc to a 1/2 D1 DVD Compliant MPEG-2 Video. I'm also trying to keep it intact as interlaced for it's pure NTSC 29.97fps and has no FILM content whatsoever.

The quality is fine, but the AR is off. If I choose 4:3 as the output Aspect Ratio QuEnc randomly will spill out either 1:1 Square AR, or 16:9 AR. Why I have no idea. I did not have this issue w/ QuEnc v0.51. Any ideas?

Here's the script I'm using for the video:

LoadPlugin("C:\Video Apps\AviSynth v2.5.4\Plugins\SubtitleEx.dll")
LoadPlugin("C:\Video Apps\AviSynth v2.5.4\Plugins\PeachSmoother.dll")
LoadPlugin("C:\Video Apps\AviSynth v2.5.4\Plugins\UnDot.dll")
LoadPlugin("C:\Video Apps\AviSynth v2.5.4\Plugins\UnFilter.dll")
LoadPlugin("C:\Video Apps\AviSynth v2.5.4\Plugins\SimpleResize.dll")

Clip_01 = Trim(AVISource("C:\Windows\Desktop\noname76.avi"),388,824).FadeIn(25).FadeOut(12)
Clip_02 = Trim(AVISource("C:\Windows\Desktop\noname77.avi"),0,3536).FadeIn(25).FadeOut(12)
Clip_03 = Trim(AVISource("C:\Windows\Desktop\noname78.avi"),0,5745).FadeIn(25).FadeOut(45)
Blank_1 = BlankClip(Clip_01,length=60,color=$000000)
AlignedSplice(Blank_1,Clip_01,Blank_1,Clip_02,Blank_1,Clip_03,Blank_1)

DelayAudio(-0.2)
SSRC(48000)

AssumeTFF()
SeparateFields()
PeachSmoother(NoiseReduction=52,Stability=25,Spatial=60)
UnDot()
UnFilter(15,15)
Weave()
InterlacedResize(352,480)
ConvertToYV12(Interlaced=True)

[jdobbs]

Originally posted by EpheMeroN
The quality is fine, but the AR is off. If I choose 4:3 as the output Aspect Ratio QuEnc randomly will spill out either 1:1 Square AR, or 16:9 AR. Why I have no idea. I did not have this issue w/ QuEnc v0.51. Any ideas?
I'm having the same problem. My 4:3 sources are coming out 16:9. It seems to have started recently, as I believe 0.51 was working.

[p200002]

Originally posted by dragongodz
yes and jdobbs has already said that will be fixed with the next version of DVD-Rebuilder.


wont be for awhile as both Nic and i have other things we are doing. your suggestions are noted though.

Which one will you suggest to downgrade? dvd-rb to .55 or QuEnc to .52?

[lamster]

Originally posted by p200002
Which one will you suggest to downgrade? dvd-rb to .55 or QuEnc to .52?

Well, personally, I'd suggest patching Rebuilder as I described in the Rebuilder bugs forum http://forum.doom9.org/showthread.php?s=&threadid=73050 (posted August 13) rather than downgrading either...

[p200002]

Can you email me the hacked rb? I have no experience editting hex.

[dragongodz]

hmm with 720x756 it works fine. just tried half d1 and ntsc and yep its wrong.

hmm visual studio has been acting wierd lately so i think i will uninstall everything and reinstall and see if that makes any difference.

i am changing isp, today is the last day with my current one. so i will not be online for a week or two. that should give me some time to try and sort this out. :)

[Peter Cheat]

I was trying to compile the source for QuEnc 0.53 but it came up with a tonne of errors (from the ffmpeg headers). I can easily fix the invalid type errors (long followed by long), but the others I don't know how to fix. This is the compiler output:


Compiling...
AVSEnc.cpp
C:\QuEnc\config.h(11) : warning C4005: 'CONFIG_WIN32' : macro redefinition
C:\QuEnc\common.h(10) : see previous definition of 'CONFIG_WIN32'
C:\QuEnc\bswap.h(16) : error C2400: inline assembler syntax error in
'opcode'; found '('
C:\QuEnc\bswap.h(17) : error C2064: term does not evaluate to a function
C:\QuEnc\bswap.h(17) : error C2143: syntax error : missing ';' before ':'
C:\QuEnc\bswap.h(18) : error C2059: syntax error : ')'
C:\QuEnc\bswap.h(26) : error C2400: inline assembler syntax error in
'opcode'; found 'no token'
C:\QuEnc\bswap.h(27) : error C2064: term does not evaluate to a function
C:\QuEnc\bswap.h(27) : error C2143: syntax error : missing ';' before ':'
C:\QuEnc\bswap.h(34) : error C2059: syntax error : ')'
C:\QuEnc\bswap.h(39) : error C2632: 'long' followed by 'long' is illegal
C:\QuEnc\bswap.h(39) : error C2632: 'long' followed by 'long' is illegal
C:\QuEnc\bswap.h(41) : error C2146: syntax error : missing ';' before
identifier 'uint64_t'
C:\QuEnc\bswap.h(41) : error C2501: '__extension__' : missing
storage-class or type specifiers
C:\QuEnc\bswap.h(43) : error C2143: syntax error : missing ')' before ':'
C:\QuEnc\bswap.h(43) : error C2290: C++ 'asm' syntax ignored. Use __asm.
C:\QuEnc\bswap.h(45) : error C2059: syntax error : ')'
C:\QuEnc\bswap.h(46) : warning C4244: 'return' : conversion from
'unsigned __int64' to 'unsigned long', possible loss of data
C:\QuEnc\common.h(225) : warning C4005: 'NDEBUG' : macro redefinition
unknown(0) : see previous definition of 'NDEBUG'
C:\QuEnc\common.h(239) : error C2010: '.' : unexpected in macro formal
parameter list
C:\QuEnc\common.h(239) : error C2010: '.' : unexpected in macro formal
parameter list
C:\QuEnc\common.h(239) : error C2010: '.' : unexpected in macro formal
parameter list
C:\QuEnc\common.h(239) : error C2010: ')' : unexpected in macro formal
parameter list
C:\QuEnc\common.h(278) : error C2143: syntax error : missing ')' before ':'
C:\QuEnc\common.h(278) : error C2290: C++ 'asm' syntax ignored. Use __asm.
C:\QuEnc\common.h(280) : error C2059: syntax error : ')'
C:\QuEnc\common.h(285) : error C2143: syntax error : missing ')' before ':'
C:\QuEnc\common.h(285) : error C2290: C++ 'asm' syntax ignored. Use __asm.
C:\QuEnc\common.h(287) : error C2059: syntax error : ')'
C:\QuEnc\common.h(800) : warning C4146: unary minus operator applied to
unsigned type, result still unsigned
C:\QuEnc\common.h(1077) : error C2010: '.' : unexpected in macro formal
parameter list
C:\QuEnc\common.h(1077) : error C2010: '.' : unexpected in macro formal
parameter list
C:\QuEnc\common.h(1077) : error C2010: '.' : unexpected in macro formal
parameter list
C:\QuEnc\common.h(1256) : error C2632: 'long' followed by 'long' is illegal
C:\QuEnc\common.h(1258) : error C2632: 'long' followed by 'long' is illegal
C:\QuEnc\common.h(1259) : error C2629: unexpected 'volatile int ('
C:\QuEnc\common.h(1263) : error C2143: syntax error : missing ')' before '}'
C:\QuEnc\common.h(1263) : error C2143: syntax error : missing ';' before ')'
C:\QuEnc\avformat.h(48) : error C2059: syntax error : 'bad suffix on number'
C:\QuEnc\avformat.h(48) : error C2146: syntax error : missing ')' before
identifier 'L'
C:\QuEnc\avformat.h(48) : error C2059: syntax error : ')'
C:\QuEnc\avformat.h(49) : error C2059: syntax error : 'bad suffix on number'
C:\QuEnc\avformat.h(49) : error C2146: syntax error : missing ')' before
identifier 'L'
C:\QuEnc\avformat.h(49) : error C2059: syntax error : ')'
C:\QuEnc\AVSEnc.cpp(309) : warning C4305: '=' : truncation from 'const
double' to 'float'
C:\QuEnc\AVSEnc.cpp(334) : warning C4305: '=' : truncation from 'const
double' to 'float'
C:\QuEnc\AVSEnc.cpp(557) : warning C4244: '=' : conversion from 'double'
to 'unsigned long', possible loss of data
C:\QuEnc\AVSEnc.cpp(605) : warning C4244: '=' : conversion from 'double'
to 'unsigned __int64', possible loss of data
Error executing cl.exe.

QuEnc.exe - 39 error(s), 8 warning(s)


(Are all these headers required???)
Am I doing something completely wrong, or am I just a retard???
I have a little experience with C/C++, I know Java and other languages better. I was expecting a pretty straigt forward compile but alas no.

You may be wondering why I want to compile the sources, well because I have "FIXED" the ratecontrol in ffmpeg (the code is a little messy at the moment, but works nicely). No bufferunderflows, quantiser is modulated with frame complexity, and if I get it compiled for QuEnc, should beat CCE or TMPEnc in quality (very good results with mencoder so far...).

For those that encode 2 hours of film onto 1 CD (SVCD 480x480, 480x576) at 850kps, this is what you've been looking for...

FFMPEG was compiled with MingW32 (maybe a problem?!?!?!?!?)
Tried to compile QuEnc with VC++ 6.0 (SP6) with latest Platform SDK etc etc.

Can you help me Dragongodz??? Anyone???

(btw. sorry for the long post)

[mean]

I'd be interested to have a look at the patch

[mean]

and "long long" means 64bits integer in Ansi/Gnu term

[Peter Cheat]

I'll clean op the ratecontrol code a bit, remove the debug messages I put in and post in on a website for those interested.

I guess I'll have to go through and fix the errors one by one. Damn I wish I knew X86 asm...

[mean]

Just out of curiosity, you are still using the VBV model for ratecontrol or a different way of enforcing max bitrate ?

[Nic]

Hi Peter,

Well done on fixing the ratecontrol :) (If indeed you have, I'd love to look at your source, if available please send to nic@nic.dnsalias.com )

As for the errors you were having...ffmpeg code is very gcc biased (it's a shame it wouldn't take much of a patch to make it (at least the headers) more VC compatible (although there is little interest in doing so)).

I've lost my notes, so I can't remember how I used to solve this problem. Try sticking a #undef ARCH_X86 in bswap.h after the header files. That would help some of those errors.

Shout me if you need more help. :)

-Nic

[vmesquita]

Hi Peter Cheat,

Great Job, I also would like to check the mod you did to the rate control. You don't need to recompile QuEnc: just recompile ffmpeg using mingw, so you'll get a new avcodec.dll with your fix. ;) Unless of course you changed something in avcodec.h.

[Peter Cheat]

@Nic
Thanks I'll try that when I get home from Uni

@mean
The VBV model is still being used, but to implement really strict max bitrate (ie frame size = max bitrate / frame rate) would take 3-4 extra lines of code max, and an extra parameter to enable this strict enforcement. I concentrated on fixing buffer underflows as my hardware player would jerk like crazy when they occurred.
I will write the code for strict max bitrate when I get home. I rewrote the frame size prediction, which was the problem with FFMPEG.

@vmesquita
Clean compiles are always best :)
Also, I would like to add extra options to improve functionality of QuEnc.

[mean]

Doig max framesize= bitrate/fps will give you a loss of quality

The following example is a bit extreme, but you 'll get the meaning

Assuming I frame size is 10
P frame size is 6
B frame size is 4
with a gop size of 12, you will have

1xI frame = 10
3xP frames= 18
8xB frames= 32

Total = 60
So it would give 60/12 frames~ 5 as upper limit for the I & P frames
which will negatively impact the overall quality

[Peter Cheat]

Originally posted by mean
Doig max framesize= bitrate/fps will give you a loss of quality


Yes, this is obviously the case.
I just realised this is pointless as if you want to keep the bitrate at a strict maximum, just make the VBV buffer really small (ie 1) :)
However there might be a need for strict max bitrate enforcement. I don't know but I'll leave it as it is for now.

btw
I managed to compile QuEnc, but, it crashes when you try to encode (Access Violation 0xC00000005) and for some reason, it compiles with the DLL built in (avcodec.dll not needed). My modified (improved)avcodec.dll will be uploaded sometime tomorrow for thorough testing.

[vmesquita]

Peter Cheat,

If possible, also post the source of your modified DLL so I can compile with my encoder FreeEnc. ;)

[RobertR]

I would also ask to post those changes at ffmpeg mailing list.
This would also help people that are trying encoding DVDs under Linux.
(there was someone there that fixed some problems with MPEG2 encoding, was that you?)
Can't wait till i get my hands on it
Thank You very much for your effort :D

[dragongodz]

However there might be a need for strict max bitrate enforcement
there is. vcd/svcd/dvd all do have a max bitrate because of hardware players. to ignore the max bitrate means that they may not play back smoothly or in extreme cases not at all.

I guess I'll have to go through and fix the errors one by one
yes the exact same thing as i have had to do. Nic and i did warn about this though so nobody should be surprised. as is i still cant get aspect ratio working properlly and it is no doubt 1 of those things that i havent changed right or something i need to change but havent. bloody frustrating.

[Peter Cheat]

Originally posted by dragongodz
there is. vcd/svcd/dvd all do have a max bitrate because of hardware players. to ignore the max bitrate means that they may not play back smoothly or in extreme cases not at all.


This surely can't mean that, for an SVCD for example, the maximaum frame size is 13KB at 25fps (2600kbits/s / 25 * 8 =13).
Hardware players have a buffer (112KB for SVCD). As I understand, as long as there is data in the buffer the player will be happy. Therefore a frame (perhaps I frame) can be 80KB, as long as the following frames do not chew up the rest of the buffer before it can recover. That is how I have implemented the code anyway, and my hardware player stopped jerking.

I have finally uploaded avcodec.dll (FFMPEG) and Mecoder, compiled with Ming32 to Modified Libavcodec Site (http://petercheat.host.sk/libav/). Try it out, and tell me what you think about it. The DLL should work with QuEnc and FreeEnc.

[Nic]

Hi Peter,

Well done on the work :) Being LGPL and everything, the source should really be released as well. Is there any chance of you uploading it soon? I'm sure myself, dgz, vmesquita would love to see the improvements you've made.

Cheers,
-Nic

[vmesquita]

Hi Peter Cheat,

Unfortunatelly, It didn't work properly in my test with FreeEnc... I asked for max 2500 and got spikes over 14000! :( Maybe I should tweak some parameter?

[mean]

In the original lavcodec 2 pass code, the max bitrate stuff was computed on the pre-pass2 stage but not in the actual pass2 .
Did you fix that too ?

[dragongodz]

Hardware players have a buffer (112KB for SVCD). As I understand, as long as there is data in the buffer the player will be happy. Therefore a frame (perhaps I frame) can be 80KB, as long as the following frames do not chew up the rest of the buffer before it can recover.
the max bitrate is usually averaged over the GOP. for reasonable quality there needs to be a limiting factor aswell to provide consistancy over the GOP aswell. in the case of CBR strict frame size limiting becomes even more important.

[Paced]

Originally posted by vmesquita
Hi Peter Cheat,

Unfortunatelly, It didn't work properly in my test with FreeEnc... I asked for max 2500 and got spikes over 14000! :( Maybe I should tweak some parameter?

Same thing happened to me; I managed to get a max bitrate of 23800 (with FreeEnc). On the other hand, when I use QuEnc (dragongodz' version), it exits/crashes just as it starts the second pass. With Nic's 0.51, the program doesn't start - it just comes up with a typical Windows 2000 crash popup window...this is all with Peter Cheat's avcodec.dll, by the way. :confused: But, I'm glad, and thankful, that someone is working on making the rate control better :D

[dragongodz]

Paced - with mine i have had some problems when avisource() is used for 2 pass, meaning second pass throws an error. directshowsource and mpeg2source(dvd2avidg 1.10) 2 pass works fine.

just did a quick 1500 frame test. not good.

target bitrate was 2000 with max 3000 for 352x576(hald D1). bitrateviewer shows average bitrate 3573 and max bitrate of 7682. those are waaaay over whats desired.

[mean]

The vbv buffer starts full
It is filled up with max bitrate maximum speed
It is emptied depending on the picture size and relation with previous pictures (i&p cannot be discarded right away).

If the buffer gets empty it means that max bitrate is not enough to fill it up quickly enough ->buffer underflow

The maximum bitrate is just one factor in the formula.
The VBV buffer size is as much or even more important.
The way the frames are removed from VBV buffer is not trivial either, especially for interlaced encoding.

What usually happens it that the ratecontrol reset itself at each gop and assumes it is full again. That(s why having variable gop size is not always a good idea.

Said in other words, the maxbitrate reported by bitrate view should be taken with care as it is not a real view of what happen in term of buffer fullness, which is what really matters, but a partial
view that is correlated to it but not equal.

The main issue with libavodec code is that the VBV buffer is used as very short term modifier, and in case of quick decrease of buffer fullness it not quick enough to compensate. Moreover the VBV model is a bit simple.

Now depending on the hardware, the buffer can be greater than the size indicated in the seq header.
It means that if the mpeg stream says it needs a buffer of 112K, the dvd player may use its full buffer anyway which may be > 240 Kb
Such player are very tolerant toward out of spec streams

Others apply strictly what's in the header and will use 112k period.

Finally the CD/DVD rom max speed should be x2 for SVCD, but some players happilly make them move faster, which makes them more tolerant toward out of spec stream.

A good example is pioneer old model (non MKT based), ST based.
They apply strictly the spec.
2x is 2x speed. Period.
112KB is 112K. Period.

[dragongodz]

mean - i agree but the max bitrate is usually a good indicator of if the VBV is working or not. a small spike in a GOP means nothing but when the total average and max are so high above target its easy to see its not.

also the point about different hardware being able to handle footage different is a good point. the target is and should always be to work on standards following hardware.

[Peter Cheat]

Originally posted by Nic
Hi Peter,

Well done on the work :) Being LGPL and everything, the source should really be released as well. Is there any chance of you uploading it soon? I'm sure myself, dgz, vmesquita would love to see the improvements you've made.

Cheers,
-Nic

I sent you an email with my modified source last night (my time). Source is available by request at the moment (don't want dodgy, almost completely undocumented code to spread). It has taken me longer to clean up than I expected.

Originally posted by mean

In the original lavcodec 2 pass code, the max bitrate stuff was computed on the pre-pass2 stage but not in the actual pass2 .
Did you fix that too ?


Ok, the two pass code is _entirely_ written from scratch. First pass is now done with constant quatiser 2, and max bitrate is ignored (first pass is useless to keep). Second pass takes the VBV buffer into account (rather than the max bitrate). The code works by using the average 'compressibility' of the 5 previous frames, and looks at the current and 9 future frames for possible buffer underflows. If a bufferunderflow looks imminent, the quantiser for the offending frames is increased by one and checked again. It will continue increasing the quantiser by one until there will be no buffer underflow. This creates a sort of averaging of degradation of frames, instead of a visible quatiser 31 (like in original code) for one frame, 10 frames can be averaged to a quant of about 7-10, which isn't noticeable. So far, I haven't been able to generate any buffer underflows, even with normally hard to encode material (such as the start of 'X-Men' movie, which is what TMPGEnc had a lot of trouble with). This is why I consider it fixed.


Originally posted by vmesquita

Hi Peter Cheat,

Unfortunatelly, It didn't work properly in my test with FreeEnc... I asked for max 2500 and got spikes over 14000! Maybe I should tweak some parameter?


But was there a buffer underflow? I don't think that there will be. Try encoding with Mencoder, or FFMPEG as I just realised that I put the version of Mencoder compiled for my CPU an Athlon XP. If you want to keep a strict maximum bitrate, set the buffer size to 0 and try that. 14000 / 8 / 25 = 70KB, which is less than the buffer size of 112KB, assuming you are using an SVCD profile.

I didn't expect it to work properly with QuEnc, or FreeEnc as I have changed code. QuEnc and FreeEnc was compiled with a avcodec.lib corresponding to a different DLL file. This is why I wanted to get QuEnc to compile (and work), so I could do some testing. On another note, what is the quality of the output like? Better than original libavcodec? As I said, if you cant get it to work, try with FFMPEG. If I can get QuEnc to compile, I can do more thorough testing, and even allow for a very strict bitrate enforcement, as it seems that this is what people are requesting (although I believe this is due to lack of understading of how hardware players work).

I'll upload some more tools soon, such as Mplex 2.0, which is great for SVCD multiplexing, some programs I have written, such as an audio analyser used to compare the difference in SNR and MSE for different codecs such as MP3, OGG, AC3, WMA etc so people can actually see that WMA sucks compared to MP3 :).

Back on topic, bitrate spikes are ok, PROVIDED BUFFER UNDERLOWS DO NOT OCCUR. A bitrate spike does not mean the codec stuffed up, it means the frame was harder to compress compared the the frames around it :) Buffer underflows are the problem I attempted to fix.

I am also considering the option of a third pass, which will marginally improve quality and further ensure no buffer underflows. But this is _after_ the 1 pass code has been done.

I'm out
Peter Cheat

[dragongodz]

bitrate spikes are ok, PROVIDED BUFFER UNDERLOWS DO NOT OCCUR.
sorry but thats not strictly true. small bitrate spikes will generally be fine true. spikes to 14000 such as vmesquita quoted(dvd target output i am assuming) is definatly not. most modern hardware dvd players may well play it but there will be others that stick strictly to the standard which may choke or stutter at that point. thats also why i said a more consistant GOP.

so actually there is 2 problems. VBV and max bitrate. both need to be considered. as i also said strict max bitrate is also very important for CBR.

actually i do remember an old open source encoder that used to do a GOP to memory and if it underflowed or overflowed then redid the whole GOP so it was consistant quality and able to catch major spikes in all frames. any spikes could then be dispearsed to the other frames in the GOP aswell.

[Peter Cheat]

Originally posted by dragongodz
sorry but thats not strictly true. small bitrate spikes will generally be fine true. spikes to 14000 such as vmesquita quoted(dvd target output i am assuming) is definatly not. most modern hardware dvd players may well play it but there will be others that stick strictly to the standard which may choke or stutter at that point. thats also why i said a more consistant GOP.

so actually there is 2 problems. VBV and max bitrate. both need to be considered. as i also said strict max bitrate is also very important for CBR.

actually i do remember an old open source encoder that used to do a GOP to memory and if it underflowed or overflowed then redid the whole GOP so it was consistant quality and able to catch major spikes in all frames. any spikes could then be dispearsed to the other frames in the GOP aswell.

dragongodz, I believe you misunderstand the actual concept of VBV buffers.

The purpose of VBV buffer is to allow for spikes. If indeed the profile which was used was DVD, then there is a buffer of 224KB. Now lets start with a full buffer:

Initial Buffer Occupancy = 224KB = 1835kbits
Lets say that the first frame is 560kbits (14,000kbit/s 'spike').
Frame 1 = 560kbits Buffer Occupancy = 1275kbits
But at the same time that the frame is being read, the buffer is filling with new data at max rate, 9800kbit/s (correct me if wrong)
Buffer Occupancy = 1667kbits
The buffer is now a little smaller, but not even close to an underflow!

Maybe vmesquita meant SVCD? If thats the case:
Initial Buffer Occupancy = 112KB = 917kbits
Lets say that the first frame is 560kbits (14,000kbit/s 'spike').
Frame 1 = 560kbits Buffer Occupancy = 357kbits
But at the same time that the frame is being read, the buffer is filling with new data at max rate, 2600kbit/s
Buffer Occupancy = 357 + 104kbits = 461kbits
We've lost half of the buffer, but we are still not creating an underflow. Hardware players that can play SVCDs to spec will not have any problems!!!!

This is provided that the next frames do not consume the rest of the buffer before it will refill. This is a simplified model of how the VBV buffer works. However, to my knowledge, it is correct. I had so many problems playing SVCDs made with FFMPEG, Mencoder, and even TMPGEnc, because of underflows. Since modifying the way libav controlled the frame data, I have had no problems (with 3 full length encodes). To me, this shows the model works. I haven't tried interlaced material, but I assume that the two fields are taken together (as a frame) and dealt with by the decoder. I maybe wrong here, as I said I haven't tried interlaced encoding.

In summary, a huge spike is completely meaningless unless it is larger than the actual size of the buffer, or larger than the remaining buffer.

A HUGE SPIKE IS MEANINGLESS AND DOESN'T AFFECT PLAYBACK UNLESS GREATER THAN BUFFER SIZE/REMAINING BUFFER

Maybe I should write a tool to analyse mpeg streams for underflows?
I don't have time for that sort of thing. Multiplexing tools usually tell you if there will be a problem with playback (TMPGEnc and BBMPG do).

FFMPEG used to create huge numbers of underflows (sometimes over 100 in a 1500 frame test encode). This was hopeless. I perform the same test with the modified ratecontrol and no underflows occur. Of course there are spikes, and for the best quality, one would expect them to be there. I frames take significantly more space than B frames for example. I expect to see spiking for I frames, a spiking B frame would trigger my attention, but it just may mean that the scene being encoded is of high motion.

mean's explanation (4 posts back) is almost spot on in explanation, except as far as I see, the VBV model in libav is *NOT* short term

[dragongodz]

I believe you misunderstand the actual concept of VBV buffers.
well you can believe what you like but you missed the point. :)

notice i said its 2 problems and not 1 ? VBV undeflows are just 1 part. max bitrate is also a factor which some hardware players MAY have problems with. to asume a large spike is ok so long as VBV is ok is a bad assumption. if the hardware player is strict with its max bitrate per frame limiting or reading it will have problems with such a spike no matter the VBV. actually full rate control takes in to account min bitrate and average/target bitrate aswell of course.
actually i can give a good example of how underflows are not the whole story. in some of the DVD-Rebuilder threads and on other forums its been shown that on some dvd players if min rate falls below a certain size (some its under 500 some its under 150) playback can stop or show serious problems. now thats only on certain dvd players. the target is to work on all and not just most.

I have had no problems (with 3 full length encodes). To me, this shows the model works.
no it shows it works for you with your player etc. a universal "works" is a big call from that. :D

A HUGE SPIKE IS MEANINGLESS AND DOESN'T AFFECT PLAYBACK UNLESS GREATER THAN BUFFER SIZE/REMAINING BUFFER
well thats another big call. so you have tested that on how many players exactly ? :sly:

[Peter Cheat]

This is my interpretation of the SVCD/DVD profiles.
I have not read anywhere that there is a 'hard limit' for max bitrate except for the max size of the VBV (this is the 'hard limit' that the encoder abides by). Do some test encodes for your player, and see if they play correctly. If you know about any 'hard limits' tell what they are, and they can be implemented immediately, and posted on the website. It's as easy as that.

[Peter Cheat]

Sorry for the double post, but here is an important quote from http://www.spawns.dk/svcd/main.htm
When capturing to SVCD with default SVCD-template of 2400kb/s videobitrate and 224kb/s audiobitrate - you might sometimes experience VERY short peaks up to about 3000kb/s. And you might ask yourself if this is not a problem since the SVCD-specs states a maxbitrate of only 2600kb/s ? Will it not cause my SVCD to stutter in my dvd-player ?

Well - no it wont - actually its a very common mistake to focus exclusively on max bitrate when creating compliant svcd. What is really much more important is muxingrate and packetsize. No encoder - software or hardwarebased is capable of keeping precisly within the max bitrate you specify, not even the DVCII. But this is not the biggest problem in itself - most modern standaloneplayers are capable of handling these very short peakbitrates within reason - the biggest problem is that most softencoders do not encode using the right muxingrates and/or packetsizes for SVCD - and this is mostly what is causing playbacktroubles like stuttering and breakups in video with ugly big green blocks sometimes even with peakbitrates lower than those of the DVCII. The DVCII however DO encode using the correct muxingrate and packetsize which is why a SVCD created with the DVCII will play correctly on 99% of the players even if the peakbitrates is close to 3000kb/s.

The correct values for SVCD are pack size = 2324 and mux rate = 2,788,800

Now the muxingrate is closely tied together with the datarate - this means that IF the peakbitrate much exceeds about 3000kb/s - the datarate WILL get to high for the standard SVCD-muxingrate to handle - and this will cause playbacktroubles - even if you do have a player capable of playing files with higher bitrates. The cure for this is simply to demux the file and mux it back together using BBmpeg setting the muxingrate to 0 - this will force BBmpeg to calculate the needed muxingrate to fit the datarate. The muxingrate will get higher and will nolonger be 100% SVCD-compliant - but it will make the file play correctly. This cure can also be used if you have older SVCD-files created with softencoders that are giving you playbacktroubles.

Please note however - that there are still limits to what bitrates can be used. Different players have different cappabilities in handling bitrates - some players may be able to handle almost any bitrate, while others may play fine with peaks at 2600 but immediately start breaking up with peaks at 2700 - muxingrates cannot ovecome these barriers - so you will have to try and figure out what peakbitrates your specific player can handle.


If 3000kbit/s for SVCD is the hard limit you want, as soon as I get home from Uni, a strict limit will be introduced, not allowing frames to be larger than 15% of the max bitrate, or user set. It will (hopefully) be uploaded later today (around 8:00pm GMT +10:00).
Maybe I should implement that the average bitrate for a GOP must not exceed the maximum bitrate...but I have the feeling this will not prevent huge spikes...

[dragongodz]

max rate, 9800kbit/s
you already quoted max bitrate spec for dvd (video component) playback yourself. to spike way over that is not a good idea to start with.

so again(and finally) i say its not just VBV but max bitrate aswell that needs to be considered for consistancy. i will do some fuller testing on sunday anyway and report what i find.

[Peter Cheat]

9800kbit/s is the maximum video data rate for DVD. This doesn't mean that a single frame cannot be 20,000kbits, it means that this is the speed the DVD is read!

[dragongodz]

thanks for that i will pick a couple of bits from that quote which actually back up what i have said.

will play correctly on 99% of the players even if the peakbitrates is close to 3000kb/s.
not 100% of players though is it ? which is what i said the target was. i even said most modern players do handle such streams but thats not the point.

The muxingrate will get higher and will nolonger be 100% SVCD-compliant - but it will make the file play correctly.
ah so long as it plays ok in 99% of players it doesnt matter that it breaks specs. hmmm.

Different players have different cappabilities in handling bitrates - some players may be able to handle almost any bitrate, while others may play fine with peaks at 2600 but immediately start breaking up with peaks at 2700 - muxingrates cannot ovecome these barriers - so you will have to try and figure out what peakbitrates your specific player can handle.
which is exactly what i have said several times now. :D


If 3000kbit/s for SVCD is the hard limit you want
no, bitrate limiting to max bitrate given is whats desired. whats the point of having a max bitrate setting thats not respected ?

[dragongodz]

9800kbit/s is the maximum video data rate for DVD. This doesn't mean that a single frame cannot be 20,000kbits, it means that this is the speed the DVD is read!
yes i know that. how well do you really think every dvd player will handle a 20000kbit spike though ? there are players that may start to have problems once it spikes over the 9800kbit. that quote you posted already says that type of problem for svcd, it holds true for dvd aswell.

[Peter Cheat]

What is the point of the VBV buffer then?
Do manufacturers stick to standards, or do they see the 9,800kbit/s limit and think to themselves, hmmm, I am lazy, so at 9,800kbit/s for a PAL DVD source, the max frame size will be 49KB, so my hardware decoder will decode no more than 49KB at a time and thats it!

If IC manufacturers design hardware like this, then there will definately be problems with playing back anything, including original DVDs from the shop.

If a DVD has a 224KB buffer, it is "safe" to assume that the decoder is able to handle at least 224KB per frame. Or is the buffer just there in case a frame is larger than 49KB, but really frames shouldn't be.

There seems to be a lot of contradictions in literature I have been reading. Sticking to the max bitrate for each frame is a little silly. It's like CBR, and everyone knows CBR sucks big time. I've just coded in maximum bitrate enforcement, I'll test in when I get home as I don't have MingW32 here at Uni :).
This is really going to suck though, but if this is necessary for strict compliance with players, then :D

[dragongodz]

as i already said small spikes should very rarely cause any sort of problem. other factors are being ignored though when you are considering VBV. audio, muxxing overhead, subs, padding/private stream - they all have to be loaded/played at the same time as the video aswell. once you start adding in those sort of factors you should see that its not only about video.

oh and yes CBR may suck but if someone wants to make a standard VCD for example it is needed. :)

[Nic]

Thanks Peter :) I'll have a look at it all on Tuesday (away till then :( )

You may want to make you max bitrate enforcement optional...if you can, or at least clearly marked in source code so it can be #ifdef'd out.

Great work BTW :)

-Nic

[mean]

I'd be interested to check your modifications.
Fixounet at free dot fr.
Thanks.

You are right, "short term" is not a good explanation.
I should have said blind.

As you said earlier, it works only if there is no big surprise in the current and very next images.

I did some testing some months ago, in the same type of code that you did. Project the next half gop frames using the current quantizer and it it is too low increase it, and this increase is slowly removed
(-1 quant per frame).


For interlaced encoding, the issue is that there is twice as much field with the I&P&B relationship. It means the code must be changed to
keep fields in the VBV buffer longer as they are needed longer

The present code handles field as special frames, so it will discard the
frames from VBV buffer at each new input, the relation ship is complicated in that case.

[Peter Cheat]

Modified Libavcodec Site (http://petercheat.host.sk/libav/) has been updated with a new DLL (FFMPEG), Mencoder (generic cpu) and also the modified source. The bitrate spikes should now be significantly reduced. If its not good enough yet, give me details about which frames are causing problems (mostly I frames) and by how much. I have one spike at 6000kbit/s when the max was set at 2600kbit/s, which probably isn't good for old dodgy hardware players. Anyway, this should be better, not perfect yet, but being worked on. Also added Mplex 2.0, a better muxing tool than some others.

[dragongodz]

probably isn't good for old dodgy hardware players
actually the player does not have to be old or dodgy at all just because it doesnt accept or displays a problem with out of spec streams. standards are set for a reason. :)

on the site you ask about CCE. well in the DVD-Rebuilder forum its been shown that CCE can spike past max bitrate occasionally aswell. what was the result ? problems on playback on certain players, certain models of sony and pioneer from memory. not exactly dodgy hardware. :)
jdobbs reduced the max bitrate setting DVD-RB set to help with these problems.

also for those testing for dvd output they can use this
http://users.adelphia.net/~liquid64/dvdauthorgui.html
to author. it uses mplex aswell. :)

oh a side note about 1 pass. Michael(of FFMpeg) was talking about doing per MB rate control which would be suitable for both 1 pass and 2 pass. just another idea in the pot. :D

and thanks for all the work you are doing.

[Peter Cheat]

How would macro block rate control work? Does this mean assigning quatisers to each macro block of a frame rather than a frame?
I can sort of see some benefits, but it probably won't improve predictability of a frame size...

The reason I said "dodgy hardware players" was because when engineers are designing hardware (engineering being the profession I am studying at uni), it is important to expect the unexpected. Sony and Pioneer are expensive brand name DVD players, yes true. But the actual mpeg decoder they have inside may be the exactly the same as the el cheapo players that cost 75% less... A strictly valid stream is hard to create, so a player expecting a stream to be 100% compliant is a little to idealistic, if not outright stupid :) I've tried my encodes on 5 different players, newer models all played fine, only a friends 4-5 year old DVD player than only supported VCD didn't want to play it (not surprisingly). Anyway, is the updated code better?

[dragongodz]

Does this mean assigning quatisers to each macro block of a frame rather than a frame?
more of a bitrate allowance/sum and adjustment. so like how you do a few frames and then work out what the other frames in the GOP come out as(size wise etc) based on those and then adjust quant if needed. same type of thing but do a MB and work out the rest at that quant, if not desired result then adjust quant accordingly etc.
Michael didnt go in to it in detail but that is what i am assuming. i did actually read some material on per MB and per frame rate control some time ago, will have to see if i can dig it up again for you. :)

it is important to expect the unexpected
true but the whole point of setting a standard is that there should be no surprises. or if there is then minor ones. as such most modern players do handle out of spec streams reasonably but not all and its never quarenteed. so you really cant critisise a manufacturer that works to the standard only as its not their fault if someone creates out of spec material.

the actual mpeg decoder they have inside may be the exactly the same as the el cheapo players that cost 75% less
yes there are only so many chip makers, i doubt many of the cheap dvd players use pioneer chips though. pioneer i believe do generally make their own chips so again not exactly dodgy. :)

a player expecting a stream to be 100% compliant is a little to idealistic, if not outright stupid
no its what the whole point of standards is about. take the CCE spiking problem i mentioned. now that only occasionally happens and from memory it was with 2 pass and max set to over 9000kbit. set slightly lower or maybe even doing 3+ passes and it wasnt a problem. i have never heard of this problem with Tmpgenc or Procoder by the way but who knows.
thats why i said 3 pass MAY be advantages in the poll thread you posted. professional producers do not seem to have any problems producing standard streams either. :D

Anyway, is the updated code better?
well i have already said i wont get time to do any testing until sunday, even then it will probably be limited. so anyone else ? come on guys help make a free encoder even better.

[dragongodz]

bump so people notice the update. :D

[lamster]

Thanks for the update!

Is there a discussion anywhere of why we might want to or not want to use the custom matrix?

[jdobbs]

Thanks, dude. Nice work!

I've already updated DVD-RB with the version check and the cmatrix commands, but won't post until tomorrow. Bad timing on my part.

[dragongodz]

Is there a discussion anywhere of why we might want to or not want to use the custom matrix?
it has been discussed in both the xvid and cce forums in the past. using a custom matrix such as the built in QLB one is good for low bitrate encoding. example - you encode a file at a constant quant and it ends up size A, do the same but use a custom matrix such as QLB and the same file turns out 10% smaller(will vary depending on footage etc) but look the same unless you zoom in for the tiniest details.

Bad timing on my part.
nah bad timing by us both i guess. :)

[dragongodz]

just curious on the aspect ratio. so is it all ok now for everyone or still a problem i can try to replicate ?????

[jdobbs]

Ok, I'm confused. I tried 0.54 and trying to use "-cmatrix" or "-nocmatrix" fails -- and "-qlb" or "-noqlb" works... am I missing something here?

On the bright side, the new version works with DVD-RB 0.57 for that reason.

[dragongodz]

hahaha you are right. i missed 2 changes. bugger. see now thats what happens whena person rushes to get a release out before another program is updated(meaning DVD-RB). bloody failed on both counts. :D

no rush for me to fix it is there ? it can wait a week say so i can actually make some other changes ?

ok just updated the first post history. :)

[jdobbs]

Wow, you're good. Even your missed changes are helpful. That saves me from having to put an interim DVD-RB version out also!!!

[lamster]

Just tried using the latest (0.54), and got a Priviliged instruction exception (0xC0000096) at address 0x10176343. This was in avcodec.dll, which was loaded at 0x10000000; the instructions at the place where the exception occurred are:

10176343 66 0F 7F 4A 00 movdqa xmmword ptr [edx],xmm1
10176348 F3 0F 7E 53 40 movq xmm2,mmword ptr [ebx+40h]
1017634D F3 0F 7E 43 48 movq xmm0,mmword ptr [ebx+48h]
10176352 66 0F 6F 59 20 movdqa xmm3,xmmword ptr [ecx+20h]
10176357 66 0F 6F 79 30 movdqa xmm7,xmmword ptr [ecx+30h]


I was running it from DVD Rebuilder 0.57, on a Windows 2000 Professional system. Let me know if you need any more information.

[dragongodz]

you wouldnt happen to running on a pentium 4 by any chance ?

[lamster]

Originally posted by dragongodz
you wouldnt happen to running on a pentium 4 by any chance ?

Got it on the first try! :)

Interestingly, the error happened on the second file that Rebuilder invoked QuEnc on, and after I killed the debugger, it processed a few more uneventfully before I killed everything and restarted.

I'll know in a few minutes if it's repeatable...

[lamster]

Originally posted by lamster
I'll know in a few minutes if it's repeatable...

This time it got past that point without problem?!?

[dragongodz]

i also just uploaded tp the QuEnc download page the avcodec compiled with the memalign hack. so if you have any more problems can you test that ?

if that doesnt completely clear it up then next release i will go back to a newer cvs release. i assume 0.53 didnt have any problems ?

[EpheMeroN]

I shall do a sample encode to 1/2 D1 NTSC MPEG-2 in the morning to verify if the AR issue has been resolved :)

Keep up the good work on this awesome encoder.

[Peter1234]

dragongodz,
I tested QuEnc 0.54 with memalign hack avcodec.dll on P4 and there were no SSE2 problems. Also encoded 352x480 NTSC MPEG-2 and it plays in WinDVD with proper aspect ratio.

[EpheMeroN]

Okay, I just ran a test on QuEnc v0.54 and the 1/2 D1 NTSC Aspect Ratio Error is fixed! Good job =)

[dragongodz]

thanks guys, good to know. :)

[insanescape]

Question about QLB, what it does, and what exactly comprises "Low Bitrate" when dealing with DVDs?

I've got a movie that's going to stretch it, about 190 minutes or so, probably around no more than mid 2-ish for the bitrate. Should I turn on QLB or just leave the regular?

[dragongodz]

in simplest terms it will drop some very fine detail allowing for better compression.

my best advice is to do a small clip or 2 both using it and not. then compare them playing and see how much difference you can see. if you cant see any real difference then using QLB is definatly a good idea for lower bitrates.

whats a low bitrate foe dvd ? well around 3500 and up would be the majority of standard dvds i would think. so once you start to go under 3000 you head towards a low bitrate where picture quality will start to degrade noticably.

[EpheMeroN]

I'm getting an error when trying to encode a video:

AVS File is not outputting
(Use ConvertToYV12() at end of script)

I don't understand becase the last line of my script is ConvertToYV12(Interlaced=True), yet I'm still getting that error. I'll test on another machine w/ same input video to narrow down the issue.

[dragongodz]

are you using avisource() in the script ? there is a known bug that it wont do 2 passes with that. directshowsource() works fine however.

also how many frames is it ? another known problem is 1 or maybe 2 frame sources also not doing 2 pass.

[EpheMeroN]

I was using AviSource in the script. I switched to DirectShowSource and it's still giving me the ConvertToYV12() error.

The video is 1229 frames so the other issue is not present here either...

Okay I just tested something and fixed it. I tried dragging the AVS Script into Vdub. It told me that PeachSmoother needed YUY2 color format and gave me an error. Usually my captured AVI files are in YUY2 colorspace natively but the video I was dealing with I edited and processed out of Vegas Video for a DVD I'm working on. Vegas Video made it RGB32 colorspace. QuEnc for some reason gave me a YV12 error but I believe it was trying to tell me PeachSmoother needs YUY2 like Vdub said.

I tossed a quick ConvertToYUY2(Interlaced=True) in my script and it fixed everything.

[dragongodz]

ok. probably need to change that warning then to say there is a possible error in the avs and that you may have to add ConvertToYV12() at the end if it isnt.

[Peter Cheat]

Doesn't AviSynth pass the details of the error to QuEnc???
If it does, then just mirror the message to the user. Couldn't be too difficult I imagine.

[dragongodz]

i just had a quick look at the avsreader and the only functions it has at the moment is for getting the frame size, frame rate and total frames etc. you would have to ask Nic about adding getting the error message as i havent really looked at the source since 0.54 and wont for awhile. i am currently busy trying to squeeze in something else. :)

[Nic]

It's tricky to get the error from avisynth...also QuEnc reports a possible YV12 trouble, with all avisynth errors (because the error is being output in something other than YV12). So it can be confusing. Ill try and remedy that...

-Nic

[Mug Funky]

one question:

quenc works very well in interlaced mode (target svcd bitrate), but is there a way of selecting alternate scan? is it even necessary?

i'm a little clueless about mpeg-2 interlacing as there is a lot of conflicting information about how it is actually done (like field-based motion, field pictures, alternate scan, or all the above).

[Nic]

Well i'm a bit clueless about it all too ;) Hence, why alt-scan isn't an option, but I could add it if you want/need it?

-Nic

[dragongodz]

"MPEG-2 defines two different zigzag scanning orders: zigzag and alternate scans as shown in Figure 15. The zigzag
scan used in MPEG-1 is suitable for progressive images where the frequency components have equal importance in
each horizontal and vertical direction. In MPEG-2, an alternate scan is introduced based on the fact that interlaced
images tend to have higher frequency components in the vertical direction. Thus, the scanning order weighs more on
the higher vertical frequencies than the same horizontal frequencies. In MPEG-2, the selection between these two
zigzag scan orders can be made on a picture basis."

taken from
http://www.ee.eng.chula.ac.th/~supava/doc/mpeg12.pdf]

i also read elsewhere that alternate scan can even give better quality with progressive mpeg2 encoding but that seemed more of an opinion since no hard data was given. :)

[Mug Funky]

thanks, dragongodz :)

so this would help then?

but if it can be set per-frame, it might be useful to allow QuEnc to handle it (maybe that would require avcodec to be modified).

AFAIK DV video does this per-block, but that's probably a bit much (and wouldn't work in mpeg-2).

[edit]

about it having better quality on progressive... that sounds a bit naff. i could only think of it looking better on NTSC where vertical res is more important, but i would think the chroma would be messed up and offset the very slight possible benefit.

rather than adding an alternate scan checkbox, it should probably just be tied to the "interlaced encoding" option. i think nic said he didn't want the interface to get cluttered. i suppose it makes sense - if people want to tweak, they can do it with ffmpeg at the command-line.

[dragongodz]

so this would help then?
with interlaced encoding it would seem so.

but if it can be set per-frame, it might be useful to allow QuEnc to handle it (maybe that would require avcodec to be modified).
hmm well for static/near zero motion scenes zig-zig may do better. without looking at the avcodec source i doubt it does per frame. so i suspect its an either/or case.

about it having better quality on progressive... that sounds a bit naff.
ye i found it strange which is why i said there was no data to prove that. i will look in to it more when i get the time though. :)

rather than adding an alternate scan checkbox, it should probably just be tied to the "interlaced encoding" option.
i agree.

i think nic said he didn't want the interface to get cluttered.
yes plus also make it straight forward enough for anyone to use. give people 100 options they can fiddle with and many will f*ck it up. many options can be set by just following certain basic rules. using alternate scan for interlaced mpeg2(no checkbox) is a perfect example. i have read comments by many "experts" who really know bugger all. you would not believe some of the ideas people have, they want to be able to "tweak" everything they can, no matter if its more likly to mess things up. :D

[Nic]

So what's the concensus then? Should I turn it on when interlaced encoding is turned on? (U know me ;) I like to keep it to as few configurables as possible...so don't really want to add an extra option)

-Nic

[Kika]

My suggestion:

If interlaced is turned on, use alternate scan, if it is turned off, use ZigZag. Many Encoders are doing it this way.

And if you like, include an Expert-Setting-Mode where people who like to play can choose their own settings. ;)

[Mug Funky]

@ dragongodz: yeah, tweekers can often do more harm then good.

just look at the LAME encoder... no matter how many times it says "use the presets", people will just download the program, and type "lame -?" and then complain to the devs that their encoder sucks :(

[edit]

and i'm for tying alternate scan to the interlaced button. there's no good reasons not to from my (very limited) research.

[dragongodz]

Should I turn it on when interlaced encoding is turned on?
well i vote yes.

people will just download the program, and type "lame -?" and then complain to the devs that their encoder sucks
yes thats exactly what we would rather avoid. :D

[EpheMeroN]

I also agree that "Alternate Scan" should be enabled when checking the "Interlaced Encoding" Mode.

When I used CCE months ago, switching from "Zigzag Scanning Order" to "Alternate Scanning Order" always yielding me more quality whe dealing with Interlaced Material.

On a side note, I have a ??? about DC Precision. I've always set it to 10 for everything I've ever encoded. What are all the pros/cons to using a DC Precision of 8 or 9 besides slightly faster encoding time?

[dragongodz]

What are all the pros/cons to using a DC Precision of 8 or 9 besides slightly faster encoding time?
what it comes down to is quality(at least in theory). higher dc precision should give you slightly better quality.

there are limits to what can be use for what of course. example - vcd uses 8, svcd can use 8 or 9, dvd can use 8,9 or 10. dc precision 11 is used for HighProfile@ (such as 20Mb/s or more)

[Nic]

? The difference in encoding time should be non existant with different dc precision...basically, higher dc precision will take up slightly more bits but can make for a higher quality picture. (This is my understanding, i may be talking cr*p ;) )

-Nic

[Kika]

The DC-Precision affects the way, the DCT/Quantisation works.
With 10 or 9 Bit you can expect a better quality, yes, but you will also need slighty more Bitrate.
9 Bit DC is always a good choice for Movies.
For my self, i only use 10 Bit for my private Videos (from Hi8), if i plan to put it in highest possible Quality onto DVD (at Max. Bitrate).

[Mug Funky]

doesn't DC precision only affect the very first coefficient (like the "base colour" for the block)? if that's the case, then it would make almost negligible difference to quality and filesize.

or have i got it wrong? damn mysteries.

[dragongodz]

"intra_dc_precision: the MPEG-1 DC value is mandatory quantized to a
precision of 8 bits. MPEG-2 introduced 9, 10, and 11 bit precision set
on a picture basis to increase the accuracy of the DC component, which
by very nature, has the most significant contribution towards picture
quality. Particularly useful at high bit rates to reduce
posterization. Main and Simple Profiles are limited to 8, 9, or 10 bits
of precision. The 4:2:2 High Profile, which is geared towards higher
bitrate applications (up to 50 Mbits/sec), permits all values (up to 11
bits)."

from

http://www.faqs.org/faqs/mpeg-faq/part3/

:D

[Kika]

doesn't DC precision only affect the very first coefficient

No, it affects all elements of the Matrix.
While DCT, all elements are being roundet, at higher precision, you will get lot's more of different results. That lowers the risc of getting Rainbow-Effects but needs more Bitrate.

That all is becoming very complicated, if you want to use a special Matrix for quantisation. And if the bitrate isn't high enough, you may get LOWER quality at 10 Bit...

[Mug Funky]

hmmm.... come to think of it there's nowhere to set the field-order in the GUI. i'm assuming it's TFF by default (as most mpeg-2 is).

[dragongodz]

well i just had a quick look at ffmpeg.c etc. ok theres a couple of flags that can be set, CODEC_FLAG_INTERLACED_DCT and CODEC_FLAG_INTERLACED_ME. there does appear to be a top field first option aswell where you can set top, bottom or automatic.

just some more stuff for Nic to look at when he gets time. :)

[freelock7]

Strange MPEG2 results after encoding a movie at 4000 VBR:
On my PC, the movie works fine and on my DVD player it shows a lot of ugly pixels.
What does it means?

[dragongodz]

is it bad the whole way or just in parts ?
how did you author the dvd ?
are the pixels there when played by your pc from the burnt dvd ?

could be anything from a bad encode to bad authoring to a bad dvdr.

[freelock7]

the hole part.
I'm using DGindex for the .d2v file and the avs works well with CCE on my DVD player.
I'll test 0.51 to compare.
DC precision is fixed at 11.
Maybe the wrong choice?

[dragongodz]

DC precision is fixed at 11
GAK! read what i said above about what DC precision can be used for what. 11 is for HighProfile@ only. DO NOT use it for dvd etc. the max for dvd is 10.

[freelock7]

sorry!
It's fine.
The picture is very accurate without blocs on the edges-with asharp(2,5).
Now, it's hard to see a difference between 0.54 and CCE!

Settings:
-VBR>3500(*)
-High quality
-2Pass
-treillis quant
-interlaced
-detect scene change(**)
-limit high bitrate:7500(***)
--------------
(*)Advice: Not under for best performance
(**)seems to be necessary for better results in high speed motion picture.
(***)More precise & stable than 0.51.

[Amnon82]

@dragongodz: I added support for QuEnc 0.54 to ESD 0.6. The only Problem is this:

the options: -cmatrix and -nocmatrix doesn't work. Can You tell me the right strings?

[RobertR]

Originally posted by Amnon82
@dragongodz: I added support for QuEnc 0.54 to ESD 0.6. The only Problem is this:

the options: -cmatrix and -nocmatrix doesn't work. Can You tell me the right strings?
It's hidden somewhere in this thread :)
Try -qlb and -noqlb

[Amnon82]

I try this. Thx.

Also I found out that -scene and -noscene won't work!

K -qlb and -noqlb works. But if I check -qlb it shows QuEnc quick and disappear again. Nothing happend.

This happens also when I used the avcodec.dll compiled by Peter Cheat.

[Edit] With the avcodec-mem.dll it works. There is still the -scene/-noscene matter.

@nic and dragongodz: When do you guys add a custom matrix support. I for example want to test my own matrix with quenc for example. In FreeEnc it works realy good. I tested in the newest ESD build the FreeEnc with my CYDVD 2.0EX Settings against the Settings of 0.54 using the Custom Matrix. In QuEnc I got a higher avg.Bitrate during prediction but not so a good Quality with FreeEnc using a lower avg.Bitrate to get the same size.

[dragongodz]

yes mentioned when i released 0.54 i missed a couple of changes to for the cmtrix commands to work. so the qlb commands were still active. not a big issue since jdobbs had just released a new version of DVD-RB using the qlb commands. :)

-scene and -noscene won't work!
hmm thats strange. i will test that out later and see whats up.

When do you guys add a custom matrix support
i personally do not like to say when things will and wont happen. otherwise people get expectations and they start to ask "when?" as you just have. so it will happen when it happens. :D

a lower avg.Bitrate to get the same size
you lost me here. if you have 2 encoded files that are the same size they cant have a different average bitrate.

[Amnon82]

a lower avg.Bitrate to get the same size
you lost me here. if you have 2 encoded files that are the same size they cant have a different average bitrate.

My program ESD is a Prediction Routine for QuEnc and FreeEnc.
I tested the same Movie with both Encoder.

First I encoded the Movie in FreeEnc and got a file with the size of 798,56 MB and a Sample of 9,86 MB. The Quality with a avg.Bitrate of 751 was good.

Then I encoded the same Movie with QuEnc with a avg.Bitrate of 981 and got also a Sample of 9,86 MB and a 797,56 MB big file with less quality as the one encoded with FreeEnc.

The avg.Bitrates are calculated by ESD. In the QuEnc-Mode it takes always higher Bitrates than in FreeEnc. I don't know why. The Result is always the same. This is realy strange.

Only thing I did was using my settings in FreeEnc (CyDVD 2.0 EX).
In QuEnc I only can use the KVCD Matrix or the buildin one.

If I can change the Matrix, maybe it will get the same Quality.
I used for both encodes the avcodec.dll You called avcodec-mem.

[dragongodz]

ah you mean avg. bitrate you enter. i meant the real average bitrate of the produced mpegs. the same size means they should be the same bitrate(or close since the example you gave they are not exactly the same).

QuEnc uses the standard matrix or custom(QLB, Quenc Lower Bitrate)) matrix. kvcd matrix was replaced as of QuEnc 0.53.

simply replacing the matrix will not change things to make them the same. you would also have to use other settings that QuEnc uses to reduce bitrate spiking. this is no doubt where the quality loss comes from aswell.

i did a quick test to use as an example. i did a short clip(1500frames), 720x576 ,25fps, avg bitrate 3000, max bitrate 4000.
freeenc using default matrix(which is notch i believe) 10.2mb, pulsing and bad to be honest.
freeenc using incredible matrix(had to delete default matrix file for this to actually work), 20.5mb, quality ok.
QuEnc no custom matrix, 20.5mb, quality ok.

now when viewed with bitrate viewer it shows another important detail. freeenc(incredible) spiked to 4786 bitrate while QuEnc max remained just below 4000. so during those spikes freeenc will look better since its using more bitrate for those frames. QuEnc however is trying to stay below the max bitrate(no it wont 100% of the time but it does try :) ).

now when you are making a video for vcd/svcd/dvd that max bitrate is rather important. there are set standards for them and if not adhered to then some hardware players can have problems playing them. thats why QuEnc's settings are the way they are.

so how does this relate to the avg. bitrate you enter. hmm well its possible that the spiking is actually taking the bitrate higher than what you enter so you have to enter a lower value to begin with.

it will be nice when Peter finishes the new rate control and settings dont have to be messed with to try and force avcodec to do what it is meant to. :D

[dragongodz]

ok just tested the -scene and -noscene commandline options. both worked fine. i checked the advanced options and it was changed both times correctly. i then checked the produced files and again they were correct.

[Amnon82]

I retested it and got this:

http://www.brckomania.net/CYBERNETSOFTWARE/images/quesd.png

And here the created File by ESD 0.61:

@ECHO off
ECHO Batchfile created with EasySVCD/DVD 0.61 - visit: www.cydvd.tk
ECHO Start encoding Movie Fullencode Pass
C:\Programme\ESD\Encoder\QuEnc.exe -i "D:\esd\test.avs" -o "D:\esd\test.m2v" -b 3550 -maxbitrate 7550 -dc 10 -1 -mpeg2 -hq -vbr -scene -trell -cgop -nointerlaced -noextreme -gopsize 15 -maxbframes 2 -qlb -aspectratio 16:9 -auto -close
exit

So what is wrong?

[dragongodz]

dont know. i tested from the command line.

i have downloaded ESD and will try to test it sometime tommorow. will let you know if i can repeat it once i have.

[lamster]

Originally posted by dragongodz (to "DVD Rebuilder > QuEnc encoding completed in 0 minutes!")
well its basically the sse2 parts of avcodec that are the problem. you either have to disable sse2 or use the memalign hack to make it work properly with a P4. you would think one of the FFMpeg guys would have tracked down the problem. apparently though its not meant to be so bad under linux so they havent.

I understand that the problem is that an exception is occurring in avcodec.dll, because the structure isn't properly aligned, and the movdqa instruction generates a protection exception if the memory address isn't 16-byte aligned. (I had reported my experience at http://forum.doom9.org/showthread.php?s=&postid=539053#post539053 )

The fix is to either ensure that the address is properly aligned, or use movdqu instead of movdqa.

My point was that the symptom reported in the other thread was that QuEnc was only doing one pass, and nobody (but you) had a clue as to what was going on. If you were to wrap the calls to avcodec.dll (possibly just the call to avcodec_encode_video) in a try / catch(...) block, you could catch the exception and display a message saying that avcodec wasn't behaving nicely. (If you wanted to get fancy, you could add a structured exception handler and see exactly what the exception was, to give a better error message - "Dude - you're running on a P4 and getting a Priviliged instruction exception - RTFM !!!", and log some diagnostic information, but that's not really necessary.)

[dragongodz]

Amnon82 - ok did some quick testing. the problem is closed gop and scene detection, they do not work together, try selecting both in the QuEnc gui. so its either 1 or the other. try turning off closed gop in ESD and you will see scene change works fine from command line.
i also noticed you dont put quotes "" around the path to the ESD exe. if installed in a drawer with a space in the name the bat wont work.

lamster - yes i understand but since all versions should use the memaligned compile from now on is there a real need ? the only problems i have seen reported have been fixed with that.

[lamster]

If QuEnc will be shipping with the memaligned avcodec.dll, then I agree that it's less likely that people will run into it.

[Amnon82]

THX for the replay dragongodz.

[Peter Cheat]

@dragongodz
There is a mistake in the code for setting aspect ratio. In file "AVSEnc.cpp" the line:

c->sample_aspect_ratio = av_d2q(frame_aspect_ratio,255);

should actually be:

c->sample_aspect_ratio = av_d2q(frame_aspect_ratio*c->height/c->width,255);

This fixes the aspect ratio problems. (Look in FFMPEG source, this is how it is done in there).

[dragongodz]

This fixes the aspect ratio problems.
that was already fixed on 0.54. what version of the source code are you looking at ? in 0.54 it has

c->sample_aspect_ratio = av_d2q(frame_aspect_ratio*sdh/sdw,255);

its interesting though that 0.51 didnt need the height and width. it however used a much older checkout of FFMpeg.

[Trahald]

How hard would it be to add support for Chapter setting (ie forced I-frame insertions)? (I was whipping up something in c++ to use quenc with big3)

[dragongodz]

i remember there was some asking about I frame insertion on the FFMpeg mailing list. went nowhere. so dont expect to see it soon.

[darkluna]

How difficult would it be to save the 1st pass info file to a specific directory so that you could run (or re-run) the 2nd-pass separately at a later time? This would be a very handy feature.

Thanks for all the work

[zilog jones]

Someone probably noticed before how QuEnc encodes TFF interlaced video as BFF, but is there any way of fixing this? Is there just some byte in the file header that needs be changed or what? I'm fimiliar with hex editors if it is something like that.

[Mug Funky]

a little program called "ReStream" may be what you're looking for.

i think it's just a stream flag thing, but it may not be, so don't hit me if it doesn't help you (i do a lot of testing, but not many actual encodes, and as such haven't tried interlaced QuEnc on my teev yet).

[Peter Cheat]

Originally posted by dragongodz
that was already fixed on 0.54. what version of the source code are you looking at ? in 0.54 it has


I thought I was using 0.54 source. Now I am not sure.

@Mug Funky
If it is only a flag that has to be changed/set, then it can be fixed in QuEnc easily.

[dragongodz]

I thought I was using 0.54 source. Now I am not sure.
it also says QLB matrix in the gui etc so i am guessing its actually 0.53 you may be using. :)

If it is only a flag that has to be changed/set, then it can be fixed in QuEnc easily.
yes a page or so back its already mentioned that there is an option in FFMpeg for TFF and BFF. so yes thats another thing on the list for the next version.

How difficult would it be to save the 1st pass info file to a specific directory so that you could run (or re-run) the 2nd-pass separately at a later time? This would be a very handy feature.
yes quite possible to do but its questionable of how much use it would be. ok you can encode passes at different times but on the same hand if you change anything between passes(such as in the avs) it makes the first pass pointless. i dont think its a priority to me.

[Mug Funky]

@ dragongodz: would it be beneficial to save the first pass, and on the 2nd and 3rd passes do something tantamount to a "rejig", that is re-encode using the motion vectors from the 1st pass? this would make "fast 2nd pass" REALLY fast.

or do the vectors change subtly in 2nd and 3rd passes?

[dragongodz]

hmm well it would need proper testing but seeing as the first pass is effectivly a constant quant encode i dont know how reliable they would be for using for the second pass, the motion vectors that is. however from second pass to third ? that may be worth investigating how much MVs change or not.

just as a note about re-using MVs. i notice that you can write an MV file with divx's first pass and read it for nth passes BUT thats only for standard mode. for slow and slowest that function is disabled and not ticked. kind of suggests it doesnt give the best results/quality.

so unless people are interested in a sub-optimal/lower quality quick encode its probably best not to re-use MVs from the first pass.

[Mug Funky]

mm. okay.

does this mean MVs are calculated after quantization? i thought they were calculated using the source picture (at least, the CCE manual says this, but i suppose libavcodec is entitled to do it differently).

because if MVs are calculated off the source, then re-use seems logical, but of course, it's quite possible the best rate/quality is achieved by calculating them after quantization.

i don't know enough about MPEG-2 :scared:

[dragongodz]

motion vector decisions are based on pre-encoded frames compared to the current frame. that is how much like is the previous I or P frame in the GOP to the frame we want to encode(actually this is all done by macroblock but i am just trying to simplify it). now with first pass encoding everything at say quant 2 you are going to get pretty good block matching. however when you do the second pass you are doing VBR and the quants will change as things like the rate control require. so a motion vector based on a P frame that was quant 2 first pass may not be ideal if the same P frame is encoded at quant 10 second pass. a frame referencing it may no longer be a very good match in other words.
hope i explained that well enough(i doubt it but that should give you some idea). :)

oh and i just installed divx 5.2 today(to check a problem a freind was having) and i notice it no longer has the reuse MVs. 5.1 did but i guess they decided it wasnt worth keeping. i have the feeling the same is true for QuEnc aswell.

[darkluna]

I was looking for the option to do the 2nd-pass separately, as a way of interrupting the process. My encodes take a long time to complete, and there have been times when I have wanted to stop after pass 1, do something else, and then pick up pass 2 at a later time

[Peter Cheat]

Going back a few posts...

Originally posted by Trahald
How hard would it be to add support for Chapter setting (ie forced I-frame insertions)? (I was whipping up something in c++ to use quenc with big3)

Actually, this isn't hard to do at all. It is easy to force FFMPEG to use any frame type, for any frame you want. If you explain exactly how you want to forced I frame insertion to work, I can check it out. (ie do you just want to be able to specify the frame number of a frame you want to turn into an I frame?)

The code to force an I Frame would just look like:

...(some condition)...
s->pict_type = I_TYPE;
...


Too easy. It's probably possible to force it externally with QuEnc.

About MVs, dragongodz is right. The MV decision will most likely change for second pass as P references I and B references P. If the quality (quantiser) of an I frame changes, MVs change for P, and pass on to B. You could do it, but it would most likely come out far below optimal.

[RobertR]

Originally posted by Peter Cheat
Actually, this isn't hard to do at all. It is easy to force FFMPEG to use any frame type, for any frame you want. If you explain exactly how you want to forced I frame insertion to work, I can check it out. (ie do you just want to be able to specify the frame number of a frame you want to turn into an I frame?)

The code to force an I Frame would just look like:

...(some condition)...
s->pict_type = I_TYPE;
...


I'm assuming that it would be good to follow CCE behaviour on that part too. With CCE it's just matter of supplying list of frame numbers. (this would also help very much in my simple private project :D )
I've done some more testing of your changes to libavcodec/ffmpeg (please remember that i don't use windows). Unfortunately i was too stupid and let ffmpeg overwrite files from passes 1 to 3 (so i have no evidence of that spikes i wrote ealier). I did 7 passess of same VOB ID.
4th and 5th pass are almost equal in size (difference is about 500KB) and have avg bitrate just below targeted 3500kbit/s.
Strangely at 6th and 7th pass both bitrate and size went up (for 6th pass diff in size is around 1MB, for 7th pass - 30MB - which is 10% of file).
In all above cases q level in BitrateViewer is almost flat (fluctuances (?) are very small). In NuEnc at some pass it almost followed bitrate line (4th pass i think). I can;t reproduce this here. I'll post the pictures from bitrateviewer later and will edit this post to add url. Today and tomorow i'll try to do same tests with patched ffmpeg 0.49.pre1 (the same version that your patches are based).

EDIT:
Ouch! Big big sorry! I just spotted that i wrote about patched libavcodec in wrong thread :scared:
If i can be forgive just this time i'll leave my comments here. If not please let me know and i'll remove them and repost in proper thread.

[Guest]

Hi,
Any plans of adding sound to your great tool? avs -> m2v+m2a?
That would be super cool :)
Tin2tin

[Mug Funky]

dragongodz and peter cheat: thanks for the info. believe it or not, i understood it perfectly well. i suppose if it were that easy, everyone would be doing it :)

i eagerly await the next version :)

[DMagic1]

Can someone tell me how to solve this "AVS File is not outputting
(Use ConvertToYV12() at end of script" error with RB+QuEnc.

I saw someone else taking about the same problem but it did really get answered. ConvertToYV12() is in my script.

[Peter Cheat]

Originally posted by Guest
Hi,
Any plans of adding sound to your great tool? avs -> m2v+m2a?
That would be super cool :)
Tin2tin

I could write audio encoding and muxing into the code. If I have the time, I might do that and pass the sources onto dragongodz, if he is interested. Libavcodec can encode mp2 audio already, and it can mux, however, not to a system stream but a program stream. I don't imagine it would be hard to change though.

[dragongodz]

Nic decided not to use the mp2 encoding from avcodec because it is very basic and not the best quality. using TooLame would provide better.

[Trahald]

Originally posted by Peter Cheat
Going back a few posts...
Actually, this isn't hard to do at all. It is easy to force FFMPEG to use any frame type, for any frame you want. If you explain exactly how you want to forced I frame insertion to work, I can check it out. (ie do you just want to be able to specify the frame number of a frame you want to turn into an I frame?)

I would be greatly appreciative if possible.. As robert said, reading from a list file of the frame #s would work. oh.. and btw.. it would also have to be a new GOP, not just an i-frame ;)

[DMagic1]

Originally posted by DMagic1
Can someone tell me how to solve this "AVS File is not outputting
(Use ConvertToYV12() at end of script" error with RB+QuEnc.

I saw someone else taking about the same problem but it did really get answered. ConvertToYV12() is in my script.

Anybody?....

[dragongodz]

did you try playing the avs to see if it reports an error ?

also how many frames is it ? QuEnc wont handle smaller than 3 frames for 2 pass for example.

[DMagic1]

Its not small and it plays fine. CCE handels the script fine also.

[Peter Cheat]

Can you post your AVS script.
It might help to work out the problem.


I would be greatly appreciative if possible.. As robert said, reading from a list file of the frame #s would work. oh.. and btw.. it would also have to be a new GOP, not just an i-frame


Doesn't an I-frame automatically indicate the start of a new GOP (or do you mean that the previous GOP should be closed first)

[DMagic1]

#------------------
# AVS File Created by DVD Rebuilder
# VOBID:01, CELLID:03
#------------------
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MPEG2Dec3dg.dll")
mpeg2source("E:\NEW FOLDER\D2VAVS\V01.D2V")
trim(16678,22542)
ConvertToYV12()
AudioDub(BlankClip())

[DMagic1]

Hmm i may have solved my problem. Let me check...

**edit** no didn't work again.

[DMagic1]

Ok, this is weird.....

I don't get the add the ConvertToYV12()error when I use the avs script manually.

If I import the avs manully into QuEnc, set a bitrate, and click encode the app just closes. If I do the same thing but this time open the options, click apply without changing anything, and then click encode it starts encoding fine. :confused:

Whats going on here?

[dragongodz]

hmm sounds like the command line settings may not be workiing 100% for you.

hmm could be related to this maybe ?
http://forum.doom9.org/showthread.php?s=&threadid=81777

can you also post some information about your system ? what OS(+SP's), what cpu etc.

[Oldeman]

Dmagic,
try v.63a

[DMagic1]

WinXP SP2
2.8P4 800fsb
all standard MS controllers

[dragongodz]

as oldeman says, try DVD-RB 0.63a since i see other had similar problems with 0.63.
http://forum.doom9.org/showthread.php?s=&threadid=83369

if that doesnt fix it then we know theres something more.

[DMagic1]

Same errors with RB.

[Nic]

That's very strange DMagic. Hopefully the next release will help solve the issue.

(In the current release, almost any error in the input will provide a "YV12 Error" message, the new version gives a far more useful error ;) )

(Also I'm going to add optional debug logging to help with these sorts of problems)

The new release is pretty much done, just adding custom matrices in, then I'll release a beta before submitting it to jdobbs to see if he would want to include support for it in RB

-Nic

[dragongodz]

hmmm well as i said it appears to be the options are not being set. seeing what the actual command line is would help.

after you set the options by gui and it encodes ok have you tried quiting and then running QuEnc again and seeing if options has to be done again to encode ok ?

have you cleaned your registry lately ? it may be another thing worth doing. ok that may sound like its grasping at straws but every possibility needs to be checked. :D

[Nic]

By the way everyone:

If i'm going to add support of external matrix files...What format do people use? And where can I find links to examples :)

Cheers i'll add that in and release the new version.

-Nic

[dragongodz]

gee Nic now what a good idea that is. :D

2 posibilities that i can think of.
1. plain text with each line a line of the matrix, so 8 values per line, as generally shown in most programs and custom matrices posted here.
2.loading of an xvid matrix file. to create people would need to save from xvid is the down side i guess. up side being there are already ones for people to try.

[nwg]

I hope this hasn't been covered yet. What is Quenc's Scene detection ? I have just seen it in DVD-RB and wondered if I should be using it.

[horny_german]

Hello,

i noticed that Quenc likes to crash very often.
I used Quenc with DVD2SVCD and sometimes just as standalone encoder
with only a resizing script. Nothing special ...
Be Sweet encodes the audio and after this Quenc starts and crash without any obviusly reason.
The Quality I achieved were great with Quenc and even the speed is very satisfying !

Is this a generell problem or does this seem to be special problem of single PCs ?

I would use quenc as often as possible :D

Thanks
hg

I should mention that the encode process can be done with the same script after some tries but this isn't very satisfying while using DVD2SVCD ...

[Peter1234]

Nic,
FreeEnc uses an ini file to input the matrix. This seems like a simple way to do it. It is easy to have multiple matrixes and changing to a different matrix is done simply by selecting a different ini file. It also makes it easy to modify the matrix values.

[Bogalvator]

I come across the *.qmatrix format most often myself, so it would be nice if they were supported.

Can I suggest you include the MPEG quantisers as an option with QuEnc?

Very glad you're adding this feature by the way Nic. It truly will make QuEnc the premier MPEG-2 encoding program :)

[dragongodz]

FreeEnc uses an ini file to input the matrix. This seems like a simple way to do it.
the ini is simply a plain text file.

[dragongodz]

horny_german - let me guess, Pentium 4 right ? download and use the mem-aligned dll. the link to my page with it(5the QuEnc 0.54 page)is in the very first post of this thread.

[Trahald]

Originally posted by Peter Cheat

Doesn't an I-frame automatically indicate the start of a new GOP (or do you mean that the previous GOP should be closed first)

Nah.. you can have multiple I-frames in a gop.. a gop header is what separates gops. (they can be a opened gop or a closed gop). normally, the gop header is paired with a sequence header. the dvd will only chapter jump to places that have sequence headers so a chapter spot will always have a gop header/sequence header.. and with that always be on an i-frame.

[horny_german]

@ Dragongodz : Sorry I'd read the thread but this must I've missed.
Thank you for your help :) I try it right away
horny

[Trahald]

In trying to use quenc encoded files with scenarist (its a picky one) i tried lowering the max bitrate by 1000 below what i wanted and it still produced a stream that had some gops that peaked too high for scenarists tastes. is there a safe amount that i should go lower by - has any one tested this? im gonna go for 2000 lower the next time i do the test.. just wanting so input.

[Bogalvator]

Trahald, have you tried Peter Cheat's NuEnc? One of the things his modified code makes an effort to respect is max bitrate, so maybe it is worth a try.

[Peter Cheat]

It would be interesting to see if it helped.

[Trahald]

OK.. I'll give it a try.

[lithoc]

Since all DVD can handle interlace video, so intend to preserve my video in interlace.
I've encode a DVD 720x480 interlace video to CVD 352x480 interlace.

When I play the video in my DVD player. It looks weird as the the interlace artefact is very obvious in my TV.
It doesn't align with original DVD interlace video, which is very smooth.

I've enable Interlace in QuEnc.


My Avisynth script is very simple, I just use crop the extra 16 pixel & HorizontalReduceBy2()

Did I miss anything?

Thank in advance

[EpheMeroN]

This is probably a simple question but, does QuEnc output the brightness-darkness range of 16-235 by default since it's dealing with MPEG Video? Or do you still need to specify the range in a script?

[lithoc]

Sorry, if this issues is not related to Quenc.
I don't think it's due to brighness.
What I mean is, the DVD is in pure interlace, which view on my TV is look normal.
But once I convert it to 352x480 interlace. The interlace artifact somehow look like having trailing effect where look like 2 image display at once.

The question now is interlace, will resize destroy the interlace video info?

I just test it with my PC, it look ok.

Btw, I author it with IfoEdit. May be IfoEdit didn't specify the correct mpeg2 header?

[Mug Funky]

describe the effect you saw? i'm not sure from what you wrote whether you're referring to ghosting or stuttering, or some form of temporal problem (trails).

how is your video processed? Gknot? straight avisynth?

it sounds to me like blend-deinterlacing is happening somewhere.

resizing will destroy interlacing if the vertical size is changed at all. because i'm a little vague in my scripting, and might crop before deinterlacing without noticing, my resize statements look like this:

lanczosresize(352,last.height)

this means the vertical size wont be touched, and the interlacing stays intact.

preview in virtualdub before encoding just to be sure :)

[Peter Cheat]

Originally posted by EpheMeroN
This is probably a simple question but, does QuEnc output the brightness-darkness range of 16-235 by default since it's dealing with MPEG Video? Or do you still need to specify the range in a script?

QuEnc doesn't change the colour range. Use Limiter() in your avisynth script.

@lithoc
For resizing interlaced material, first seperate the fields (this will give you double the framerate) then resize, then weave the frames back together. If you just resize the interlaced material, and the resizing algorithm doesn't recognise it is interlaced, you'll end up with visible bars (which is what I think you are seeing).

[lithoc]

Thank you very much peter cheat.
I'll try it when I'm free.

how is your nuenc going on?
lastly, all the best in your exams

[hellgauss]

I think there something wrong in option setting....

I try to run quenc using cli, with this file bat:
quenc.exe -interlaced -i F:\Acquisizione\job\Temp\dmjob.avs -o f:\provampeg2.m2v -auto

The program open and close immediatelly

If i remove the -auto options, the main window is opened, but if i click encode it close

But if i click advanced settings and then close the advanced windows, and i click start the encode starts.

Sorry for my bad english :-)

HellGauss

[Bogalvator]

lithoc, perhaps you should see this thread aswell ;)
http://forum.doom9.org/showthread.php?s=&threadid=74906

[lithoc]

I don't think bobbing is needed cause for 720x480 > 352X480;
only horizontal is resize but the vertical line is keep. Anyway thanks for your links.

But I'm not sure if resize actually destroy the interlace video. Well, last resort will be FieldDeinterlace() :)

I think we should stop from here cause it's already off-topic.

[hellgauss]

I think that when Quenc is normally run, or when the advanced dialog is opened, happens something that doesn't happen when quenc is launch using a file bat. I try to look to source, but i don't find the problem. Also i try to compile quenc to try to debug, but i'm not able to compile ffdshow with my compiler....

However before the app close, it appears (it's less than a second) the label 'Stop' Instead of the label 'Encode' In the left button.

[dragongodz]

the label 'Stop' Instead of the label 'Encode' In the left button.
which means its starting to encode and then for whatever reason failing.

see it sounds like the settings are not being set when you are running from CLI. i will have to try your example out and see what happens.

[EDIT]
ok just tested and i couldnt reproduce your problem. it worked fine.

[hellgauss]

I do some other tests, the bug is not always reproducible.
Some times the encode don't starts, sometime yes.

However the encode always start if i click the advanced button or IF I CLOSE THE DOS WINDOW OF THE BAT FILE.

It seems that closing the dos window has the same effect of click the advanced button.

Maybe windows sometimes think that is the bat file to call the encodinc process, not quenc.

I have win XP with SP2, p4 1.7GHz mobile, 512MB ram.
Bat file is in the same dir of Quenc

[dragongodz]

p4 1.7GHz mobile
i assume you replaced the normal avcodec.dll with them mem aligned version ?

[hellgauss]

No, i thought that the included avcodec.dll was already the fixed one. I didn't think to it because the GUI works well. I replace and seem to be ok (i will do more test, however).

Thanks

[dragongodz]

i didnt change it because a lot have already downloaded it and it may confuse people if i start messing with it.
also Nic will be releasing a new version when he gets the time so i thought it shouldnt be too much of a bother for too long. boy was i wrong. :)

[freewheeling]

here's another download link: http://www.doom9.org/Soft21/Encoders/MPEG2/QuEnc052.zip
Neither of these download links works. This one just gives a 404 error, and the one above just forwards to a different site that looks like some kind of scam. Could you post a link that works please?

[manolito]

Videohelp.com has versions 0.54, 0.71 and 0.72

Cheers
manolito