Suggestion for a new method of bitrate distribution

[Boulder]

4) The ability to encode the whole VTS at a time, that is, so that it is not split up in cells. I have seen too many DVDs that are encoded as CBR in which case this option would be really useful.To add to this: I just ran into another wonderful CBR encode where the average bitrate is ~3500kbps for every cell IIRC. Definitely not optimal. Here's what I suggest: encode every cell as one-pass (CQ mode in HC, OPV in CCE etc.) with the exact same parameters (same quant, same Q-value etc.) Then use the average bitrates of the sample encodes to determine the "correct" average bitrate for each cell.

I use a similar method for re-encoding my DVB captures so if you need the maths, I can send my Excel spreadsheet to you. I intend to try this approach in DVD-RB as soon as I have the time; you can do it manually using the rebuilder.ecl, the spreadsheet and the segment viewer/editor but it requires a bit of work.

[linx05]

@Boulder
That looks like a really handy way of doing things. It would improve the look of some parts of the movie wouldn't it? The bigger action scenes would get encoded differently to the scenes where nothing really happens.

[Boulder]

Exactly. Fortunately most movies are encoded properly using VBR but many series are CBR. One another problem is that many series have the same avg bitrate for every episode, the method I described can also be used to tackle that, and it doesn't matter whether the episodes are in the same VTS or not.

Simply put it's just doing a compression test and then tweaking the average bitrates accordingly.

[Boulder]

Just got the test encode done, and it does work just fine. A little manual work is needed and some extra time, of course, but it does allow you to correct the average bitrates of the cells when the original is almost or completely CBR, or when every VTS on the disc has the same avg bitrate.

I'll ask jdobbs or wmansir to move the couple of posts discussing this into a new topic since it's not just a request.

[Boulder]

OK, here's the deal.

1. Run the prepare phase in DVD-RB.
2. Encode all the avs files DVD-RB created using the exact same parameters for each file in one-pass mode. That means CQ for HCEnc, OPV for CCE etc.
3. Open the spreadsheet I've attached in this post.
4. Get the average bitrates and number of frames in each encoded cell.
5. Enter the space available for video value in the spreadsheet from DVD-RB's status window or the log and divide it by 1024 to get megabytes.
- Space for Video : 3 724 506KB --> 3637MB
6. Use DVD-RB's segment viewer/editor to edit the average bitrate of each cell. The correct value for each cell is in the corresponding "Avg kbps for cell in DVD-RB" field.
7. Encode and rebuild as usual.

If you need any more cell columns in the spreadsheet, you need to copy an existing column and edit the formula in B21 so that all the columns are included in the sum.

[techreactor]

that was exactly the way I was thinking when I read the subject of this post, but with the difference that can we not use any tool for reading the bitrate for each segment of the source and then using those values and reducing them equally in proportion to the compression required for the final encode ???

The results should be similar theoritically.

[Boulder]

What I've been trying to fix are those nasty CBR encodes where the source avg bitrates cannot be used for any calculations because every cell has nearly the same avg bitrate. The latest one was 4:3 full screen at 3200kbps which made me really angry, just how stupid can the authoring houses be?

My method can also be used in those cases where every VTS has the same avg bitrate but the bitrate demand is not even between them. This applies to many series DVDs.

[Sir Didymus]

Hi Boulder!

Very nice approach (simple and useful)...

Appreciation and thanks for sharing the xls!

Cheers,
SD

[Boulder]

Thanks:)

Hoping that jdobbs will some day add it as an option ;)

[jdobbs]

I'll take a look at putting in a check for CBR and making automatic adjustments when it is found.

[Boulder]

Be warned though that I've never seen anything specifically marked as CBR, everything has been as VBR but the min/max/typical average bitrates have revealed the truth.

[mpiper]

If we are re-encoding the entire movie, why would the bitrate and VBR vs. CBR bitrate matter?

Maybe I am missing the point on this, but I use CCE with it set to 2 passes for almost all my Rebuilder work. I have always assumed that rebuilder reads the AVWS files and generates its own bitrate using my settings (DVD-5 size, 10-15 VBR_Bias, 12-16 Quality Prec.)

So why would it matter if the original source was CBR or VBR with a single bitrate? Am I missing a point here?

Thanks,
Mike

[Boulder]

It does matter because every cell would have almost the same average bitrate - regardless of the amount of motion etc. which all contribute to bitrate demand of the cell. Opening credits on a black background need very little bitrate compared to a high-action scene. The method I described shifts the bits to the cells that demand more bitrate.

[mpiper]

Boulder, before I add anything else, let me say that I'm not arguing with you. I am honestly trying to understand the exact nature of how this works.

I amk the multimedia nerd for my department, which does multimedia and CBTs for our company, so I try to understand what I am talking about for future discussions.

So, here goes my questions (lol)

My understanding for multipass encoding is that:
A) The encoder generates a keyframe, using the selected matrix and allocates the midrange of bits, the next frame (intraframe) encodes only the changed information, using the intraframe matrix, using a number between the midrange and the lowest bitrate, and so on. (The avagerage is kept at a running total and extra bits are stolen or added as needed to maintain the average off from the maximum and minimum bitrates, more to high motion, less to the low motion.
B) The second pass, the encoder compares the original frame to the frame generated the first time. If the 1st pass was too high for avg bitrate, encoder is trying to find frames to steal from. If 1st pass was too low, encoder is trying to find frames to add to. If the frame is matching, bits may be removed to lower avg. If frame is not matching, bits will be added, as much as allowable based on max rate and average rate.

With that said (and it may not be accurate), a two pass encode at settings of 1700,2450,5500 would generate a first pass where every part of the video would be at 2450, while the second pass would shift/add/subtract bits so that some sections would be around 1700-2000, some parts around 2400-2500, and high motion parts would be 4000-5500. (Third and more passes would refine the bit shift by comaring again against the original until maximum match for datarate is reached.)

My understanding of your earlier statements (possibly also wrong) is that the second pass would result in 2450 for all parts of the movie, even when VBR is chosen, after the second pass. If this is true, wouldn't this be a case of a bad encoder, not a need for extra steps?

My impression of the Rebuilder add-on RB-Opt(?) that allowed changing individual groups was: if you wanted to push the limits further than the encoder was willing to go (shrink the size and quality to crap for the credits, etc.) to allow the main feature to have the maximum possible bitrate.

I have never really gone back and checked my datarate of encoded DVDs, so I have no basis for my arguement, except my understanding of the process. So if I am mistaken, please point out my errors so I can better understand (and explain to others) how this process works.

Thanks to everyone!
Mike

[Boulder]

Very simply put: DVD-RB splits the video in cells (usually a chapter?). It takes the average bitrate of each cell and uses that as a base for the calculations. DVD-RB handles each cell as a separate unit, it doesn't borrow or allocate bits from/to other cells.

If the authoring house has decided to go for CBR or almost CBR, every cell has (almost) the same average bitrate. For a VBR encode, the cells do not have the same average bitrate because the bits have been allocated more intelligently.

Now consider a regular action movie which has its slow and fast scenes. If both scenes (which usually are a separate chapter) have the same average bitrate, the fast action one will probably look terrible, or at least worse than the slow one.

The idea is to run a constant quality compressibility check pass which tells you directly which cells need more bits than others to keep the quality at the same level in each cell. The spreadsheet I wrote a long time ago uses the constant quality pass to calculate the average bitrate you need to set in DVD-RB for the cells.

Any questions, just ask :)

[mpiper]

So your saying I was roughly correct in my understanding, but by splitting each cell, there is no average datarate to use, so each gets slammed to that average since it is such a small sample size. Correct?

OK. Now I see the big problem.

So your process allows us to see what was encoded, calculate the optimum bitrate distribution and then set it for final encoding?

I don't have a sample DVD to try handy, but how does the spreadsheet know which groups to add or subtract datarate from? Or do I make a judgement call and then the rest auto adjust?

Mike

[mpiper]

After putting fake data into your spreadsheet (I used a CBR value to simulate what we are discussion), I see a new datarate at the bottom of each column, but each one is the same (i.e. CBR).

Are we assuming that running OPV will give us a VBR datarate set, which we can then use to set the VBR rates for multipass encoding?

Just checking on how this is working.

[Boulder]

Using OPV or CQ will give a proper VBR curve (despite the length of the cells!) because the cells are encoded with constant quality mode. Well, constant quant is not exactly constant quality but it is very close to that.

[jdobbs]

One problem with a reencode of CBR is that the best quality you are going to get is whatever bitrate was fixed in the original. In other words, anything that reencodes at a higher rate then the original would be wasting bits on (most probably) reproducing artifacts. So about the best you can do is reencode with VBR with the maximum bitrate set to the constant one found in the CBR. That's what DVD-RB does now. The problem is that it will likely come out smalller than the original (high demand hits the CBR rate barrier, low demand uses less).

[Boulder]

If you use a sub-optimal bitrate curve to re-encode, the results cannot be optimal. That's the problem I'm trying to address. Encode a blocky frame with a low bitrate - you get a frame with even more blocks. Encode a blocky frame with the highest bitrate you can afford without the rest of the video suffering - lowest possible damage done.

I've got one really terrible looking intro scene which I'm going to test my method on. It may take 3-4 weeks before I get to finish the test as I've got very hectic times ahead at work but if I'm lucky, I'll have them done early next week.

[jdobbs]

Encode a blocky frame with a low bitrate - you get a frame with even more blocks. In addition -- if you try to encode a frame that has blocks caused by the decoding at CBR limits -- the sharp edges of the blocks make it harder to reencode (because the encoder is trying to reproduce them as perfectly as possible) -- and you end up needing even more bitrate.

So the worse the original is decoded -- the more bitrate it takes to reencode (attempting to reproduce garbage). Unfortunately the encoder can't distinguish the macroblocks from the good parts.

[Boulder]

Another thing related to a new bitrate distribution: you should be allowed to set the maximum bitrate to any (sane) value. I've got one concert DVD where the avg bitrates between cells have very little variance and to add to that, the max bitrate is always ~6000-6500kbps.

EDIT: it would also be useful when you need to sharpen the source, for example 2010: The Year We Make Contact is one of those. Letterboxed 4:3 video and a very fuzzy one too..SeeSaw is a must there.

[Sharc]

....you should be allowed to set the maximum bitrate to any (sane) value.....


I think that can be done (at your own risk) by inserting

max_bitrate=nnnn

where nnnn = kbps, in the rebuilder.ini.
See DVD-RB Help / Hidden settings.

[Boulder]

Nope, if the value found in the source is lower than the value you set in the ini-file, the original maximum bitrate is used.

[jdobbs]

Yes. The original maximum is used to limit it. But, since you can't make a reencode better than the original -- any bitrate greater than the source maximum would be, by definition, the application of bitrate to retain new artifacts.

[Boulder]

But if you alter the source for example by sharpening, you need those extra bits at times. Many older DVD releases are quite poorly mastered and sometimes need quite serious actions. Of course, this doesn't apply to Joe Average, but there are quite a lot of us who like to use those advanced techniques.

[jdobbs]

Good point. You can override that limit by adding:

DISABLE_DYNAMIC_PEAK=1

to the "[Options]" area of REBUILDER.INI.

You have to be careful, though. If the maximum it is set too high, the audio reintegration might run into timing problems. No matter what you set for max -- DVD-RB will still enforce a limit [9800Kbs - audio_bitrate] though.

[Sharc]

yes, I remember, original bitrate is retained as a means to prevent stutters ....

[Boulder]

Good point. You can override that limit by adding:

DISABLE_DYNAMIC_PEAK=1

to the "[Options]" area of REBUILDER.INI.

You have to be careful, though. If it is set too high, the audio reintegration might run into timing problems.Thanks :) I usually use 8000-8500kbps to avoid playback problems, depending on the audio tracks.

[Boulder]

OK, I'll try to make the process a bit clearer. To achieve that, I made a small FAQ:

1) Why did you come up with this silly method?

I originally began developing it when I used to cram two movies per DVD. I quickly noticed that the average quant levels between the two movies were very uneven - one would have ~3.5 whereas the other would have ~6.0. This is, of course, not a good thing so I began thinking about how I could fix the situation. One thread by DDogg (http://forum.doom9.org/showthread.php?t=74141) in the DVD2SVCD forum actually helped me come up with the initial idea.

2) What is the purpose of the method?

- to shift bits from less demanding segments to those that need more
- to avoid the problems caused by using the original bitrate distribution especially if the original source is CBR or near CBR
- to maintain equal quality throughout the whole video

3) What do you do the OPV/CQ pass for?

The OPV/CQ encode acts only as a compressibility test. Every segment is encoded using the exact same parameters so a bitrate-hungry segment will have a higher average bitrate than a segment that doesn't need as much to keep the same quality level. This means that from the results of the compressibility test encodes, we can calculate a bitrate ratio which can then be used to redistribute the available space for video between the segments.

After the compressibility tests have been run and the bits have been redistributed between segments, the encoding process continues just like in any normal DVD-RB project.

For fastest possible processing, you can run the redistribution pass without any filtering.

I have not tested the effects of different Q/quant values. I usually use Q30-40 in CCE and q4-5 in HC for doing the pass. IMO the most important thing is that the bitrate stays below the specified maximum because when the bitrate gets close to the maximum, the quants need to be raised. This can prevent the redistribution from being optimal.

4) What are the pros and cons of the method?

pros:
- equal quality throughout the whole video (and DVD when all VTSs are in the same redistribution pool)
- all the pros of OPV/CQ encode apply but you get accurate filesizes

cons:
- the redistribution pass takes extra time

5) How do you know that the method works?

Lately I've been capturing a lot of DVB stuff which I then re-encode as they usually need quite heavy filtering. I often put 3-4 episodes per DVD. I've used the method for determining the average bitrate per episode so that the quality would remain constant. When all the episodes have been encoded and I've checked the log, the average quant levels have been roughly the same. The variance has usually been in the range of 0.1-0.2 units which is a very small difference IMO. If I had encoded every episode at the same average bitrate, the variance would have been much larger.

If you have any questions, please don't hesitate to ask.

[gurkan]

Using the q value to redistribuate the bitrates will produce an outcome with an "even" quality throughout, right? So this method won't help in regards of, for example, getting higher bitrates to segments with detail and less to segments with high action, except for the usual vbr in the individual segments?

Don't know if that made any sense. ;)

[jdobbs]

Tell me, why wouldn't you simply do a Q-based multi-pass encode? It works as you've recommended... but instead of doing a standard multipass DVD-RB run after the Q is complete -- you could use the Q-pass generated (except for CCE Basic) .VAF file and recalculate the bitrate (for each segment based on the sizes of the Q-pass output) to get the required result. That way you'd only do 2 passes total.

For most encodes (except the CBR ones you mentioned) you'll probably find you'll get very close to what you got from DVD-RB originally, though. The difference would be that instead of going through all the segments once doing 2 passes, you'd go through them twice doing 1 pass each time (Q followed by VBR).

[Boulder]

Using the q value to redistribuate the bitrates will produce an outcome with an "even" quality throughout, right? So this method won't help in regards of, for example, getting higher bitrates to segments with detail and less to segments with high action, except for the usual vbr in the individual segments?

Don't know if that made any sense. ;)The method will shift the bits toward high-action segments by nature, because they need more bits for the same quantizer than low-motion ones.

@jdobbs: I've never tested it that way..one problem that immediately comes to my mind is that the Q used in the redistribution pass might not be accurate enough and the sizing pass would then not yield optimal results. Besides, you couldn't use HC which is a major disadvantage IMO.

I'm not that sure about getting similar results than in the original DVD. The three discs I've done recently have had much more variance in the average bitrates than in the original source. Chances are that they have originally been encoded using some kind of bias towards CBR whereas OPV/CQ doesn't take any of that into consideration.

[gurkan]

@jdobbs

AFAIK, it's not possible to use opv on seamlessly branched dvd´s. Would the predictability that this opv/vbr-method introduces enable this ability?
I've got this horrible pal-version of The Abyss, dir. cut that only looks good if one does a vbr on the whole unsegmented shebang.. I've only managed to do this in big3, and they can't handle the branching.

[jdobbs]

Use with ILVU would depend on whether it is seamless branching or angles, but generally the answer is "No." ILVU needs to be very accurately reproduced in a very specific fashion.

I've done the Abyss using standard 2 pass encoding without any issues. It's the NTSC Version -- but it also is the same ILVU nightmare... I'm working from memory, though.

[gurkan]

@boulder
Do you have any suggestions as to what quantizer characteristics and vbr bias settings would produce the most opv-like outcome? Might be wrong, but i don't remember those being available for opv.

[Boulder]

Bias should be zero because OPV has no such parameter. I cannot say anything about quantizer characteristics, it probably is neither an multipass-only nor OPV-only parameter but it affects both the same way.

[gurkan]

Wouldn't setting bias to zero just produce segments with individual cbr's? Since opv doesn't do segments I'm having a hard time to see how this would be equal.

[Boulder]

I'm not sure if I'm following you. What are you trying to achieve and how?

[gurkan]

Sorry, got it all wrong.
Nevermind.

[Sharc]

..... For most encodes (except the CBR ones you mentioned) you'll probably find you'll get very close to what you got from DVD-RB originally, though.......

Hmm ... , not sure.
See attached example for comparison. Quite some difference for some of the segments. I used CCE, avamat6 matrix and initial Q=9 for redistribution.

[jdobbs]

You may want to try it without changing the matrix and see if it has an effect...

Also, the second column sure seems to have a much more significant amount of swing in bitrate between segments. Is this from a commercial source or a homemade video? The small differences in the DVD-RB column looks a lot like a realtime VBR encode (like from a home DVD recorder).

[Boulder]

Also another note: did you use 100% for redistribution? It will naturally give the most accurate results. I never use any other values than 100% myself.

[Sharc]

I extended the tests using different matrices (requiring different Q factors to aproximate the target size). See attached file.

I think it is the bitrate redistribution that makes OPV encodes often "look at least as good or better than" standard VBR multipass encodes.

[jdobbs]

I personally wince when I hear that. I have doubts that OPV ever exceeds multiple pass quality... although it can come close to the same.

[robot1]

@Sharc
have you done any visual comparison, between the backup you get with standard DVD-RB and the redistributed ones? (obviously same conditions, same matrices)

[~bT~]

Sorry if its off topic but I have a small question.

Is it poss to do a 1pass encode using the bitrates from RB-Opt after bitrate distribution?

If so, how? Edit the .ecl?

[Sharc]

@jdobbs:
Commercial DVD - The Departed.
Actually I was motivated for the tests by an earlier post by nashcity about the amazing results he obtained with OPV for that movie ... I wondered why it should be better than multipass VBR .... then came along the post by Boulder discussing the redistribution .....

@boulder:
I used 25% sample size for these comparisons. For a real encode I would probably spend some more time and increase the sample size, just to be on the safer side.

@robot:
I cannot watch the differnet encodes simultaneously. But I compared some frames (I know, not very meaningful). I noticed for example less macroblocking in a segement which obtained a significant increse in bitrate after redistribution (using CCE Default matrix, which is softer than the original matrix).

Really a strong combo DVD-RB and RB-Opt :)

[jdobbs]

I cannot watch the differnet encodes simultaneously. But I compared some frames (I know, not very meaningful). I noticed for example less macroblocking in a segement which obtained a significant increse in bitrate after redistribution (using CCE Default matrix, which is softer than the original matrix).As might be expected... but what about the ones where the bitrate goes down? For every plus in bitrate distribution there is also a minus. In order for the new distribution to be better -- you have to also conclude that the original (professionally authored) bitrate distribution was done poorly. With the exception of CBR sources (or realtime VBR) I just can't buy into that assumption (yet).

The biggest argument I have against redistribution is that you are encoding a previously compressed (MPEG) source. The reallocation is just as likely to represent more bits being allocated to reproduce errors (from the first compression). I've seen this in testing.

I'm not against new ideas... I just like to be sure they are correct before joining in... :)

[Sharc]

I personally wince when I hear that. I have doubts that OPV ever exceeds multiple pass quality... although it can come close to the same.

I am not sure here.
Imagine an original complex cell (segment) which looks good when watching it in the original format (bitrate). After rebuilding, the avearge bitrate is lowered to say 65%, and although the VBR multipass will allocate the bits within this segment for best quality, the final encoded quality of this complex cell may become marginal.
OPV in contrast will steal bits from less demanding segments (still maintaing a constant Q there) and give it to the demanding segment which eventually migth receive an average bitrate close to the original => OPV can indeed look better than multipass VBR.
Does this make sense?