NuEnc 0.00d & Libavcodec improvements/suggestions

[dragongodz]

Do you understand what maximum bitrate means? I think not
do you know what a smart arse who thinks he knows more than everyone else is ?
you can keep your opinions of what you think i do or do not know to yourself because i am quite sick of being nice when reading such rubbish. :angry:

a couple of quotes for you
Now some bright spark is going to point out that for a DVD player to be compliant it "must be able to sustain a bitrate of 9800kbits/s for an indefinite amount of time". This is the maximum bitrate at which the video is read from a DVD. This is really only relevant for CBR encoding at 9800kbits/s
wrong, it is relevant for VBR aswell. go to the DVD-Rebuilder section and tell those people who had bitrates exceed 9800Kb/s VBR(using CCE i may add) that their playback problems are irrelevant and see what they say to you.

a buffer underflow can also be interpreted as a maximum bitrate exceedtion
really ? but isnt that irrelevant ? :devil:

let me end by saying that yes i already knew what an underflow was. i also know from my own and others on this forum real life experience of what works and what doesnt. you provided information yourself that said the svcd over 2500Kb/s VBR caused stuttering in hardware players. i point to the DVD-RB forum to show you the same with dvd. now if you want to ignore that well thats up to you.

am i mad this morning ? yes actually i am not in a happy mood and so to any that read this and are insulted/shocked/whatever well sorry but a person patience lasts only so long. i will not bother to post about this again since even with my years of experience i seem to know f*ck all.

[Peter Cheat]

As I said, you have misinterpreted maximum bitrate. Thats the whole confusion dammit. When I said a buffer underflow CAN be interpreted as a maximum bitrate exceedtion, I meant that the DVD/CD needs to go faster than it is capable of to keep the flow of data going. CBR encoding is a special case of VBR. What I have written is not opinionative. It is complete fact straight from the MPEG-2 draft, a subset of DVD and SVCD. See pages 170-175 in the draft specification. I recommend you spend the time to actually read it before replying and making a total fool of yourself. This (http://www.ee.columbia.edu/~eleft/e6880-Spring98/docs/is138182.pdf) document is not opinionative it is the standard. I spent 6 hours reading the ENTIRE document. I've looked at the code for mpeg2enc. I'm 100% sure I understand the standard. Maximum bitrate 9800kbits/s or 2520kbits/s is the maximum datarate at which the medium can be read. It is not the maxiumim data rate of the decoded stream. Thats a fact. I can bet that those streams with playback problems suffered buffer underflows.

I wrote in the document:

Now some bright spark is going to point out that for a DVD player to be compliant it "must be able to sustain a bitrate of 9800kbits/s for an indefinite amount of time". This is the maximum bitrate at which the video is read from a DVD. This is really only relevant for CBR encoding at 9800kbits/s


Sustaining a bitrate of 9800kbit/s per second for an indefinite period MEANS CBR. It means that the minimum bitrate = maximum bitrate. This statement from mpeg.org is relevant ONLY for CBR, where VBR minimum bitrate < maximum bitrate.

Originally posted by dragongodz
wrong, it is relevant for VBR aswell. go to the DVD-Rebuilder section and tell those people who had bitrates exceed 9800Kb/s VBR(using CCE i may add) that their playback problems are irrelevant and see what they say to you.


You will find that I am right on this. CBR is a special case of VBR where minimum rate = maximum bitrate. They reason why a DVD Player (drive) must be able to sustain a bitrate of 9800kbits/s so it is able to play material encoded at 9800kbits/s CBR. In CBR, if the buffer somehow starts becoming empty (wandering laser?) there is no chance in hell of playing a 9800kbits/s CBR encoded DVD without underflow. And underflows DO NOT make a stream non-compliant. Part of the specs states that a decoder must repeat the last decoded frame in the case of buffer underflow until the next frame is available. I could quote 100 pages from the specifications, but that would be a waste of time.

How A DVD Player Works
-----------------------
[DATA READ FROM DISC AT MAX OF 10.08MBPS(9800kbits/s for video)]
This data goes to the buffer, as it is IMPOSSIBLE to decode an MPEG-2 stream on the fly because of B frames (you need the next frame before you can decode the current one), and decoder lag.
[DATA IS LOADED ONTO VBV BUFFER (224KB MAX for DVD)]
Only complete frames/fields can be stored on the buffer
[DATA IS TRANSFERRED FROM BUFFER TO DECODER]
The maximum datarate to the decoder is 15MBits/s as specified by the MP@ML profile. This is the ABSOLUTE MAXIMUM BITRATE for MPEG-2 to be MP@ML compliant and hence DVD compliant. I've not been able to get any encoder to encode at that data rate using MP@ML profile.
[DATA IS DECODED AND FRAMES ARRANGED IN CORRECT ORDER]
[DATA GOES TO OUTPUTS (ANALOGUE/DIGITAL)]

Originally posted by dragongodz
am i mad this morning ? yes actually i am not in a happy mood and so to any that read this and are insulted/shocked/whatever well sorry but a person patience lasts only so long. i will not bother to post about this again since even with my years of experience i seem to know f*ck all.


Don't take it out on me. I've asked you and others to tell me how to implement rate control. NO one gave me any specifics about the standard. So I went fishing for information and found drafts for many standards including MPEG1, MPEG2, MPEG4, MP2, MP3 etc. Since MPEG-2 is a subset of DVD (the video part) and DVD is specifically MP@ML profile, I was able to figure out the video standard required exactly. As it turns out, LIBAVCODEC was always producing compliant streams, it just created a lot of buffer underflows which results to jerky playback. I am a computer systems engineering student. MPEG-2 encoding and decoding is part of my future profession. I know I am right, whether you think so or not is quite irrelevant. Anyone who reads the MPEG-2 specifications and understands them will agree with me. Whether you reply to this or not is irrelevant really. (An apology for your arrogance would however be accepted.)

Problems with CCE aren't really surprising. What buffer size does it use? You do not specify it. CCE probably just makes a guess depending on the maximum bitrate you specify, just like TMPEnc does when you specify a buffer size of 0 (automatic). You can't change it in CCE, and it is not documented, but it is very important for encoding MPEG-2 for DVD.

[Nic]

Lets try and keep things friendly guys :) No need to get upset over interpretations of a specification...

The way I interpret things is as follows;

1) The MPEG-2 Spec is really the superset of the DVD spec, the DVD spec is a restricted subset of the MPEG-2 spec. Therefore an MP@ML stream != a compliant DVD Stream (although of course the two have a lot of similarities)

2) As far as I can see, a DVD Player only needs to be able to read a maximum of 9800kbps. If the bitrate for a seconds worth of video exceeds 9800kbps, will not the buffer underflow as the DVD drive will not be able to read the data fast enough?

3) Buffer underflows may be spec compliant (Although I'm not sure of this, that makes no sense to me why they'd allow such things (?)), but they must be highly undesirable if it causes the decoder to repeat the current frame instead of showing the correct frame. So surely it is better to keep the bitrate under 9800kbps ?

I may, of course, be completely wrong, but that is the way I've interpreted things. But please correct me if I'm wrong, especially if you can back it up with documents/proof (although I know that will be hard as the DVD specs aren't widely available)

Cheers and keep the tone as civilised as possible please, I'd hate to have to close this thread,

-Nic

[dragongodz]

since you ask Nic then i provide this
http://www.mpeg.org/MPEG/DVD/Book_B/Video.html

the relevant parts from that are...
DVD adds many additional restrictions to the popular compliance parameter sets of MPEG. One good example is the restriction on the coded size of a picture: MPEG-2 Main Profile @ Main Level allows any coded frame size between 16 and 720 pixels horizontally and 16 and 576 pixels vertically. DVD, however, restricts the coded frame sizes to a very limited but practical subset.
MPEG is a generic representation meant for a wide variety of applications. DVD has taken a practical subset to promote interoperability by simplifying implementations and insuring features (such as random accessibility).
dvd is a restricted subset of MP@ML, they are not the same.

The maximum bitrate of 9.8 Mbit/sec is more restrictive than MP@ML's 15 Mbit/sec limit.
ALL DVD PLAYERS MUST SUSTAIN A 9.8 MBIT/SEC VIDEO DECODE RATE!!!!!!! Hardwired (Application Specific Integrated Circuits---ASICs) implementations of MPEG-2 MP@ML decoders are generally capable of handling 15 mbit/sec sustained rates.
the max bitrate for dvd(decoding aswell as reading) is 9800Kb/s. so if thats what you set the max bitrate in a program that is what it should be restricted to(MaxKb/s).

when asked i HAVE said that many times. people should read back through this thread and the QuEnc thread if they doubt i have said these things about implamenting rate control. i try to help people all the time, but i do not appreciate people asserting that i am a fool or arrogant and have not tried to help them when i have. i have been very patient about them questioning what i do or do not know. especially when they then claim only they know the truth and then expect me to apologise.

sorry but my patience has run out with this. believe me and that page from mpeg.org or not, people can make their own minds up. i dont intend to keep banging my head against a brick wall and be insulted for it.

[hank315]

Still have a question about the max. DVD bitrate of 9.8 Mbit/s.
Is it so that the sum of the last 25 or 29.97 frames must be less than 9.8 Mbit or is another time frame used to calculate the max. bitrate.
Or, simply put, how many frames do you need to correctly calculate the bitrate of a stream?

[mean]

You can compute an average bitrate using 1/2 sec before & after the current point but you'll only get a approximation of the real thing,
i.e. the vbv buffer fullness.

I tried that some months ago, but it does not it prevent underflow completly.

@Peter :

Did you improve the frame eviction method from vbv_buffer ?
Especially for interlaced encoding ?

My wish list would be a 2 pass engine for lavcodec separated from lavcodec itself.
It is not too hard to do (did it, reusing some ideas of you like the compressibility stuff, but it is very basic) .

The main advantage would be that it can co-exist with lavcodec and be used by most applications that are lavcodec based (mplayer, transcode and al) while keeping the existing lavcodec ratecontrol that works well for mpeg4 with almost no constraint.

As a bonus, you'd be relatively immune to lavcodec internal change.


You code as of today is *very* interesting, but using it in most general purpose application would more or less mean dropping 2 pass for mpeg4
(and merging with lavcodec changes can be tiedous)


I believe you mainly need Qp, frame type and frame size as information for both passes and that can be get/set externally from lavcodec.

Correct me if i'm wrong.

[Peter Cheat]

Originally posted by Nic
Lets try and keep things friendly guys :) No need to get upset over interpretations of a specification...

The way I interpret things is as follows;

1) The MPEG-2 Spec is really the superset of the DVD spec, the DVD spec is a restricted subset of the MPEG-2 spec. Therefore an MP@ML stream != a compliant DVD Stream (although of course the two have a lot of similarities)

2) As far as I can see, a DVD Player only needs to be able to read a maximum of 9800kbps. If the bitrate for a seconds worth of video exceeds 9800kbps, will not the buffer underflow as the DVD drive will not be able to read the data fast enough?

3) Buffer underflows may be spec compliant (Although I'm not sure of this, that makes no sense to me why they'd allow such things (?)), but they must be highly undesirable if it causes the decoder to repeat the current frame instead of showing the correct frame. So surely it is better to keep the bitrate under 9800kbps ?

Lets say 1 second (25 frames) of video in VBR goes up to 11Mbits/s.
Assume the buffer starts full at 224KB=1792kbits.
(just say each frame is 440kbits for simplicity)
Frame 1=440kbits Buffer goes down to 1352kbits, but the data is read at 9800kbit/s=392kbits so the buffer holds 1744kbits. No underflow.
Frame 2=...buffer has 1696kbits
Frame 3=...buffer has 1648kbits
...
Frame 25=...buffer has 592bits (but may have gone down to 152kbits)
but no underflow occured, therefore will playback fine. That assumes a progressive film, and that the next frame will not cause underflow (if it is >592kbits it will). Thats the maths taken care of. (From the MPEG-2 draft, or any open source mpeg-2 encoder.)

The buffer allows for frames to exceed that maximum bitrate, thats what its for. It says so in the draft (its for big frames). Without a buffer, DVD decoder would continuosly stutter because frames are not in the right order in a bitstream. They have to be put onto the buffer, put in the right order and decoded. P frames rely on I frames, B frames rely in P frames (and I frames?).

9800kbit/s refers to the bitrate the DVD is read at. A DVD is read at 10.8Mbits (from memory). In the case of DVD video, 9.8Mbit/s was assigned for video and 1 Mbit/s for audio.

The restriction added to MP@ML is:
9800kbit/s maximum bitrate <- check it the draft as what this means. It was reduced from 15Mbits/s cause 1x DVD is only 9800kbits/s.

The VBV buffer size is the same 112 buffer size or 224KB.

I have put the link for the draft, and the pages that are relevant to maximum bitrate and VBV buffer (page 170 i think). I do recommend reading it, as it explains the context of maximum bitrate. Please read it.

I've read heaps of material, and I've pointed to the most important information. Just read what maximum bitrate means. It says exactly what it is in the MPEG-2 specs. The proof is here (http://www.ee.columbia.edu/~eleft/e6880-Spring98/docs/is138182.pdf). Pages 170-175. Thats the proof.

MPEG-2 is a SUB-SET of DVD. Audio is another sub-set the format is another sub-set. These sub-sets make a full set accepted as DVD video. The fact that a sub-set has some restrictions doesn't change it from being a sub-set.

@mean
I am working on a better VBV model (to consider interlacing/telecined content). MPEG-4 works very well with the last update (try it yourself, but you'll have to compile from source). My method looks at the future 10 frames and their predicted size and removes them from the buffer while adding the required datarate. If the mock buffer underflows, the quant increases by one, it is then checked again. This is why the encode is a little slower. This reduces buffer underflows completely, (for the model I am using) provided the prediction is good. Hence why I improved the prediction. The alternative is to pretend you have say half a buffer, then if it goes over, no problem, the real buffer is twice as big. My code checks for underflows twice. It should stop them 99% of the time.

Originally posted by dragongodz
the max bitrate for dvd(decoding aswell as reading) is 9800Kb/s. so if thats what you set the max bitrate in a program that is what it should be restricted to(MaxKb/s).
It is not a decoding limit. It is a reading limit. See the aforementioned document. It is in there. If they wanted to restrict the decoding limit, why do you need a buffer (well for decoder lag) but why do you need such a big buffer. From the document "for a big frame" where big frame = I frame.

and again "ALL DVD PLAYERS MUST SUSTAIN A 9.8 MBIT/SEC VIDEO DECODE RATE!!!!!!!" = CBR, I've explained this one before.

From Page 49 of the MPEG-2 Stardard draft
(refferring to the bitrate written in the stream)
bit_rate - This is a 30-bit integer. The lower 18 bits of the integer are in bit_rate_value and the upper 12 bits are in bit_rate_extension. bit_rate is measured in units of 400 bits/second, rounded upwards. The value zero is forbidden. The bitrate specified bounds the maximum rate of operation of the VBV as defined in C.3 of annex C. The VBV operates in one of two modes depending on the coded values in vbv_delay. In all cases (both constant and variable bitrate operation) <b>the bitrate specified shall be the upper bound of the rate at which the coded data is supplied to the input of the VBV<b>.
NOTE - Since constant bitrate operation is simply a special case of variable bitrate operation there is
no requirement that the value of bit_rate is the actual bitrate at which the data is supplied. However it is recommended in the case of constant bitrate operation that bit_rate should represent the actual bitrate.

The maximum bitrate refers to the maximum bitrate going into the VBV buffer, NOT THE DECODED STREAM, not the maximum bitrate of the decoded stream! The bitrate specified in the stream is not necessarily the average bitrate, it is the maximum bitrate. In the case of CBR min=average=max. In the case of VBR, the maximum bitrate is the bitrate required to decode the stream without underflow. Not the maximum bitrate of the decoded stream. This applies to all MPEG-2 applications. Its just what maximum bitrate means in MPEG-2. MPEG-1 is the same, but VCDs are CBR, so bitrate in and out is roughly the same but it still applies.

I'm not trying to have a go at anyone, I didn't know this either. I wanted to know, found the right answer and I am telling all of you. Saying that this is all rubbish (@dragongodz:rolleyes: ) is simply not true. It seems no matter what information I provide, I am wrong. Why? Because I have only been encoding for hardware players for two years? I assure you the information I am providing is 100% correct. I spent 6 hours reading the whole document. It is boring. But I did it.

[dragongodz]

your biggest mistake is thinking that draft is dvd specs. it is not. mpeg2 specs encompass much more than dvd. dvd uses 1 subset of mpeg2 and adds its own tighter restrictions.

and again "ALL DVD PLAYERS MUST SUSTAIN A 9.8 MBIT/SEC VIDEO DECODE RATE!!!!!!!" = CBR, I've explained this one before.
and i disagree as i did before. a VBR stream can have a 9.8 Mb/sec section for more than 1 second. that does not make it suddenly a CBR stream. however if it exceeds the 9.8Mb/sec for over a second it will underflow and cause playback issues and be out of spec.

It is not a decoding limit. It is a reading limit. See the aforementioned document. It is in there. If they wanted to restrict the decoding limit, why do you need a buffer (well for decoder lag) but why do you need such a big buffer. From the document "for a big frame" where big frame = I frame.
note i said max bitrate per second and not per frame. so your arguement about a "big frame" in no way makes the per second limit different.

I wanted to know, found the right answer and I am telling all of you. Saying that this is all rubbish (@dragongodz ) is simply not true
and i say you did not get it right. you mistook MP@ML as being dvd specs when they are not exactly the same. in your last post you finally even show 1 of the restrictions added to MP@ML for dvd specs even though in earlier posts you quite happily say
This is the ABSOLUTE MAXIMUM BITRATE for MPEG-2 to be MP@ML compliant and hence DVD compliant.
you say reading only while i say both reading and decoding. infact tell me why you would have a max bitrate setting in an encoder if it is not to be adhered to.
and lets get it staight, when i said rubbish i was refering to you constantly questioning whether i know even the basics of video encoding/decoding. i even quoted it right before it so everyone could tell what i was refering to. do not try and make it seem like i was talking about anything else. your posts on what you think is max bitrate etc i have simply disagreed with.

It seems no matter what information I provide, I am wrong. Why? Because I have only been encoding for hardware players for two years? I assure you the information I am providing is 100% correct.
so someone disagrees with you and even provides proof of their own(including experiences people are actually having and 1 of your own quotes(the svcd one)) but that doesnt mean you could be wrong ?
as for saying how long you have been encoding, thats irrelevant. there are people on this forum who have been encoding for years who do not even know what VBV stands for let alone what its used for. do you really think i would be posting back and forth to you like this if i thought you were an idiot ? its YOU that has several times questioned my knowledge on basics. now whys that ?

since you were willing to spend all that time reading that document you should not mind reading this 1 little page aswell.
http://www.mpeg.org/MPEG/DVD/Book_B/Video.html
i would think mpeg.org would have some idea what they are talking about.

[johnnyquid]

Just my two cents worth. Be gentle ;)

From a practical standpoint it would seem to me that arguing over this is pointless. Since output stream bitrates over 9.8 MB/sec (or even lower) do not improve the final picture quality much it would seem to me that a good VBR rate control would not waste bits creating them. Doing so would also get rid of users always asking why bitrate viewer (or other tool) is showing something that they think (rightly or wrongly, I do not want to take a side here) is not DVD compliant. Other programs/hardware may also assume the output bitrate will not exceed 9.8 MB/sec so not doing so may improve compatability.

[Peter Cheat]

Originally posted by johnnyquid
Just my two cents worth. Be gentle ;)

From a practical standpoint it would seem to me that arguing over this is pointless. Since output stream bitrates over 9.8 MB/sec (or even lower) do not improve the final picture quality much it would seem to me that a good VBR rate control would not waste bits creating them. Doing so would also get rid of users always asking why bitrate viewer (or other tool) is showing something that they think (rightly or wrongly, I do not want to take a side here) is not DVD compliant. Other programs/hardware may also assume the output bitrate will not exceed 9.8 MB/sec so not doing so may improve compatability.

A stream exceeding 9.8Mbit/s on input to the VBV buffer is still DVD compliant. A restriction on the input bitrate was decreased for DVD to 9800kbit/s. If a buffer underflow occurs, the previous frame is repeated. If MPEG-2 standards expect this to occur, and there is no mention of the change in the DVD specs, then it will be the same as MPEG-2.

[dragongodz]

A stream exceeding 9.8Mbit/s on input to the VBV buffer is still DVD compliant.
can you show any documents that say that ?

A restriction on the input bitrate was decreased for DVD to 9800kbit/s
it is also the only limit mentioned for decoding as also already said ad-infinitum. nowhere does specific to dvd docs(meaning not general mpeg) say max 9800 for CBR but can be higher for VBR. again, show me a document that does.

If a buffer underflow occurs, the previous frame is repeated. If MPEG-2 standards expect this to occur, and there is no mention of the change in the DVD specs, then it will be the same as MPEG-2.
which will cause non-smooth playback. so even if it is handled it is not desirable in any way.

[hank315]

Some more remarks about 9800 kbit/s, DVD read speed and VBV buffer underflow....


posted by Peter Cheat:
Lets say 1 second (25 frames) of video in VBR goes up to 11Mbits/s.
Assume the buffer starts full at 224KB=1792kbits.
(just say each frame is 440kbits for simplicity)
Frame 1=440kbits Buffer goes down to 1352kbits, but the data is read at 9800kbit/s=392kbits so the buffer holds 1744kbits. No underflow.
Frame 2=...buffer has 1696kbits
Frame 3=...buffer has 1648kbits
...
Frame 25=...buffer has 592bits (but may have gone down to 152kbits)
but no underflow occured, therefore will playback fine. That assumes a progressive film, and that the next frame will not cause underflow (if it is >592kbits it will). Thats the maths taken care of. (From the MPEG-2 draft, or any open source mpeg-2 encoder.)

But suppose we have a constant bitstream with frames of 200 kbits, 12 frames of 592 kbits and again a constant bitstream of 200 kbit frames.
The maths of this show a constant bitstream of 5000 kbit/s and 9704 kbit/s during the time of the 12 592 kbits frames if the average bitrate value is calculated every second.
This is below the "magic" 9800 kbit/s so it seems ok.

Assume we have a full VBV buffer at the start of the 12 'large' 592 kbits frames, from this point the buffer will be emptied with 592 kbits per frame and will be filled with the maximum read speed of 392 kbits per frame so after approx. 9 frames the VBV buffer will be empty, underflow will occur and previous frames will be repeated.

This shows a bitstream which would show "DVD compliant" (regarding bitstream) in programs like BitRate Viewer could cause serious buffer underflow, these programs are only applicable for bitstreams which are CBR or "mild" VBR.
For VBR where V is really *very* variable the only way to prevent buffer underflow is to simulate the behaviour of the VBV and correct the bitstream for underflow.

[Peter Cheat]

Originally posted by hank315
Some more remarks about 9800 kbit/s, DVD read speed and VBV buffer underflow....


But suppose we have a constant bitstream with frames of 200 kbits, 12 frames of 592 kbits and again a constant bitstream of 200 kbit frames.
The maths of this show a constant bitstream of 5000 kbit/s and 9704 kbit/s during the time of the 12 592 kbits frames if the average bitrate value is calculated every second.
This is below the "magic" 9800 kbit/s so it seems ok.

Assume we have a full VBV buffer at the start of the 12 'large' 592 kbits frames, from this point the buffer will be emptied with 592 kbits per frame and will be filled with the maximum read speed of 392 kbits per frame so after approx. 9 frames the VBV buffer will be empty, underflow will occur and previous frames will be repeated.

This shows a bitstream which would show "DVD compliant" (regarding bitstream) in programs like BitRate Viewer could cause serious buffer underflow, these programs are only applicable for bitstreams which are CBR or "mild" VBR.
For VBR where V is really *very* variable the only way to prevent buffer underflow is to simulate the behaviour of the VBV and correct the bitstream for underflow.

Your example is spot on. Bitrate Viewer cant tell you if your stream will have problems the way it is implemented.

Simulating a VBV and looking for potential buffer underflows is really the only way to stop underflows correctly. This is what I've tried to implement. As long as the predictor is accurate, no underflows will occur, provided the model used is accurate. However, currently it is not. It is accurate for MPEG-1, but not MPEG-2 interlaced/3:2 Pulldown. I am working on a better model.

[Peter Cheat]

Originally posted by dragongodz
can you show any documents that say that ?


it is also the only limit mentioned for decoding as also already said ad-infinitum. nowhere does specific to dvd docs(meaning not general mpeg) say max 9800 for CBR but can be higher for VBR. again, show me a document that does.


which will cause non-smooth playback. so even if it is handled it is not desirable in any way.

Looking at it in pseudo code:

MP@ML Standard {
max_bitrate = 15000000 bits
VBV_buffer_size = 1835008 bits
max_gop_size = INFINITE
low_delay = can be 0 or 1, 1 (indicates no buffer delay, ie no B's)
aspect_ratio = one of (1:1, 4:3, 16:9, 2.21:1 and some reserved?)
frame_rate = one of (23.976, 24, 25, 29.97, 30, 50, 59.94, 60 and reserved?))

//probably other relevant restrictions I've missed (resolutions)
}

DVD Standard {
import MP@ML Standard
import DVD Audio Standard
import Disc Format Standard

MP@M->max_bitrate = 9800000 bits
MP@ML->max_gop_size = if PAL 15 otherwise 18
MP@ML->low.delay = 0 //must be zero by DVD specs
MP@ML->aspect_ratio = 4:3 or 16:9 only!
MP@ML->frame_rate = 29.97 or 25 only!

//any other differences not mentioned
//any changes from other standards
}

The maximum bitrate still has the same definition as the MPEG-2 standard. The bitrate of the decoded stream is not limited to 9800kbit/s, it is limited by 9800kbit/s. These both mean something completely different (isn't english a funny language). If you have a 9,800,001bit/s CBR stream, it will play correctly in EVERY COMPLIANT DVD PLAYER for 1835008 frames, or 73400.32 seconds (@25fps), which is over 20 hours. A DVD player must be able to play 9800kbit/s NON-STOP FOREVER (for an indefinite amount of time).

When you consider VBR, the bitrate is no longer 9800kbit/s constantly, but changing. When the bitrate is below 9800kbit/s (say 4000kbit/s), the buffer can be filled up (at 5800kbit/s until full). When the bitrate exceeds 9800kbit/s (say 11,000kbit/s) the buffer is drained (at 1,200kbit/s). This is ok, as long as the buffer isn't drained until it is empty. If it is emptied, the decoder cannot get the next frame, as it is not on the buffer, and the last frame is displayed until the next frame is available.

For VBR, you can't possibly have an average bitrate over 9800kbit/s and have it play indefinitely. But you can easily have an average bitrate of 9800kbit/s. Thats the limitation. It's actually the average bitrate of the stream that is limited by 9800kbit/s, not really the maximum bitrate. However, the maximum instantaneous bitrate of the stream can be up to 1835008bits without underflow (the size of the buffer, assuming no b-frame lag).

A stream exceeding 9.8Mbit/s on input to the VBV buffer is still DVD compliant. The MP@ML standard requires the last frame to be repeated until the next frame is ready on the buffer. Because it must be able to handle such an undesirable situation, DVD players are able to handle a stream greater than 9.8Mbit/s on input without crashing or freezing. The DVD standard does not mention anything about changing the way it is handled, thefore it is safe to assume it is handled the same way. If the MPEG-2 standard say something, and the DVD standard uses this same standard with some minor changes you can (correctly) assume that what applies in MPEG-2 applies for DVD unless otherwise specified.

The changes/differences are nicely said here (http://www.mpeg.org/MPEG/DVD/Book_B/Video.html).

I am not asking you to change your religion or tell you that aliens exist. I'm just showing you documents with facts. I was reffered to the MPEG-2 draft when looking for the DVD standard. It has all the information required.


Still have a question about the max. DVD bitrate of 9.8 Mbit/s.
Is it so that the sum of the last 25 or 29.97 frames must be less than 9.8 Mbit or is another time frame used to calculate the max. bitrate.
Or, simply put, how many frames do you need to correctly calculate the bitrate of a stream?

It is the average over the whole stream. Not over a second or GOP.

@dragongodz
If you still aren't convinced that the maximum bitrate is a limitation of data rate to the VBV buffer only and not the decoded stream, send an email to mpeg.org stating you are a student doing an assignment and you aren't sure. They will probably tell you.

[dragongodz]

hank315 - the point trying to be made(atleast by me) is that neither max bitrate or VBV alone should be considered. all factors must work together and to ignore any one can cause problems later.

The maximum bitrate still has the same definition as the MPEG-2 standard.
no it does not. you even show right above where it is changed to 9800Kb/s for dvd. MP@ML's limit is 15Mb/s.

The bitrate of the decoded stream is not limited to 9800kbit/s, it is limited by 9800kbit/s. These both mean something completely different (isn't english a funny language).
or to put it another way, it is limited to 9800Kb/s because the max delivery speed(meaning dvd read speed) is 9800Kb/s. so it is limited to A by B. no english is not really that funny its just sometimes people try to be.

For VBR, you can't possibly have an average bitrate over 9800kbit/s and have it play indefinitely
Thats the limitation. It's actually the average bitrate of the stream that is limited by 9800kbit/s, not really the maximum bitrate
so lets say we have 30 seconds of no motion footage and then 15 seconds of high motion. the average bitrate can easily be under the 9800Kb/s but i wonder how that last 15 seconds will play if it that part is allowed to exceed that.

A stream exceeding 9.8Mbit/s on input to the VBV buffer is still DVD compliant. The MP@ML standard requires the last frame to be repeated until the next frame is ready on the buffer. Because it must be able to handle such an undesirable situation, DVD players are able to handle a stream greater than 9.8Mbit/s on input without crashing or freezing.
even if you were right it is totally undesirable so why not avoid it to start with. i also never said crash or freeze, i said unsmooth playback.

the maximum instantaneous bitrate of the stream can be up to 1835008bits without underflow
well
By allowing for bursts of up to 10 megabits per second, the DVD specification takes into account the need for short bursts in the data rate to accommodate complex scenes
is from http://www.creativevideo.co.uk/reframe.php?url=http://www.creativevideo.co.uk/pages/cvp_info_mpeg2_dvd.htm
and
If DVD compliant is selected, instantaneous bitrate in GOP units is controlled to be a maximum of 9.8 Mbps
from http://www.cinemacraft.com/files/doc/ccl_264e.pdf

I'm just showing you documents with facts. I was reffered to the MPEG-2 draft when looking for the DVD standard. It has all the information required.
hmm and what i have i been doing then ????
also the mpeg-2 draft does NOT have all the information required. proof ?
The changes/differences are nicely said here.
hmm wasnt it me that posted that link for you to read.....twice ?

well i have provided plenty of documentation and quotes etc. its up to you what you do with it and what you want to believe. do as you will because if all i have already given you isnt enough then nothing will be.

oh and i would still like to know what you think the max bitrate setting in encoders is for if not to limit the max bitrate per second explicitly.

[Peter Cheat]

The maximum bitrate definition is the same for DVD as MPEG-2. (Do you know what definition means?). The value may have changed, but it still means the same thing as in MPEG-2. They didn't suddenly change it from meaning the input data rate to the output datarate.


so lets say we have 30 seconds of no motion footage and then 15 seconds of high motion. the average bitrate can easily be under the 9800Kb/s but i wonder how that last 15 seconds will play if it that part is allowed to exceed that.


It will play fine provided no buffer underflow. A huge spike for the full 15 seconds would cause underflow, but the last 15 seconds can average around 9804kbits without to much concern.

CCE documents are not fact, they just explain how CCE works/what it does. It doesn't make it right. I did reuse your link, as it just backed up everything I said 100% (BOOK B DVD Video Specs overview).


oh and i would still like to know what you think the max bitrate setting in encoders is for if not to limit the max bitrate per second explicitly.

You can't model the VBV without specifying a maximum bitrate. You need to know the maximum bitrate at which the buffer can be filled. Funnily, you can't change the VBV buffer size in CCE. But you need to have a VBV buffer size if you specify a maximum bitrate, and you need a maximum bitrate if you specify a vbv buffer size. I can show you the code for FFMPEG and mpeg2enc, both of which only make reference to maximum bitrate with the VBV buffer.

[dragongodz]

They didn't suddenly change it from meaning the input data rate
have you been reading what i have typed at all ? i have constantly said the input max bitrate per second is the max bitrate. you have stated it doesnt matter if it goes above.

A huge spike for the full 15 seconds would cause underflow, but the last 15 seconds can average around 9804kbits without to much concern.
yes it would cause underflow. however if the max bitrate limited by the max media speed aswell as VBV is handled by the rate control then it shouldnt.

CCE documents are not fact, they just explain how CCE works/what it does. It doesn't make it right.
no but i suspect a big commercial company that has been making a quality encoder for years does have the dvd specs and may just have some idea what its talking about. at least better than you or i. :D

I did reuse your link, as it just backed up everything I said 100% (BOOK B DVD Video Specs overview).
well you asked for documentation to show that the mpeg draft wasnt dvd specs and i provided it. none of that information on limitations for dvd is in the draft, period. as for backing up what you said, well thats your interpretation while i disagree. i doubt either of us is going to change our minds so i wont bother to try anymore.

You can't model the VBV without specifying a maximum bitrate. You need to know the maximum bitrate at which the buffer can be filled.
again i have said many many times they need to be handled together and you have constantly said VBV is all that really matters.
ignore the debate over dvd for a moment. when someone enters a max bitrate in an encoder they expect it to be the max bitrate used. whether you say it is really important or not doesnt matter, that is what is expected ,and i dont mean just by newbies, and should be used.

Do you know what definition means?
hmm do you know what "ask me a question like that as if i am stupid again and i will tell you exactly what kind of person i think you are" means ? if you dont know how to talk to someone who has a different opinion than you without insulting them repeatidly then its a good idea to say as little as possible.

[Nic]

Thanks for your reply Peter.

I think it's best to say now that the argument side of things is closed, because I think it's getting a tad heated and I think everyone has made their points.

But one last question from me (if that's ok):


Lets say 1 second (25 frames) of video in VBR goes up to 11Mbits/s.
Assume the buffer starts full at 224KB=1792kbits.
(just say each frame is 440kbits for simplicity)
Frame 1=440kbits Buffer goes down to 1352kbits, but the data is read at 9800kbit/s=392kbits so the buffer holds 1744kbits. No underflow.
Frame 2=...buffer has 1696kbits
Frame 3=...buffer has 1648kbits
...
Frame 25=...buffer has 592bits (but may have gone down to 152kbits)
but no underflow occured, therefore will playback fine. That assumes a progressive film, and that the next frame will not cause underflow (if it is >592kbits it will). Thats the maths taken care of. (From the MPEG-2 draft, or any open source mpeg-2 encoder.)


What if the buffer started at, say, quarter full? (around 448kbits) then it would soon underflow. Does the VBV model (or at least the code you use) stop that from ever happening?

I will re-read the pages (i've read the doc before from start to finish (a while ago now) but wasn't focusing on bitrate), and maybe the answer is there. (For people following this discussion it's annex C of ISO 13818-2 (pg 182 in the PDF Peter linked to)

Cheers and Thanks,
-Nic

ps
Do you also agree, that underflow, although accounted for in the spec, is highly undesirable for those doing DVD backups?

pps
It actually appears that underflow is definitely not part of the spec if low_delay = 0 (which it is in the DVD spec). So we can't have underflow it appears (from reading C.8)...do you concur?

[Peter Cheat]

Originally posted by Nic
Thanks for your reply Peter.

I think it's best to say now that the argument side of things is closed, because I think it's getting a tad heated and I think everyone has made their points.

But one last question from me (if that's ok):

What if the buffer started at, say, quarter full? (around 448kbits) then it would soon underflow. Does the VBV model (or at least the code you use) stop that from ever happening?

I will re-read the pages (i've read the doc before from start to finish (a while ago now) but wasn't focusing on bitrate), and maybe the answer is there. (For people following this discussion it's annex C of ISO 13818-2 (pg 182 in the PDF Peter linked to)

Cheers and Thanks,
-Nic



RateControlContext *rcc= &s->rc_context;
const int buffer_size = s->avctx->rc_buffer_size;
const int qmin = s->avctx >lmin;
int unused_buffer;
int look_ahead = 10; // number of frames to look ahead

/* Look for buffer underflow in future second and prevent it */
if (buffer_size && frame_number < (rcc->num_entries - look_ahead)) {
int predicted_buffer = rcc->buffer_index; // Set the predicted buffer to the same value as data in the buffer
int frame_bits;
int i=0;

do {
RateControlEntry *rce = &rcc->entry[frame_number + i]; // Get statistics for this frame
frame_bits = qp2bits(rce, rce->new_qscale, compressibility[rce->pict_type]);
frame_bits = FFMAX(frame_bits, min_rate);

if ((predicted_buffer < frame_bits)&&(rce->new_qscale < qmax)) {
/* Pending underflow detected, so increase quant */
for (i=i; i>-1; i--) { // nasty loop
RateControlEntry *rcp = &rcc->entry[frame_number + i];
rcp->new_qscale += FF_QP2LAMBDA; // increase quant
predicted_buffer = rcc->buffer_index; // reset predicted buffer
}
} else {
predicted_buffer -= frame_bits;
unused_buffer = buffer_size - predicted_buffer - 1;
predicted_buffer += clip(unused_buffer, min_rate, max_rate); // refill buffer
}
i++;
} while (i < look_ahead);
}


This code is executed BEFORE encoding every single frame. It takes the value currently in the buffer, and checks if the next frames cause underflow. If they do, the quant is increased by one until it no longer does. Looking ahead 10 frames slows down encoding a bit, but it pretty much guarantees no underflow. To get this to work properly, I had to change the way rescaling of quants was done to keep the filesize. To answer your quenstion, yes.

Originally posted by Nic

ps
Do you also agree, that underflow, although accounted for in the spec, is highly undesirable for those doing DVD backups?


If it wasn't, I wouldn't have spent so much time writing code to stop it.

Originally posted by Nic

pps
It actually appears that underflow is definitely not part of the spec if low_delay = 0 (which it is in the DVD spec). So we can't have underflow it appears (from reading C.8)...do you concur?

Oops, I mixed up low_delay 0 and 1. You're right, DVD players are not required to handle underflows at all. But I have made every effort to try and stop them.

[Nic]

Hi Peter,

Looking at your code, is it not perhaps a bad idea to use 'i' twice in that loop ?
(to show what I mean i'll cut the code i'm referring to below:)


do {

if ((predicted_buffer < frame_bits)&&(rce->new_qscale < qmax))
{
for (i=i; i>-1; i--) { // nasty loop
..etc..
}
}

i++;
} while (i < look_ahead);


Won't that make it so if the 'if' statement is true 'i' will be set to 0 (from the 'for' loop) and the 'do...while' loop will have to repeat all over again? (well until 'i' reaches look_ahead anyway). Or is that the intended way it should work?

EDIT: Although it may be intended (as I think it is). It may be not working as you hope, because 'i' will be set to 1 on a reiteration of the loop (because of the 'i++') instead of 0 if the 'if' statement is true. Hope that makes sense and/or helps.

-Nic

[Peter Cheat]

I believe that i=-1 after completing the for loop (do while >-1), adding 1 will make it zero as required. No problem there. I know this is horrible code, thats why I don't want to submit it to cvs yet.

[Nic]

Oh, yes, very true. :)

Well, keep it up. What's the current status and how do you feel the quality is compared to the original libavcodec code?

-Nic

[Peter Cheat]

Doing a quick comparison, the quality appears to be the same (well, this is expected when using the same rate control equation). I'll post results of a comparison. The advantage is that I can't make NuEnc underflow yet on passes >=2 (in 1st pass of X pass buffer is ignored to increase encode speed). 1 pass encoding is unchanged. The code seems stable, and still can be tweaked using 3 parameters (not available to be tweaked externally yet). They include improvement/degradation factor which is set to 10%, rescale period which is set to 300 frames (every 300 frames the next 300 frames are scaled) and if the filesize becomes 5% off target at any time, the next 300 frames are rescaled also to compensate. These seem to be good figures for now. If anyone notices quality problems, these can be adjusted accordingly.

I have a sneaking suspicion that while loops are faster than for loops (when I had the external while loop as a for loop, it was running at half the speed). Do you know if this is true Nic?

[dragongodz]

I have a sneaking suspicion that while loops are faster than for loops (when I had the external while loop as a for loop, it was running at half the speed).

http://www.codeguru.com/forum/showthread.php?t=310721

thats Visual C++ but the comparison of disassembled code could be done for GCC aswell. that should give you some idea.

[Peter Cheat]

It should be the same, but I had the impression that the when I changed a for loop to a while loop that it was faster. I'll look at the disassembled code and see if gcc does treat while and for loops differently.

[freelock7]

It would be interesting to add in advanced options some new matrix as the excellent CYDVD.

[Trahald]

Ok.. i reencoded the file with nuenc (this is a file that scenarist would not take when encoded with quenc because bitrate was too high that i mentioned in the quenc thread) .. i used full bitrate max (meaning the video*max* + audio, etc == 9800) and worked like a charm. picture looks great as well.. good work peter (and Nic)

[dragongodz]

freelock7 - you may be interested in reading the QuEnc thread, especially the last page.

Trahald - actually the 9800Kbits/s is video limit, not the total limit. that is 10.08Mbits/s. so you actually set slightly undersize max. :)

good to see someone testing and posting results though.

[Trahald]

@dg - yeah.. sorry... we use the 9800 as a target to leave a buffer.. sometimes even cce spikes.

[Peter Cheat]

Originally posted by Trahald
Ok.. i reencoded the file with nuenc (this is a file that scenarist would not take when encoded with quenc because bitrate was too high that i mentioned in the quenc thread) .. i used full bitrate max (meaning the video*max* + audio, etc == 9800) and worked like a charm. picture looks great as well.. good work peter (and Nic)

Great, its good to see that NuEnc created a stream that scenarist accepted. Perhaps buffer underflows were the problem in this case, because I have not included code to stop the decoded stream from exceeding maximum bitrate.

@freelock7
When/if QuEnc has this feature, I will include it into NuEnc. Currently, I have no time to make any big changes (exam time!), but I will get back onto it after exams. I have got a small update coming up, which improves quality a little for encodes at all bitrates.

At the moment, my tests show that my modifications have notreduced the quality at all, and using the right settings, you can get better results than with original libavcodec (not much though).

[dragongodz]

we use the 9800 as a target to leave a buffer.. sometimes even cce spikes.
yes we have "discussed" that very fact around here before. :)

Perhaps buffer underflows were the problem in this case, because I have not included code to stop the decoded stream from exceeding maximum bitrate.
though the prevention of undeflows does also reduce frames sizes reducing the amount of spiking maybe ?

[Peter Cheat]

Sort of true, it does reduce frame sizes where an underflow would occur, but spikes occur more frequently then in the original libavcodec code. The reason is that libavcodec originally *tried* to make frames no bigger than 1/3 of the buffer to prevent underflow. This would have worked if the prediction was more accurate. I changed it so a frame can consume as much as the buffer as it wanted (so I frames could have a lower quant in high action scenes), as long as there was enough bits for the next frames to remain at a relatively constant quant. Hence, high action scenes look better, you shouldn't get underflows, but spikes can be huge, usually caused by I frames that are close together.

TMPEnc causes underflow on occasion. Older versions of TMPGEnc used to stop encoding if too many underflows occured. It may still, I haven't really tried the latest version.

I agree, it would be interesting to see what happens if the full bandwidth was used. It should also be ok, but no guarantees :)

[Trahald]

Next project rcvd an underflow with nuenc.

Error Video or Audio Buffer underflow: (Dts: 156781857, SCR 156781886)
Error Total bitrate is too HIGH. Please reduce the stream bitrate or the number of stream.

i removed some of the audio streams and it went through ok. I'll report how the next project goes

<edit>
Next project smooth as silk.. scenarist happy with input

[Peter Cheat]

So underflows still can occur on occasion. Its hard to completely prevent. I'm still amazed:confused: how a DVD originally encoded as CBR at 4000kbit/s can spike way over 4000kbit/s when re-encoded. Odd.

[Trahald]

I did another project and compiled fine as well.. i wonder is there something that will check bitrate and vbv compliance and give detailed output...

[hank315]

So underflows still can occur on occasion. Its hard to completely prevent. I'm still amazed how a DVD originally encoded as CBR at 4000kbit/s can spike way over 4000kbit/s when re-encoded. Odd.
Maybe this isn't so odd. With CBR the quantizer can have very low and high spikes to keep the bitrate constant.
When this CBR stuff is re-encoded using VBR an encoder should try to keep the quantizer as low and constant as possible to get the best possible quality so the bitrate can spike (ofcourse within certain limits such as VBV underflow:) )

[dragongodz]

I'm still amazed how a DVD originally encoded as CBR at 4000kbit/s can spike way over 4000kbit/s when re-encoded. Odd.
not really. you have to remember you are dealing with lossy compression. every time you recompress you are losing more detail. so to maintain all the detail from the CBR stream may require a higher bitrate than the original bitrate, effectivly trying to do as little loss as possible. this is very dependant on the original CBR encode and how much detail it has reatined of course.

I changed it so a frame can consume as much as the buffer as it wanted (so I frames could have a lower quant in high action scenes), as long as there was enough bits for the next frames to remain at a relatively constant quant. Hence, high action scenes look better, you shouldn't get underflows, but spikes can be huge, usually caused by I frames that are close together.
when i was looking at this some time ago with the orioginal rate control it was not actually the I frames that were spiking but P frames. I frames were never given enough bits to start with which caused the pulsing people know about. that why i changed that setting in my release and pumped up I frames and reduced B frames. less underflows and spikes but no true fix of course.

[Peter Cheat]

Originally posted by Trahald
I did another project and compiled fine as well.. i wonder is there something that will check bitrate and vbv compliance and give detailed output...

NuEnc reports underflows internally (well, it does roughly). I can implement log file writing if you want that gives detail about bitrate etc.

@hank315 & dragongodz
It does seem strange to spike so high. If originally material was encoded at 4000kbit/s CBR, I wouldn't expect the bitrate to increase over 8000kbit/s. The reason is that detail has been removed during the original encode. The only way the bitrate can go above the original bitrate is due to increased noise, such as block noise or ringing. If you encode material at Q=2, then reencode it again at Q=2, the second time round, the file will be smaller (and lower quality)...I guess it really depends on the encoder, and the decisions it makes.

@dragongodz
The pulsing in original rate control was (probably mostly) caused by the default algorithm tex^0.5 (SQRT(original texture bits) * factor). Large frames get punished, small frames get a bonus. To get around this, negative i_factor and b_factor could be specified, so that the quantiser of I/B frames depends on P frames...(You could also use a very small i_factor and a very large b_factor as you've done). The reason why the tex^0.5 algorithm was used was to try to help prevent underflows by limiting the size of an I frame. I frames, in general are larger than P frames. But it is better to reduce the quality of P frames than I frames, for obvious reasons. Using 'tex' as the rate control algorithm fixes the pulsing issue (or tex^1) giving 'constant quality'. You might want to try giving negative factors instead in QuEnc.

I think another small contributor to pulsing is lack of closed gop with scene detection on. I am working on that now. B frames referencing an I frame after a scene change is pointless and wasteful.

[dragongodz]

If you encode material at Q=2, then reencode it again at Q=2, the second time round, the file will be smaller (and lower quality)
yes but to get the same quality(no detail loss at all) would require a lower quant which would increase size, possibly sometimes past the original size.

I guess it really depends on the encoder, and the decisions it makes.
yes and also the decoder for noise,ringing etc as you mention.

I frames, in general are larger than P frames. But it is better to reduce the quality of P frames than I frames, for obvious reasons.
of course which is what my settings force to happen. result- no more pulsing and less underflows than the default settings. :)

You might want to try giving negative factors instead in QuEnc
yes i did try negatives aswell. didnt really improve anything which is why i used the settings i did. as has been said by many people many times, avcodec rate control just is not that good. which is why so many people are interested in you working on it aswell. :D

I think another small contributor to pulsing is lack of closed gop with scene detection on
not really no. ok that may for that particular case but the general problem of a fixed GOP size having pulsing is seperate.

[Peter Cheat]

Closed GOP will fix pulsing (well its not really pulsing but smeared noise that suddenly disappears) in some cases. Pulsing in general doesn't seem to occur with QuEnc or NuEnc anymore.

Note the new update. It is not a huge update feature-wise, but I have focused on quality improvements. Scene change detection sensitivity was increased to overcome an obscurity in scene detection algorithm (scene detection depends on quantiser!). Other changes as well.

[dragongodz]

cool. hopefully some people will do some testing and report back. i will try to squeeze some in aswell but it wont be extensive.

i do question the point of replacement of QLB by notch matrix but hey whatever. :D

[Peter Cheat]

I liked the QLB matrix but ppl on the KVCD forum obviously needed the precious notch matrix. As long as its tested and any bugs stomped out, I don't think it really matters. Custom matrices will be implemented eventually anyway.

[hank315]

@Peter & dragongodz
Did some testing encoding a video again and again.
Took a 20 sec. clip from a movie and encoded it using a constant quantizer of 2, then encoded the result again using a quantizer of 2 and so on.
The result of this:
run 1: file length: 33259 KB
run 2: file length: 33340 KB
run 3: file length: 33437 KB
run 4: file length: 33550 KB
run 5: file length: 33651 KB

During the tests all conditions are exactly the same.
It shows that after each encode the file is about 0.3% larger, probably due to the introduction of noise at each encode.

[Peter Cheat]

Small increases in size aren't surprising. It's the huge bitrate increases that I find odd (over double).

IMPORTANT NOTE
If you downloaded NuEnc 0.00c before this message was posted, please redownload it. There was a problem with Q=1 and the 'Notch' matrix that I just fixed.

[Trahald]

I have a 112k file that nuenc is choking on.. it seems to do ok with 1 pass mode, but in 2-pass nuencs process bloats up really big (to the point it brings windows to its knees) and refuses to do the next pass. quenc and cce have no problem with the file.

[bergi]

in 2-pass nuencs process bloats up really big (to the point it brings windows to its knees) and refuses to do the next pass

I have the same problem.

NuEnc also refuse to work if i start it with command line parameters. I think it's a P4 problem:

65645915 pmaddwd mm3,mm2
65645919 pmaddwd mm7,mm1
6564591D pmaddwd mm2,mm5
65645921 pmaddwd mm1,mm4
65645925 paddd mm3,mm7
65645929 paddd mm1,mm2
6564592D paddd mm3,mm6
65645931 paddd mm1,mm6
65645935 psrad mm3,11h
6564593A psrad mm1,11h
6564593F packssdw mm1,mm3
65645943 movq mmword ptr [edx],mm1

At position 65645943 an error occured in avcodec.dll.

[dragongodz]

Peter needs to compile the avcodec.dll with --enable-memalign-hack for P4's if he hasnt.

[freelock7]

I encoded the same video with QuEnc0.54(custom matrix) & NuEnc0.0a(QLB matrix).
1) at VBR:4600_1Pass.
2) at VBR:2600_2Pass.
Results:
QuEnc seems to encode with a better bitrate average than NuEnc designed to work in low bitrate settings.
Pixels appears in high motion picture with NuEnc (1Pass) not with QuEnc0.54 .
But in 2Pass setting, NuEnc works better than QuEnc.

[RobertR]

My tests of Peter's patches to ffmpeg/libavcodec have slowed down a lot last few days :(
For some unknown to me reasons when I apply Peter's changes over 0.4.9-pre1 it always segfaults during 2nd pass. When changes are applied over recent CVS there is no such problem (i did 6 passes)
Bitrate distribution seems to be better (at least in ffmpeg-source.zip that was released together with NuEnc 0.00b).

Peter could You please do me a favor and put some 'versioning' on ffmpeg-source.zip ?

Would releasing commandline only version of NuEnc be a big problem? My programming skills are quite rusty and trying to make my way throu windows gui bloat (no offense) is getting on my nerves a lot. :D

Peter thanks a lot for what you've done so far :)

[dragongodz]

Pixels appears in high motion picture with NuEnc (1Pass) not with QuEnc0.54 .
from memory NuEnc is using old rate control for 1 pass encoding so it would be the internal settings used that are the difference.

throu windows gui bloat (no offense) is getting on my nerves a lot.
please dont be a richard felker. :eek: :D