Yes.Yes.

-kwag

It's a damn shame that MEncoder doesn't give the timestamp where the underflows occur. I just finished the encoding process and there's some 20-30 underflow errors 8O I'll try authoring a DVD in Maestro and see if it complains anything.

According to Bitrate Viewer the Q level is very low but I don't know if it can be trusted one bit since the Q values are sometimes below zero. Also the average bitrate isn't nearly correct.

8O
I haven't seen that on any of my encodes :!:
The Q line is always above the bitrate line.
Could it be related to resulutions, or to PAL :?:
You are encoding PAL, right :?:

I've encoded 704x480 and also 352x480, and burned as SVCD and as DVD, and I haven't seen any more underflows. At least since I started using the noise parameter.

-kwag

I'm in PAL zone, and I have seen Q lines below 0 too.

I often get Qs between 0 and 1 (below zero doesnt exist (IMHO) in BV) ... thats if a high avg bitrate is used and therefore even less quantization was needed.

IF you would rise the lmin that would mean even higher quantisation and therefore even LESS bitrate at those parts.

The Q curve in BV ONLY shows if (and now my english) many same values came out after the Inverse DCT transforming .... means good RLE compression. BUT that means nothing according to the real quality when quantizing was done by the encoder.

I do have streams from CCE TmpgEnc and mencoder at the beginning of our tests .... TmpgEnc got an Q avg of aprox. 5-6, CCE 4-5 and MEncoder 2-3 ... and ALL looked almost the same in their quality.... that was before doing tweaking the parameters of mencoder

Well, maybe we have gone off topic...
... but I'm also in PAL country, and never had quantizers below 0. It's even difficult for me to find quantizers below 1.
As Inc says, maybe too high average bitrates and too low lmin values?(not in general, but in certain films maybe it's not necessary lmin=0.3...)

I hope you all understand that well .... ;-)

Buffer underflow means bitratedrops (shure you know that)

BUT the less you quantisize (less q!), the higher the bitrate gets, logic?

So IF you suffer from too much drops of bitrate, that would mean at these scenes you need to allocate less quantization so more bitarte will come out.
Im not shure but IMHO less lmin should sove that .... well thats the logic, .. but it seems it also affects the whole bitrate curve (not Q curve only).

So dont mix Q curve with bitrate curve ... they are nearly the opposite.

And I checked in BV ... a Q lower than zero doesnt exist it goes in the Y axis from zero up to X ...

@Boulder: Have you a pic. I don't have anymore that mpg with BV negative Q curve.

@Inc.: You don't see the curve below 0, but you can see that Q curve is broken at basal line, it dissapear in one point and come back in other point little bit away from first point. I don't keep cursor over this point to check out values in Q info values.

Inc,

My second attempt with pack-shot is full of underflow !
I didn't change anythign since the previous one and the kind of source is the same (I do the sequel of the previous movie !)

What do you mean, same source, nothing changed??
That would mean you deal with an abitary behavior of mencoder?

8O

Ok, now I understand .... and "that" never happend to me

Ok guys, I'll get the pictures for you shortly.

DVDMaestro didn't complain anything so the encode should be ok. Funny how the bitrate can get too low as I encoded the movie as anamorphic and there are only small borders so it's basically a fullscreen encode. I also encoded Blade Runner as anamorphic and that movie has an AR of 2.35:1 but it didn't cause any underflows.

No, it's not the same source ! I did 'Blade', I'm doing now 'Blade 2'.

What I wanted to say is that the 2 sources are very similar in words of quality / complexity / actionness / length / ...


[/quote]

All right, here's the screenshot:

http://www.digitalfaq.com/archives/error.gif

The Q value at that point is -0.29, the green color gets all messed up with JPG compression :x

You seems to use a registered version of the tool, don't you ?

Try to install in an other directory the non registered versoin. And open again the same m2v.

It seems that bitrateviewer has a stange behaviour once registered.

Well that case in here shows me really the "issue" of BV according to Q values!

Dont trust them!!!!
(It doesnt make sense discussing Q values of BV as very big issues of BV according to Q are known ;-) )

Also there BV does say "Linear Quantizer Scale" ... but as you see its not! :lol:

So, watch the stream, ... do decide if it results good or bad ... and the only thing I would give notice if there are BITRATE (not Q) peaks or drops outside DVD compilancy, ... but even encodes including some BITRATEdrops down to 150kbit do play very well on my SAP (maybe in reality they arent that low! - or my SAP tolerates this. And if you do apply some noise as Kwag told, the issue is even less present.

BTW. Karl told me as he did noise tests also using a smash factor of 99 means full of big noise, ... the noise generating was performet only on the effective movie area, ... so if you input a 2.35:1 source where still borders even at anamorph source state do exist, these borders - it seems - that they wont be touched by the noise generating.

(EDIT: Answering to Phil)
That seems to be the case. The weird thing is that the curve CCE-encoded video gives is not like the one that MEncoder gives when using the registered version.

The MEncoder stream is also encoded with a linear quantizer scale?!

@Inc: I used AVS to crop, filter and resize and then MEncoder's noise (3th) before expanding so the noise is certainly only in the film pixel area.

Hey Boulder ;-)

I just edited my post above and added the "quantizer scale" issue of BV.


Resumeé .... BV is maybe nice, does look nice ... seems to be nice ... but I dont wanna trust him anymore ... defenitely not in case of Q and also I dont trust him "that much" in case of Bitrates. :?

Go and do an encode a mpeg1 at "linear Quant scale" using CCE 2.5 .. and a low flatline Q will output ... but the stream for shure wont look better in relation of a non linear one where Q iss more above. I tested it ;-)

Maybe there will be a new appl. released soon which gives more trustable outputs



-------------

Boulder, Im at work so I only assume:

Try modifying the BIAS as in regular the BIAS is responsable also for Bitrateallocations as we know from multipass CCE tweaking.

Do generate an AVS based input, using a sampler() or better Slicer() cutted output .... there you can see very fast how this affects the Bitratecurve. Do start cutting right from frame 0! As there the most black parts will be present :)

@boulder
i'm a bit confused.
- ur screenshot shows vbv=112. it's for svcd ... but u wrote u'r making dvd. how's it going ?
- it seems as if ur max & target bitrate were the same (~2500). if so why not a cbr=2500 ? (much safer)
- in my experience, if target bitrate is 'too close' to the max this 'underflow business' kicks in after awhile. if keeping max precisely is not a big issue, u should raise (or leave out) max.
anyway, this warning is just a warning. it does not bite. it simply means there's not enough bit in the buffer to feed a sudden bitrate peak.
- why do u bother about borders ? pioneers are pretty well with anamorphic shots. (or am i misinformed ?)

@inc
- imho, the bias values has nothing to do with mpeg2 here. they are mpeg4 related. (the manpage is quite unreliable with respect to distinguising the option types properly)
- adding noise does not necessarily means higher bitrate. the codec can circumvent this by raising the qantizer level. the other way round is changing the macroblock quantizers and keeping (more or less) the same frame quantizer. imho, this process is quite unpredictable. if we consider plain black frames it's a bit simpler but here we talk about clips/movies.
- bv is not as bad as u state. it's not as accurate as can be but what i've seen from it seemed to be quite reliable. (i used only the freeware versions so i don't know how it worx if it's paid :-))

Based on my experiences, BV shows the VBV buffer value incorrectly. It's always double in reality.

Nope, target bitrate was 3069kbps and the max 5000kbps.

And this often causes problems with standalone players.

Overscan, man, overscan :wink: