Suggestion for a new method of bitrate distribution

[Boulder]

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?Do the redistribution, then switch to OPV in RB-Opt and let it do the prediction etc.

[~bT~]

Do the redistribution, then switch to OPV in RB-Opt and let it do the prediction etc.

OK, that got me thinking. If I do the OPV 1st to find the Q. Then enter that Q to do the resdistribution. Then switch to OPV again. Can I enter the Q I found earlier or is it best to do it again?

EDIT: Or is it straight redistribution and then OPV?

[jdobbs]

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?But that distribution between segments has already been done -- in the original encode.

[Boulder]

@jdobbs: The authors are often not that professional. I've seen a lot of crap, especially in localized (i.e. Scandinavian) releases. The MacGyver season boxes are one good example..encoded at CBR and every episode has the same bitrate. Guess how good that looks when the source tapes are from the 80s? :p

[Boulder]

OK, that got me thinking. If I do the OPV 1st to find the Q. Then enter that Q to do the resdistribution. Then switch to OPV again. Can I enter the Q I found earlier or is it best to do it again?

EDIT: Or is it straight redistribution and then OPV?I haven't done any tests whether you should predict the Q which you should use in redistribution. When I use CCE, I simply use a value between 30 and 40. The fastest route is to use a generic value in redistribution and then do prediction against the new bitrates.

[Sharc]

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... :)

I basically agree, in particular what relates to poorly mastered originals with suboptimal bitrate distribution. The suboptimal distribution may not be noticeable when being played at the original rate.
However, the original has probably been encoded with a different encoding engine which most likely had a different characteristic (quantization, bitrate allocation, motion estimation etc.) and hence the original bitrate distribution may be suboptimal for the encoder which is used for the backup. The "Q" is a highly nonlinear process. I am not an expert though, just speculating.

[~bT~]

I haven't done any tests whether you should predict the Q which you should use in redistribution. When I use CCE, I simply use a value between 30 and 40. The fastest route is to use a generic value in redistribution and then do prediction against the new bitrates.

cheers mate. gonna try it out tonite. :thanks:

[Sharc]

But that distribution between segments has already been done -- in the original encode.
Yes, but the encoder for the backup knows nothing about the past or how the original has been encoded. It just gets frames served one by one (as good or as poor the original is) and tries to make the best out of it given a constant Q for the entire movie (OPV) or an average bitrate on a cell per cell basis (VBR multipass).
I feel OPV gives better results when the original bitrate distribution is "skewed" or when complex scenes are marginal in the original, and less demanding scenes got abundant bits wasted.

[Boulder]

Like I've said, the method tries to maintain a constant quality throughout the video. Using the original segment bitrates means that you must trust the authors, and my experiences say that many times they don't know that much about MPEG2 encoding.

Also one point is that the original encode possibly has a bias towards CBR. The redistribution will nullify its effect completely - if you use any bias in your backup encode without redistributing the bits, you'll push the bitrate curve even closer to CBR.

[jdobbs]

Yes, but the encoder for the backup knows nothing about the past or how the original has been encoded. It just gets frames served one by one (as good or as poor the original is) and tries to make the best out of it given a constant Q for the entire movie (OPV) or an average bitrate on a cell per cell basis (VBR multipass).
I feel OPV gives better results when the original bitrate distribution is "skewed" or when complex scenes are marginal in the original, and less demanding scenes got abundant bits wasted. But DVD-RB does, because it scanned the original before the encoding starts -- and it's knowledge is reflected in the bitrates provided to the encoder. Lot's of testing has been done related to that argument... I very strongly disagree.

[gurkan]

But that distribution between segments has already been done -- in the original encode.

You can't expect the bitcurve to be identical in proportion between a dvd9 and a dvd5. What's passable in one bitrate isn't neceserely passable at another. Also, the movie has changed and new artefacts have been introduced. So the movie we're about to encode has to be considered new raw-material, not to be confused with the movie that was originally encoded.
So therefor, the original bitcurve that was used for a movie without artefacts and macroblocks no longer is useable.
To quote you from another post:
Unfortunately the encoder can't distinguish the macroblocks from the good parts
Where bits will be used to retain unwanted macroblocks also wanted details will be retained. Keep the same low bitrate as the original and both macroblocks AND details we want to keep will get worse, because the encoder can't see the difference. If you can afford a higher bitrate to retain macroblocks and details, use it. A low bitrate will only increase the macroblocks.

[jdobbs]

Ok this is turning into a debate and a lot of what I'd consider incorrect "facts" are being thrown about. I'll just have to disagree and leave it at that. I'll probably add something along these lines into DVD-RB for sources that are CBR or limited VBR (like DVD Recorder or digital broadcast realtime encoded input), because I think it has merit there. But the bitrate curve argument was finished three years ago after a lot of testing and proving.

[gurkan]

Ok. Sorry if I offended you. That debate took place before my time.
But, if you do, would it be possible to put some alternative in the rebuilder.ini for us who happen to disagree? It would be nice to have the choice to ruin my backups. :)

[Sharc]

@jdobbs
...But DVD-RB does, because it scanned the original before the encoding starts -- and it's knowledge is reflected in the bitrates provided to the encoder. Lot's of testing has been done related to that argument... I very strongly disagree.

May be I misunderstand it, but see for example cell no. 38 (= end credits) in my table (Example_1_.zip in previous post). At the reduction level of 62% DVD-RB allocates to cell 38 an average bitrate of 3305 kbps. I understand that in the subsequent VBR multipass encode this segment would be encoded at this average bitrate of 3305 kbps, with lower and higher swings according to the VBR mechanism and frame complexity. Still the average would aim at 3305 kbps for cell 38. Correct?

When doing a redistribution, the new average bitrate is reduced to 608 kbps for cell 38, because the Q-controlled encoder decided that 608 kbps is enougth for maintaining the desired "quality" given by the Q value, with lower and higher swings according to the actual frame complexity, but still maintainig an average of 608 kbps for cell 38. Means that cell 38 consumes less bits, and the free bits are available for redistribution to other more demanding cells/segments that will move closer towards the original bitrate, hence reducing the bitrate reduction for the demanding segment, which in turn should improve the quality of the encode (similar to blanking some extras for freeing up space).
Correct, or do I misunderstand something?

I agree that there is a risk that the bitrate reallocation might in some cases be abused for more accurately reproducing artefacts and noise of the original (poor) encode. This is definitely not what we want. But still, even the segments that benefit from the redistribution will remain below the original bitrate.

[Boulder]

@everyone: I intend to run a series of tests. The first test DVD will be Predator SE R2. It contains some rather still scenes and some with a lot of motion (trying to encode a jungle scene is a real test to any encoder). I try to post samples from a normal backup and a redistributed bitrate backup as soon as possible. I'm going to test 4-5 different kinds of R2 DVDs to get a good sample variance.

[gurkan]

@boulder
Nice.
A suggestion would be to pick out the two segments that differs the most between normal dvd-rb and redist. One where destrib is bigger than normal and one where normal is bigger than destrib. To see if the quality-gain in one segment justifys the quality-loss in another.

[jdobbs]

Ok. Sorry if I offended you. That debate took place before my time.
But, if you do, would it be possible to put some alternative in the rebuilder.ini for us who happen to disagree? It would be nice to have the choice to ruin my backups. :)We who seek the truth are never offended! If we can make encodes better -- I'm all for it. But I don't want to build false expectations...

The one thing to remember in all this is that for every bit you add to one section of the output -- you are subtracting a bit from another. If the sharp edges of a macroblock requires more bits to keep it sharp.... where are you sacrificing quality in order to do that? The only thing I can guarantee is that you are sacrificing somewhere.

Another thing to keep in mind.... Q for the most part means quantization. Quantization changes with different matrices... so you can't compare the resultant bitrate of one matrix to that of another.

[gurkan]

Yep. Changing the matrix between the projects would render the test useless.

[Boulder]

Another thing to keep in mind.... Q for the most part means quantization. Quantization changes with different matrices... so you can't compare the resultant bitrate of one matrix to that of another.But you are not supposed to look directly at the OPV encodes but the bitrates that are calculated from them..this means the final result should be roughly the same no matter what matrix you use. Of course, different matrices treat the frequencies differently, but it should apply on a general level.

It may take a while before I get the samples to you as I work the weeks and commute 3 hrs every day..I've also got two little kids so spare time is something I often don't have :) If anyone knows a good place where to upload the sample videos once I get them done, please post links here.

[Sharc]

Another thing to keep in mind.... Q for the most part means quantization. Quantization changes with different matrices... so you can't compare the resultant bitrate of one matrix to that of another.

Yes. The meaning of the Q factor in CCE is perhaps a little obscure. It relates to quantization and it relates to some other form of "quality" as I understand. In my example the value of Q for obtaining a DVD-5 target size - as a basis for the redistribution - ranged from Q=9 for Avamat6 to Q=58 for the original matrix (which is approx. CCE Default matrix coefficients divided by 2).

Looking forward to Boulder's samples.

[jdobbs]

Here's how I did my original tests on this subject of original allocation: I encoded the entire movie at a single average VBR bitrate, allowing the encoder to allocate across the entire 2 hours or so. I then did the same movie using DVD-RB and the original bitrate distribution across segments that it picks up during scanning. The maximum bitrate was identical on both. On the vast majority of titles I found that the bitrate curves of the two methods followed each other across the entire movie very, very closely. That drew me to the conclusion that the original VBR method (on the commercial source) took the entire stream into consideration on the vast majority of discs, and that the allocation using the two methods was roughly equivalent.

[Boulder]

That's not the same as what we're doing here so it looks like I really need to do the tests :)

The DVDs I chose are:

Predator SE
The Mask (the Jim Carrey movie)
Ed Wood
Keeping Up Appearances season 5 disc 1
The Two Towers EE disc 1
EDIT: Lapinlahden Linnut, Kuudesti laukeava (a Finnish TV series) - very low avg bitrate for an interlaced source, blocky video at times

I shall use CCE, vaf + 2-pass. No filters except for ColorMatrix when DVD-RB decides to put it there. CCE standard matrix in all bitrates, adaptive quant matrices off, DC prec 9 bits, GOP length 15 frames. Max bitrate at 8000kbps (because CCE is known to spike at times, also that's why the 3-pass), dynamic max bitrate allowed. Redistribution will be done at 100% sample size.

I'll run the projects with non-redistributed bitrates and redistributed ones and then try to choose the samples the best I can. I admit I'm biased but I'll try to look for both good and bad decisions.

[gurkan]

The maximum bitrate was identical on both. On the vast majority of titles I found that the bitrate curves of the two methods followed each other across the entire movie very, very closely.

Did you find the minority of titles, where they didn't follow eachother, better or worse without original bitrate distribution?

[~bT~]

@ Boulder

www.maxupload.com

[gurkan]

@Boulder
I guess you'e going to use 100% sample for the opv redistribution. If so, you may want to add that to the spec to make it more clear.

[Sharc]

Just a note:
I found little difference in the calculated redistributed bitrates for 25% sample size or 100% sample size, respectively. So in practice some time can be saved using smaller sample sizes, like 20 ...30% IMO. The deviations were less than 3% in my test cases.

[gurkan]

@Sharc
I'ld have to disagree. Using less than 100% would introduce chance into to the equation. There is no way to know that those 30% can represent the remaining 70% as well.
IMHO opinion it's imposible to draw any kind of conclusion from such a test.
Why be 97% sure you're right when you can be 100% sure? :)

[Boulder]

Yes, I'll be using 100% to avoid any errors in the calculations the best I can.

[Sharc]

I did some more analysis with my example and conclude as follows:

1. The cells that got more bits allocated did not really improve in quality. These were mainly scenes/frames which suffered from (slight) macroblocking in the original encode. So the bits were apparently primarily abused to preserve the sharpness of the macroblock edges, without substantilly retaining other details better.
2. The cells from which bits were stolen did not noticeably deteriorate. Apparently these cells got more than adequate bits allocated in the original encode.
3. The conclusion is that the original is probably suboptimum regarding bitrate distribution, means too flat. Complex scenes should have been given higher average bitrates, simple scenes would probably have tolerated lower average bitrates. => It was not possible to recover that "damage" by doing a bitrate re-allocation in the re-encode.

So much for my example. I expected actually better results when seeing the large swing after doing the redistribution. In this case it seems simply to indicate that the original is probably suboptimum. Again, this applies for my example. I am looking forward to other people's findings.

[jdobbs]

I'm planning to add an option for redistribution in v1.26. I'm thinking of its use mainly for realtime VBR encodes (like DVD Recorders) and CBR.

3. The conclusion is that the original is probably suboptimum regarding bitrate distribution, means too flat. Complex scenes should have been given higher average bitrates, simple scenes would probably have tolerated lower average bitrates. => It was not possible to recover that "damage" by doing a bitrate re-allocation in the re-encode.They were probably encoded with a high bias.

[Boulder]

I did some more analysis with my example and conclude as follows:

1. The cells that got more bits allocated did not really improve in quality. These were mainly scenes/frames which suffered from (slight) macroblocking in the original encode. So the bits were apparently primarily abused to preserve the sharpness of the macroblock edges, without substantilly retaining other details better.
2. The cells from which bits were stolen did not noticeably deteriorate. Apparently these cells got more than adequate bits allocated in the original encode.
3. The conclusion is that the original is probably suboptimum regarding bitrate distribution, means too flat. Complex scenes should have been given higher average bitrates, simple scenes would probably have tolerated lower average bitrates. => It was not possible to recover that "damage" by doing a bitrate re-allocation in the re-encode.

So much for my example. I expected actually better results when seeing the large swing after doing the redistribution. In this case it seems simply to indicate that the original is probably suboptimum. Again, this applies for my example. I am looking forward to other people's findings.Interesting findings, thanks for taking the time to analyse your samples. The results are mostly what I expected - trying to minimize the damage (i.e. prevent more macroblocking in already blocky frames) when re-encoding. The method is not the Holy Grail but a handy tool IMO.

Did you do any comparison between the redistibuted encode and a regular DVD-RB encode?

I'll get the last two regular encodes done tonight, then I get to doing the redistribution passes.

[Sharc]

Did you do any comparison between the redistibuted encode and a regular DVD-RB encode?


Yes, but only with very few I frames, so the comparison is perhaps not statistically relevant. In fact the results of the standard 2-pass VBR and the redistributed are virtually identical. Damage remains damage. I might, for final conclusions, also have to consider B and P frames, though.
At least I can say that the redistribution did not introduce more damage, but it is difficult to attest it a real benefit - in my case and as per present state of the (still limited and incomplete) analysis.

[Boulder]

Still, if the method doesn't improve the quality of the final result, it doesn't justify the extra time needed to do the redistribution pass.

Then again, it's difficult to say when the bits should be redistributed and when not..I just noticed before I headed for work that one test DVD is encoded with VBR but every segment has been encoded individually and every segment has the same average bitrate. It will be interesting to see the comparison between a regular and a redistributed bitrate encode. In theory, the redistributed one should look a whole lot better.

[Sharc]

I'm planning to add an option for redistribution in v1.26. I'm thinking of its use mainly for realtime VBR encodes (like DVD Recorders) and CBR.

Bitrate redistribution may perhaps also have its benefits when filters are applied (e.g. for noise removal, softening or sharpening). I have however not run any tests yet in this respect.

[Fishman0919]

Here's something from a while ago... I would use this way for encoding with cce 2.50 and 2.66 before I started using DVD-RB back around ver .20 'ish. I couldn't find on this doom9 but here it is from the /turkish.doom9.org


http://turkish.doom9.org/index.html?/mpg/cce-advanced.htm

[Boulder]

Here's one screenshot comparison. You need to zoom in to see the difference well..

In the first pair, pay attention to Legolas's face. There's some chroma noise there in the RB picture but not in the redist one.

In the second pair, look at the sky near Aragorn's face. There's macroblocking in the RB picture, which somehow disappears in the redist picture.

The first pair was taken from a segment in which the redist one has much more bits - 5665kbps compared to 4524kbps that the RB one has.

The second pair was taken from a segment in which redist had 3094kbps and the RB one had 3835kbps.

I need you to tell me which video sample looks better upon playback. Download link : http://maxupload.com/D58429D2. Pay attention to the scene change.

The pics are here : http://maxupload.com/26DF01F1

More later...

[Sharc]

I'm planning to add an option for redistribution in v1.26. I'm thinking of its use mainly for realtime VBR encodes (like DVD Recorders) and CBR.

They were probably encoded with a high bias.

I did a new test with my sample:

- adding the parameter cpu=3 in the mpeg2source("................",cpu=3) as a filter against macroblocks
- then applying the redistribution

The bitrate redistribution - see attached file, yellow marked columns - is very similar to the one without using the cpu=3, however the macroblocks were significantly less prominent, and I did not notice a loss in useful details.

@jdobbs:
I wonder if it would make sense to include an option in Rebuilder 1.26 for inserting the cpu=x parameter in the mpeg2source() line. I think it could be useful even for standard VBR encoding, to prevent abusing the bits for the reproduction of sharp macroblock edges in non-perfect originals.
There are other macroblock filters, but I found the cpu=3 in dgdecode very effective and fast.

[Boulder]

There is the option, MPEG2SOURCE_OPTS under [Options]. It was added recently. For CPU=3, you would use MPEG2SOURCE_OPTS=cpu=3..though I would use CPU=4 ;) I actually always use CPU=4 in all my encodes. It increases compressibility by a substantial amount but it's still very gentle to details.

[Sharc]

:thanks:
I was not aware that this option is already available!

[jdobbs]

In the second pair, look at the sky near Aragorn's face. There's macroblocking in the RB picture, which somehow disappears in the redist picture.

The second pair was taken from a segment in which redist had 3094kbps and the RB one had 3835kbps.I gotta be honest... I'm of the opinion that there's some kind of flaw in your testing method. I think you'd have to agree that you can't, no matter how hard you try, get a better picture by reducing the bitrate. The best goal you can expect would be to get one that is either as good, or not noticably worse.

[Boulder]

I can upload those two segments and you can see for yourself..it will take several hours though. I'll also doublecheck myself.

Maybe CCE is simply smoothing the image as the bitrate is lower, I wondered about that myself too you know.

[~bT~]

I can confirm that the redist method does wonders.

I encoded the same movie, once using normal settings in RB and the other using redist with the other settings the same.

Problem is, I cant back my findings up as I had to get rid of the files to make space on my HD for a new project.

Anyway, i'll be sticking to redist method. Thanks Boulder!!

[Sharc]

I need you to tell me which video sample looks better upon playback.
The pics are here : http://maxupload.com/26DF01F1


Nice job.

Here my vote:

Pictures:
Pair 1: redistributed is better
Pair 2: about the same, depending where we look at
=> Overall I give the redistributed a PLUS

Movie:
I give the file ttt_3.demuxed.m2v a PLUS
=> less macroblocks, less encoding artefacts (less mosquitos), less color spillover

[Boulder]

I snipped a short clip of that dark scene for you to assess. That scene might be something that should also be tested with HC.

http://maxupload.com/20AA3D83

[gurkan]

ttt_3.demuxed.m2v looks slightly better in my eyes as well.

out of curiosity:
what's your vbr bias and qual prec(quantizer characterisitics) for these encodes?

[Sharc]

I snipped a short clip of that dark scene for you to assess. That scene might be something that should also be tested with HC.


I cannot really give a preference this time, from a viewing point of view. So at the end I would say the winner is the one with the smaller file size .....

[jdobbs]

I don't want to sound too harsh. I even like to think that I always keep an open mind... but, if anyone believes that I will somehow be convinced that lowering bitrate can improve picture -- it's really a lost cause. Assuming no flaw in the encoder, and the same parameters being fed to the it, I will stick firmly to the limitations of the laws of mathmatics and physics.

I've seen some very compelling testimony that an alien spacecraft crashed at Roswell... but that doesn't mean I take it as fact.

Of course that's just me... everyone is entitled to his/her opinion -- and RB-Opt is right there for use if people want to redistribute. :)

[Sharc]

... but, if anyone believes that I will somehow be convinced that lowering bitrate can improve picture -- it's really a lost cause. Assuming no flaw in the encoder, and the same parameters being fed to the it, I will stick firmly to the limitations of the laws of mathmatics and physics.

I very much agree, but given this a fact, one would also have to admit that if the stolen bits are thrown into another cell which then gets less compressed there is at least a chance that this cell will improve .... from the very same argumentation :D . The question is just if the benefit is greater than the loss or vice versa.

[jdobbs]

I have no doubts that adding bits will improve an encode. So when you redistribute, all the cells that went up could theoretically improve as long as they don't go higher than the original bitrate. No argument there. In fact the only argument involved in that side of the equation might as to whether it is noticable -- but for the sake of argument, let's assume it is.

That brings us to the other side of the equation. The exact same logic would dictate that every cell that lost bitrate would have to degrade. Period. No room argument. Fact. Again the argument might be made, again, as to whether it is noticable.... but it ends there. Saying it can improve only invalidates the argument. It is like saying 5-2=4.... you can write it on paper, you can say it out loud, you can even post it in on a forum. But you can't, no matter how hard you try, make it true.

That doesn't make redistribution wrong... it is possible that the improvements made on the "up" side of the equation can more noticably (but subjectively) improve the viewing experience than the "down" side degrades it. That's feasible -- and is more what I thought I might hear as an justification for the method.

Something I noticed, though... when you save the settings with RB-Opt the minimum bitrate is changed from 300 to 0. So in order to make a one-to-one comparison, you'd have to do the same in the regular RB encode. I'm not sure if there are other differences. RB sets it to 300 to prevent "hangs" on certain sources when using CCE.

[Sharc]

Exactly. Fully agree!

I
Something I noticed, though... when you save the settings with RB-Opt the minimum bitrate is changed from 300 to 0. So in order to make a one-to-one comparison, you'd have to do the same in the regular RB encode. I'm not sure if there are other differences. RB sets it to 300 to prevent "hangs" on certain sources when using CCE.

Interesting point. I was not aware of it. I think it is the same as with OPV in this respect (?).

Anyway, I found this debate more interesting and challenging than discussing how to fill the last 10 MB on a DVD-5.

And finally, with regard to the spacecraft at Rosewell, I am probably the one who would go there to check with my own eyes if it's true or not ..... :)