Suggestion for a new method of bitrate distribution

[robot1]

Something I noticed, though... when you save the settings with RB-Opt the minimum bitrate is changed from 300 to 0.
That would be a bug :(
I'm trying to reproduce it right now.
[OT] Have you solved the problem you talk in the RB-Opt thread?

[jdobbs]

That would be a bugSorry, don't waste your time... I found the problem and it was in between the keyboard and the seat.

[Boulder]

VBR bias was set to 0 and quantizer characteristics were 16.

I'm going to encode that dark scene with HC with the original, RB-calculated avg bitrate and the redistributed one. I have a feeling that CCE does some smoothing - as you can see from those sample videos I posted, the redistributed one uses a higher quantizer which in theory should degrade the image more. IIRC the original quant in those parts of the frame was 5 and the redistributed one had 7 or so.

EDIT: Oh, in that first video sample, the file ttt_3.demuxed.m2v is from the redistributed encode. While looking at the samples, I also noticed how bad CCE's scene change detection is..no wonder that scene change looks so bad as it's P-B. It takes a few frames to get to the next I-frame which will fix the video again.

[Boulder]

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.This is something I'm trying to research here as well. As we're talking about MPEG2 encoding which deals a lot with psychovisuals, evaluating results is not that easy.

Still, encoding with HC shows (to my eyes) that the encode with a lower avg bitrate looks better, at least in per frame analysis. See the bottom left corner, the macroblocking is less evident in the redistributed encode (avg 3094kbps) than in the original one (3835kbps). Aragorn's face gets a little smoother though, but I don't know if it's good or bad in this case.

There's also pics of Excel graphs showing the bitrate distribution for three movies I have in the test. It shows that the biggest difference seems to be some kind of bias. The original bitrates are rather flat compared to the redistributed ones.

http://maxupload.com/3BA18D0E

[jdobbs]

I think the best way to do it is to use AVISYNTH's StackVertical() function. Then the two sources can play the same frames at the same time on the same screen so you can do a realtime full-motion comparison. I like to slow it down a little with AssumeFrameRate() to make it easier to see.

Of course the result will be subjective and you always have a tendency to see what you were expecting to see -- but in MPEG pretty much everything is subjective.

[Boulder]

Too bad it won't fit on my display, 720x576 two times is a bit too much :( TTT might just make it if I get rid of the borders.

[jdobbs]

Ok. I just did some testing with StackVertical and AVISYNTH comparing some encoding I did of X-Men 3. In segment 16 of the main movie I noticed that the redistributed one is smaller than the original RB one (BR 2613 as opposed to the original 3313).

The difference is immediately noticable -- but not in blocking etc... the lower bitrate that was created by redistribution is very obviously missing detail, especially in darker areas of the screen. If you try something similar, I think you'll see the same.

You can also try StackHorizontal().

[Boulder]

I'll try to find a good scene to compare. Ed Wood had one in which the difference between the two average bitrates was quite big, I'll check how it looks.

[gurkan]

@jdobbs
Did you find that the increase of detail, etc, in other segments justified the loss of detail in segment 16 (and presumably others)? Or were they not as noticeble?

[Rippraff]

Sorry guys, but I can't follow your discussions anymore.
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.
I totally agree with this, but this is only the bitrate side. And for high quality originally encoded discs this is also valid for the quality side.

But what about originally badly encoded or CBR dvds? In these cases I can imagine that bitrate redistribution is a good idea.
Say you have a credits segment which would look fine with an average bitrate of 1000 and you have a CBR encode with 3000. Of course you would lose bitrate with redistribution but I doubt you would notice a quality drop for this example.

@Boulder
Having said this, I'm wondering why you just chose LOTR as an example which isn't CBR nor badly encoded (and I guess the same goes for X-Men 3).
And frankly speaking if I have to zoom in to see a difference then it isn't worth to spent extra work IMHO.
No offence intended, your testings are much appreciated but I'ld like to see differences on CBR sources. Unfortunately I don't have such material.

Cu Rippraff

[jdobbs]

As I said earlier, it may be possible you may get an improvement on CBR or VBR that is encoded with a limited scope (like DVD Recorders). But even then you really couldn't do any better than the original CBR bitrate. So if the CBR was set at, say, 3000Kbs... then any segment that came in higher (in the redistribution) than 3000Kbs would only be using the extra bits to try to recreate the errors of the original CBR encode (at any point in the segment).

The problems with CBR comes on the high demand side. Sometimes in CBR bits are wasted on scenes that don't need the bitrate... and there's not enough for scenes that could use it. But once it's encoded, it's too late to recover the high end -- it's already lost in the first encode.

If, though, your new encode had an average VBR bitrate of less than the original CBR rate (as you might see on a DVD-9 to DVD-5 conversion) -- you could probably do a better job of keeping the original CBR quality (even at the lower bitrate) by using redistribution.

[jdobbs]

Ok. I just did some testing with StackVertical and AVISYNTH comparing some encoding I did of X-Men 3. In segment 16 of the main movie I noticed that the redistributed one is smaller than the original RB one (BR 2613 as opposed to the original 3313).

The difference is immediately noticable -- but not in blocking etc... the lower bitrate that was created by redistribution is very obviously missing detail, especially in darker areas of the screen. If you try something similar, I think you'll see the same.

You can also try StackHorizontal().Just an update. I've gone through some more of this... and it doesn't seem to be as obvious in some other scenes.

[Boulder]

The reason why I also tested VBR stuff is that I wanted to see whether redistribution would be useful only with badly encoded sources (=bad bitrate distribution). As you can see, I've got a couple of different DVDs to test. The last one is CBR, it's even labeled as such in the m2v stream! And it sure looks great..over 3hrs of interlaced video shot in the late 80s on a DVD9 at a constant bitrate:mad:

What I don't (yet) understand is the fact jdobbs points out : that you shouldn't use a higher avg bitrate than what the original has. I have lots of DVB captures which have a very limited bitrate range, and I intend to encode some video at the same avg bitrate that the original video has and also at a higher bitrate and see what happens.

[Sharc]

What I don't (yet) understand is the fact jdobbs points out : that you shouldn't use a higher avg bitrate than what the original has.

At least in one case this seems plausible:
Assume that the studio used the same encoder as we do for our re-encoding => Why should our re-encode produce a better result just by boosting the bitrate above the original encode? It cannot recover details that have already been lost by the original studio encode.

I am not sure however if there exists a chance for improvement when the studio encoder and the one which we use for the recoding are different, as they probably have non-identical caracteristics. Similar when we are using filters (eg sharpening) for the recode. This is very speculative, though.

At the end, we may still have the problem to decide a priori if to go for redistribution or not.

[gurkan]

What I don't (yet) understand is the fact jdobbs points out : that you shouldn't use a higher avg bitrate than what the original has.

That's what gets me aswell. And sure, it can't recover details that have already been lost by the original studio encode. But it would retain the details that haven't been lost.

To me it's fairly simple. 1 x 0,5 x 0,5 = 0,25
1 x 0,5 x 0,75 = 0,375

Where 1 = lossless quality
0,5 = original bitrate
0,75 = new redist bitrate

And by the way: 1 x 0,5 x 0,5 != 0,5

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.
Sorry, but you keep bringing it up, jdobbs. I just can't seem to let all these "facts" pass me by undisputed. ;)

[Sharc]

....... your testings are much appreciated but I'ld like to see differences on CBR sources. Unfortunately I don't have such material.
Cu Rippraff

Perhaps you have this one you could try with: Children of Men. Not CBR, but "almost CBR". See attachement.

[Boulder]

In any case, it is not as simple as not allowing to go over the original average bitrate.

There is the fact that encodes have been done using different quantization matrices, different encoders and different parameters for the encoders. The quant matrix alone makes things much more complicated, and that is why I do not believe that the bitrate should be restricted to the average of the original one. And as was already pointed out earlier, the material we are working on is not the same as what was used in the original encode. This adds more complexity to the equation.

Nevertheless, I find this discussion a good one, informative and also very civil. Let's try to keep it that way :)

[Sharc]

And here a case with a surprising similarity - I already began to doubt that such examples do exist.
No strong argument for redistribution in this case, but still: the bits of the long end credits are given to the movie.

[Rippraff]

As I said earlier, it may be possible you may get an improvement on CBR or VBR that is encoded with a limited scope (like DVD Recorders). But even then you really couldn't do any better than the original CBR bitrate. So if the CBR was set at, say, 3000Kbs... then any segment that came in higher (in the redistribution) than 3000Kbs would only be using the extra bits to try to recreate the errors of the original CBR encode (at any point in the segment).

The problems with CBR comes on the high demand side. Sometimes in CBR bits are wasted on scenes that don't need the bitrate... and there's not enough for scenes that could use it. But once it's encoded, it's too late to recover the high end -- it's already lost in the first encode.

If, though, your new encode had an average VBR bitrate of less than the original CBR rate (as you might see on a DVD-9 to DVD-5 conversion) -- you could probably do a better job of keeping the original CBR quality (even at the lower bitrate) by using redistribution.
Couldn't agree more. :)

Of course if they messed things up with the first encode you couldn't get better with a reencode (except useful filters but this is a completely different story ;)).
Sticking with the 3000 example I see the benefits with an intelligent redistribution that you hopefully stay around 3000 in high demanding segments in your backup.
But this implements that you must have other segments where bitrate can be saved.

And for the higher than original bitrate discussion, as we say here "you can't turn crap into gold". ;)
In my eyes it's logical that bitrates above original wouldn't help.

Cu Rippraff

[jdobbs]

Perhaps you have this one you could try with: Children of Men. Not CBR, but "almost CBR". See attachement.
That's (your graph in post #116) exactly the type of encode I believe this can help. But it's pathetic that the original is encoded in that way. The bad part is: I think those spikes above the original bitrate are all wasted bits... you just can't get back what has already been lost.

[jdobbs]

That's what gets me aswell. And sure, it can't recover details that have already been lost by the original studio encode. But it would retain the details that haven't been lost.

To me it's fairly simple. 1 x 0,5 x 0,5 = 0,25
1 x 0,5 x 0,75 = 0,375

Where 1 = lossless quality
0,5 = original bitrate
0,75 = new redist bitrate

And by the way: 1 x 0,5 x 0,5 != 0,5


Sorry, but you keep bringing it up, jdobbs. I just can't seem to let all these "facts" pass me by undisputed. ;)Sorry, but I just can't agree that it works that way. If I wanted to keep the "best" available detail -- I'd just copy that portion unmodified. What would the peak bitrate be? It would be the exact same as the original CBR -- with no spikes above.

I guess the only way I could imagine it any other way would be if my current encoder isn't very good, and it takes more bitrate to get the same picture. But I don't think that is the case with any of the DVD-RB supported encoders.

[jdobbs]

Does anyone have a good example of CBR or limited VBR encoding on an NTSC source? I'd sure like to get one for testing.

[Sharc]

That's (your graph in post #116) exactly the type of encode I believe this can help. .......The bad part is: I think those spikes above the original bitrate are all wasted bits... you just can't get back what has already been lost.

I think there is a misunderstanding here:
None of the peaks exceeds the original! The flat dark blue line represents the bitrate of the standard 2-pass VBR reduced bitrate of 65.4% according to DVD-9 to DVD-5 reduction.
The DVD original is therefore 100/65.4 higher, means it is in the 7200 ... 7800 range.
See attached graph (yellow = original) for clarification.

[jdobbs]

Oh. Yes, I definitely misunderstood that. That example is probably the best case I've seen for where redistributed bitrates can give you better output. Man, those may be CBR, but they are certainly high bitrates on the original.


@all

Here's an interesting test you may want to try:

1. Take a single segment and do a redistribution type pass on it.

2. Then encode it at a ridculously low bitrate -- something that you know is going to cause blocking and pixelation.

3. Then take that terrible output and do a redistribution type pass on it.

It's likely that you're going to find a higher bitrate requirement for reproducing the blocky, pixelated source than the original. But if you redo it at the same peak bitrate it won't look much different in the next run.

[edited] Added the third and fourth sentences after seeing the chart.

[Boulder]

@all: I'm currently running the RB encode on a CBR source and will run the redist encode after that. I should have some samples for you tomorrow if my time just allows.

I'll also run a test encode (original avg and a higher avg) on a DVB capture which uses a very limited VBR range and has a lowish average bitrate for the content.

[Sharc]

.....That example is probably the best case I've seen for where redistributed bitrates can give you better output......


I would say IMBO that the redistribution (or even basic OPV) produced visually better results in this case.
The great reduction was mainly applied - as expected - to dark or "flat" scenes. Maybe, if I would deeply analyze the dark scenes on a frame per frame basis I might discover some loss of detail and higher quant - perhaps. But would this loss of faint details in dark scenes be noticebale when watching the movie? At the other hand, bright and complex scenes have been boosted - means shifted closer to the original DVD bitrate (but still not exceeding the original). I would assume - without overanalyzing - that in these clear scenes any deficiencies are more visible and annoying than some loss of details or higher quant in dark scenes. The encoder (CCE) made hence a good decision how to reallocate the bits. It is possible however that another encoder might have taken a different decision.

[Sharc]

And here another example (Munich) with a rather flat distribution in the original.
I selected this one because it was cited elsewhere in this forum as an example for OPV producing "better quality" than multipass-VBR, and because people are looking for CBR type of sources. Yet this is en example for PAL.
I am always using the cpu=4 parameter in the mpeg2source, in order to avoid that the bitrate for the redistribution is primarily driven by residual macroblock edges in the original.

[Boulder]

Keeping Up Appearances:
http://img267.imageshack.us/img267/4000/kuapl4.th.gif (http://img267.imageshack.us/my.php?image=kuapl4.gif)
Note that the org bitrate graph means the one set by DVD-RB, the same applies to all graphs I created.

The following frames are from the field separated video as it's interlaced.

Here's one frame from segment 6 (higher bitrate compared to the original), first normal, then redistributed:
http://img267.imageshack.us/img267/5395/kuarb1nt8.th.png (http://img267.imageshack.us/my.php?image=kuarb1nt8.png)
http://img267.imageshack.us/img267/4605/kuaredist1yo9.th.png (http://img267.imageshack.us/my.php?image=kuaredist1yo9.png)

One frame from segment 39 (lower bitrate compared to the original), the same order:
http://img267.imageshack.us/img267/5329/kuarb2ky4.th.png (http://img267.imageshack.us/my.php?image=kuarb2ky4.png)
http://img76.imageshack.us/img76/7403/kuaredist2ft3.th.png (http://img76.imageshack.us/my.php?image=kuaredist2ft3.png)

In the first pair, the added bits really show up. The other pair shows the slight degradation when the bitrate is lowered, it was the worst case I could find when I quickly went through hi-motion scenes in that segment.

The question is as always, do the pros beat the cons? The bitrate redistribution method is designed to provide a constant quality level throughout the video. That means some parts will get more bits, some parts less. I guess everyone should answer the question himself, no one can tell you the right answer because there isn't one. I myself prefer constant quality but that's just my opinion.

[gurkan]

@jdobbs
Ok, this thickhead finally gets what you mean. A higher avg than the original would equal a bigger filesized encoding with
worse quality, so anything other than a straight copy of the segment would be rather stupid.
Case closed for me, at least. :)

A nice touch would be to have those copied segments excluded from the redist. calculations and add the remaining
over-the-avg-bits from those segments to the rest. Maybe throw in a 95% threshold as well.

[archaeo]

This idea - of adding bitrate above and beyond what the original source contained - reminds me of a debate on an old doom9 thread regarding the application of a filter called 'addnoise' by SansGrip. His idea for the filter was to add 'noise', or bitrate, during the encode to reduce DCT blocking. The thread is here: http://forum.doom9.org/showthread.php?s=&threadid=37135&pagenumber=1

Obviously the filter did not use Q as a means to distribute bitrate as does Boulder's idea, but the principle is the same in that bitrate is added to a frame/cell in an attempt to 'improve' on low bitrate sources. This seems similar to what people are exploring here in regard to determining the benefits of upping bitrate. As I recall, the debate was left somewhat open, with no firm conclusion.

[Sharc]

I am trying to find a rule as to when to apply bitrate redistribution.
Here my suggestion:

1. The compression factor of the standard reduction should be (<70%).
=> This leaves enough room for corrective bitrate swing after redistribution without exceeding the original bitrate,

AND

2. The variation of the original distribution should be (<15%).
=> The original bitrate distribution should be rather "flat".
Note: First and last cell to be excluded in the evaluation as these may contain intros and credits, or we may just disregard the "min" and "max" cells.

3. When applying redistribution, the inclusion of cpu=3 or 4 in the mpeg2source is recommended for suppression of macroblocks in the source.

The parameters in ( ) are for discussion, or may be user selectable.

I would expect that in these cases the redistribution produces equal or better results than the standard VBR multipass.

What do others think?

[Boulder]

Looks like a good basis to me. Actually I was going to ask jdobbs if he could add a graph in the prepare phase which would show the variance of average bitrates as the scanning progresses. One could use that as a helper item too.

[archaeo]

I would expect that in these cases the redistribution produces equal or better results than the standard VBR multipass.

What do others think?


Equal maybe, but better?
As I posted in the above thread, my question remains: Does the addition of bitrate to a cell above the original source level really just add 'noise' to the cell? There's no doubt that subtracting bitrate from a cell that can give it up and placing it into another that is below original bitrate levels is helpful, but the idea of a bitrate level going 'above' the original level is questionable. Perhaps, (as the sansgrip filter attempted) it can help in reducing blocking, but it will never be 'better' than the original bitrate level.

[Sharc]

Equal maybe, but better?
As I posted in the above thread, my question remains: Does the addition of bitrate to a cell above the original source level really just add 'noise' to the cell? There's no doubt that subtracting bitrate from a cell that can give it up and placing it into another that is below original bitrate levels is helpful, but the idea of a bitrate level going 'above' the original level is questionable. Perhaps, (as the sansgrip filter attempted) it can help in reducing blocking, but it will never be 'better' than the original bitrate level.

May be there is a misunderstanding here :
I am definitely not pleading for going above the original bitrate, and I am not expecting a "equal or better than the original" quality, but a "equal or better than standard multipass VBR" quality. This is possible without exceeding the original bitrate. In other words, I am not aiming at improving a poor original, we rather try to keep the perceived loss in quality due to the re-encode to the minimum by means of the proposed redistribution.

That may be well possible for cases similar to the one I showed in post #123. Up to now I normaly went straight to OPV in such cases, because I felt that even with an OPV undersize of say 100 .... 150 MB the result looked better - thanks to the redistribution of OPV. Just my personal perception, based on experience with CCE which uses its proprietary Q strategy. Actually I found more cases with flat distributions (or high bias) plus high average bitrates than I expected, maybe because on a DVD-9 there is simply enough space .....

Opposed to basic OPV, the new proposed method for redistribution eliminates the uncertainty with the file size, and in addition it will optimize the redistributed segement one by one in the subsequent multipass encode. Hence it combines the benefits of OPV for originals with a flat distribution (CBR or close to CBR) with the segment internal optimization of multipass VBR - at the expense of a slightly increased processing time.

Improving a poor original by throwing more bits than the original to some scenes is a different story, and I am very sceptic in this respect. The only case I imagine that this could make sense is in the context of sharpening filters.

[jdobbs]

Again I'd ask -- we need to look at VBR characteristics within the segments, not just the segment average bitrates to determine whether there actually is a "near CBR" source. Many discs, especially those without a lot of high action scenes will naturally have average bitrates that are close, the larger the segments, the more likely this is the case. But they may have extreme swings in bitrate at the VBR level (within the segments). Also, when using OPV for redistribution you are relying heavily on quantization to determine "quality" -- which is closely related, but isn't necessarily one-to-one.

I reiterate -- I think this is a good idea or CBR or limited VBR sources combined with limiting the upper bitrate boundary, but I'd caution against using it in most other cases. We need a little expectation managment applied here.

[Boulder]

Improving a poor original by throwing more bits than the original to some scenes is a different story, and I am very sceptic in this respect. The only case I imagine that this could make sense is in the context of sharpening filters.I would actually consider any filtering as another factor in the equation. I usually do at least light filtering, sometimes rather heavy motion compensated denoising if the source is really noisy. Many of you even use as strong filters as Deen. In these cases, I heavily suspect that the original bitrate should be forgotten as we're on a whole new playground. And I still state that whenever you don't use the exact same matrix as was used in the original, you can't say that the original bitrate really matters that much ;)

I've got some more samples encoded but probably don't have the time to check them tonight.

[Sharc]

......And I still state that whenever you don't use the exact same matrix as was used in the original, you can't say that the original bitrate really matters that much ;)


Hmm..., I am not sure if the Matrix matters that much. See for example the tests with different matrices in my post #44 or #87 (approval pending). The redistributed bitrates didn't change that much, nor did they deliver totally different swing pictures. In one example I also used the strong deen() filter. Basically all samples followed a similar redistributed swing pattern. Of course the initial Q changed (to approximate a DVD-5 size).

[Sharc]

Again I'd ask -- we need to look at VBR characteristics within the segments, not just the segment average bitrates to determine whether there actually is a "near CBR" source.


Good point. I might have to keep an eye on this as well.

[Boulder]

Hmm..., I am not sure if the Matrix matters that much. See for example the tests with different matrices in my post #44 or #87 (approval pending). The redistributed bitrates didn't change that much, nor did they deliver totally different swing pictures. In one example I also used the strong deen() filter. Basically all samples followed a similar redistributed swing pattern. Of course the initial Q changed (to approximate a DVD-5 size).But let's consider an avg of 3000kbps with the standard matrix and with Fox Home Entertainment. There's a huge difference, I'd say that FHE will look much worse at that bitrate and with a normal, 1.78:1 or 1.33:1 source. You would definitely need a higher bitrate if you are to use it.

Once again, this should be tested as well :)

[Boulder]

Here are some sample screenshots from the DVB capture re-encode. They clearly show that going above the original average bitrate is not useless. The original average bitrate was 2698kbps. I used the same in one encode, then encoded the other with an average of 4000kbps. The max bitrate was 8000kbps in both cases. The same matrix is used in all three clips. They are once again taken from field-separated video as the original is interlaced.

Original:
http://img168.imageshack.us/img168/4579/caleorg1fq9.th.png (http://img168.imageshack.us/my.php?image=caleorg1fq9.png)
Encoded at the same average:
http://img508.imageshack.us/img508/9597/calelow1ja1.th.png (http://img508.imageshack.us/my.php?image=calelow1ja1.png)
Encoded at an average of 4000kbps:
http://img253.imageshack.us/img253/6735/calehi1sf1.th.png (http://img253.imageshack.us/my.php?image=calehi1sf1.png)


Original:
http://img508.imageshack.us/img508/3271/caleorg2dj0.th.png (http://img508.imageshack.us/my.php?image=caleorg2dj0.png)
Encoded at the same average:
http://img253.imageshack.us/img253/3467/calelow2vl5.th.png (http://img253.imageshack.us/my.php?image=calelow2vl5.png)
Encoded at an average of 4000kbps:
http://img168.imageshack.us/img168/175/calehi2ig0.th.png (http://img168.imageshack.us/my.php?image=calehi2ig0.png)


Original:
http://img148.imageshack.us/img148/4199/caleorg3qc3.th.png (http://img148.imageshack.us/my.php?image=caleorg3qc3.png)
Encoded at the same average:
http://img299.imageshack.us/img299/982/calelow3ai7.th.png (http://img299.imageshack.us/my.php?image=calelow3ai7.png)
Encoded at an average of 4000kbps:
http://img168.imageshack.us/img168/1971/calehi3wp7.th.png (http://img168.imageshack.us/my.php?image=calehi3wp7.png)


I'll try to find the time to evaluate my CBR re-encode results when I get home. The bitrate variance in the redistribution is very high, ranging from 713kbps to 5189kbps. It'll still look like crap though as the average bitrate is way too low. If I was to do a real backup, it would be on a DVD9 in this case.

[G_M_C]

Here are some sample screenshots from the DVB capture re-encode. They clearly show that going above the original average bitrate is not useless. [...]

Let's not forget that there are simpler reasons when going above the original bitrate is not useless. Think for instance when you use the filter-editor, and put a slight sharpener in there (or produce something much more complicated). The script will then produce more details, and a higher bitrate could be called for. Especially when you do something like that, and also choose one of the custom matrices that are available a higher bitrate than the original is called for.

(or when you use DVD-RB as a "mediator-tool" like me; I use it to generate scrips, and than change source to the resised-to-DVD-size HD DVD/BR version. My backups than need more bitrate for shure :P. Anyway, when you can align the two versions, you'll end up with a better backup, than the original ever was. And YES it works ! But this routine of mine is not the reason why DVD-RB should change ;) )

[~bT~]

Do the redistribution, then switch to OPV in RB-Opt and let it do the prediction etc.
Just wanted to let you know that the way u suggested doesn't work so well. Final output is over/under sized.
Doing the OPV to find Q, then redist using Q found in OPV and then just entering the Q value in OPV brings it nearest to target.

[Boulder]

It should not be over- or undersized in either case, or if there is under/oversizing, it should be the same regardless of the way you do the redistribution. This is because RB-Opt should use the exact same values for available video space in the calculations. I think you should post the issue in the RB-Opt thread so that robot1 will surely notice it.

[~bT~]

It should not be over- or undersized in either case, or if there is under/oversizing, it should be the same regardless of the way you do the redistribution. This is because RB-Opt should use the exact same values for available video space in the calculations. I think you should post the issue in the RB-Opt thread so that robot1 will surely notice it.

hmmm, maybe im doing something wrong..:thanks:

[Sharc]

@boulder

To my eyes, increasing the bitrate to 4000 - ie above the original - reduced the macroblocking compared to the "recoded at the same avg" somewhat, but did not improve the already blocky original. The original is to my eyes the best quality, so it should be copied 1:1 for a real backup copy.
I assume that you set the bitrate yourself to avg 4000 / max 8000, ie it has not been set by the redistribution process. Still I would expect that the macroblocks in the original would drive the redistribution to similar high bitrates with similar results. I feel it would be better to limit the redistribution to not exceed the original or just to make a 1:1 copy, as the stolen bits from other scenes would probably make those scenes look unacceptably poor (?)

[Boulder]

Well, I've actually never talked about bringing back any details. I've said in many places that I intend to minimize the damage done by re-encoding. If I was to re-encode that video (a DVB capture), I would definitely not do that without some serious filtering - and that includes proper deblocking.

The problem is, like I've said many times, that the quality is not constant on many DVDs, some segments may look great at the cost of some segments looking bad. The redistribution method attempts to obtain constant quality throughout the video, no matter how long it is. Doing this I'm hoping that the stolen bitrate is not noticable where it was taken from but that it improves the segments where it is reallocated to.

[Sharc]

ok, but what irritated me a little is that the high bitrate did not bring back the quality of the original DVB capture, and I was wondering how the quality of those frames where the bits were stolen from would look like. I was mainly questioning the balance of the plus vs the minus - in this example.:)

[Boulder]

I didn't try to look for any minuses or pluses in that one, I have yet to author the DVD where that video will end up in. But as my recent samples have showed, there is a chance that the stolen bitrate will not be noticable but it can still improve the scenes where the bitrate has been raised. Seeing your bitrate graphs and mine, a big issue is probably the bias setting that has been used in the original encode. IMO it's not optimal to use a biased (i.e. flat) bitrate curve to determine the bitrate distribution.

You can never get back what you once lose in lossy encoding but you can try to get by :) I'd still say that I can make the re-encode of that clip look better than the original, blocky mess. It's not even hard as it's so bad looking ;)

[Sharc]

I didn't try to look for any minuses or pluses in that one, I have yet to author the DVD where that video will end up in. But as my recent samples have showed, there is a chance that the stolen bitrate will not be noticable but it can still improve the scenes where the bitrate has been raised.

Yes, understood.
But this brings me back to the question as to what to compare with what when exceeding the original bitrate. I think in this case we should compare with the original as a reference rather than with the re-encoded standard VBR. If exceeding the bitrate does not improve the quality of the original the best is to copy the original untouched rather than boosting the bitrate by stealing the bits from other scenes. No ciriticism on the experiment, though. Just an interpretation of the results.
Opposite, when we stay below the original bitrate with the redistribution, it makes sense to compare the redistributed clip with the standard VBR.

Seeing your bitrate graphs and mine, a big issue is probably the bias setting that has been used in the original encode.

Agree that a high bias in the original is an indicator for a potential benefit of using redistribution. Perhaps it is tempting to go for a high bias when there is ample space on a DVD-9. Means there is room to lift the average bitrate for less complex scenes. No harm for the original, but perhaps suboptimum for a subsequent linear reduction in DVD-5 backups.

[Boulder]

Yes, understood.
But this brings me back to the question as to what to compare with what when exceeding the original bitrate. I think in this case we should compare with the original as a reference rather than with the re-encoded standard VBR. If exceeding the bitrate does not improve the quality of the original the best is to copy the original untouched rather than boosting the bitrate by stealing the bits from other scenes. No ciriticism on the experiment, though. Just an interpretation of the results.
Opposite, when we stay below the original bitrate with the redistribution, it makes sense to compare the redistributed clip with the standard VBR.Unfortunately there is no way to compare but a pair of eyes :( Also the option to use the original segment would apply only when you don't filter at all, deblocking and all included. However, IMHO the cases where the average bitrate of the original source is exceeded are very rare and usually apply only with CBR and limited VBR range sources.