View Full Version : RB v1.26 bitrate redistribution
Sharc
19th August 2007, 15:45
Was the blocky output on a very small segment (like less than 500 frames)? I noticed that on one I did where there was a fade-in to an announcement. It was caused by the fact that only the blackness (before the fade-in) was used as the sample.
I have seen this recently on a short segment with few seconds blackness (voices only) followed by a short flash of few motion picture frames, then again blackness with voices for few seconds etc => The sample retained mainly the blackness and the redistributed bitrate was set too low.
I would suggest to use 400... 500 frames as the minimum for redistribution. If the segment is shorter than these 400 ...500 frames all frames of the segment would be used. In my case this has solved the problem as the short flashes of motion pictures were fully included in the sample.
jdobbs
19th August 2007, 15:55
Yep. That's what I've done. If it is 500 frames or fewer I just do a 100% sample.
jamewoong
26th August 2007, 11:29
Was the blocky output on a very small segment (like less than 500 frames)? I noticed that on one I did where there was a fade-in to an announcement. It was caused by the fact that only the blackness (before the fade-in) was used as the sample. I've made some adjustments for the next release to prevent that.
The problem occurs on black areas and during a FADE-IN. Don't know how many frames, but it's less 3 secs during the fade-in. For the black area, it always mess up.
That's a lot of extra time for doing a sampling??? You didn't change anything else?
Well, I navigate through this thread and as you said, people give good comments, so I trust them and BAAM, I got the bad result after encoding a DVD with this feature. Normally, I don't add any filters as I don't have any knowledge on it. So, no extra setting.
Carpo
26th August 2007, 22:59
nevermind
jamewoong
2nd September 2007, 07:59
Well, this is a problem when I enable the redistribution:
http://www.mediafire.com/?d1yz1dn9igg
It give some quality to other part, but it destroy some part too.
And this one occurs 1/50 times (really rare case):
http://www.mediafire.com/?dwhmcuuojg4
I'm not sure, but I think the redistribution was enable. And no, the original DVD was not scratched or anything.
Sharc
2nd September 2007, 09:06
File 1:
Average bitrate of 1 Mbps in this short test sequence is low. Is the same scene without redistribution ok? Can you post the redistribution.txt file?
Which encoder did you use for redistribution and for encoding?
File2:
Looks like a bad rip or poor burn/media problem to me.
jamewoong
2nd September 2007, 21:07
File 1:
Average bitrate of 1 Mbps in this short test sequence is low. Is the same scene without redistribution ok? Can you post the redistribution.txt file?
Which encoder did you use for redistribution and for encoding?
File2:
Looks like a bad rip or poor burn/media problem to me.
Well, it's a serie and I encoded it few weeks ago with Procoder, so everything (info) is deleted. I think this problem could be solved if I've got the txt info, but... D*mn it, why did I delete it?
Between, each episode was reduced from 1400MB to 880MB. It's a lot, but if you compare the quality of the good image with the broken one, then this is not normal. The other part is okay, but this one is messup... I only remember that the Q base was 48. Don't know if it helps...
Anyway, I notice it when burnt it to DVD, then watched it on TV as it's impossible to test it on PC because I'll lose my fun about watching that serie.
FILE 2: It was like that after the encoding. The original source is perfect. It could be a problem from the redistribution...
Sharc
2nd September 2007, 23:16
.....so everything (info) is deleted.....
Difficult to help then.
You could however quickly redo the re-distribution in 3-click mode - without encoding - and post the redistribution.txt. That doesn't take much time.
You may want to redo everything with HC - means redistribution and encoding - and set lumgain to 3.
If the problematic scenes have been in a very small segment, you may also select a higher sample size instead of the default 10%.
Actually I can't comment much on the combo HC (for redistribution) with Procoder (for the encoding) because I have no experience with it.
Dashiell
5th September 2007, 16:35
I think I have found quite the match for the redist feature.
National Geographic's "Inside 9/11" disc one. granted there is nearly 4 hours of content on this disc, but I noticed an extremely low bitrate and blocky picture during program #2, about an hour in...
It is a frenetically edited program, with a multitude of flash cuts and various types of source material... too numerous to even try and mention. there were entire sections of programming that were under 1000k and extremely blocky. It would then shift to different types of video and clear up.
I was using version 1.26.2 of rebuilder, CCE Basic and the HC Redist feature. Perhaps this disc can be considered a "tough case scenario" for testing?
Boulder
5th September 2007, 16:41
Out of interest, what does a non-redistributed backup look like?
Dashiell
5th September 2007, 16:59
Out of interest, what does a non-redistributed backup look like?
Good question, and I have not tried as of yet. I may try it tonight and see what happens.
jdobbs
5th September 2007, 17:13
And the original.
Dashiell
5th September 2007, 17:18
Hey, J.
I have watched the original many times in the past, no such conditions exist.
Now that I have the moment, I have one other question as well...
When using HC as the redist encoder for CCE Basic, should the ConvertToYUY2() feature be unchecked in the settings? I know that ultimately CCE will be doing the encoding, but I was just wondering if this would have an adverse affect on the redist with HC...
jdobbs
5th September 2007, 17:33
I wrote the code so it will automatically adjust for that during REDISTRIBUTION.
Any way you could post the REDISTRIBUTION.TXT file from the "Inside 9/11" D2VAVS directory? I'd like to see if there are som obvious problems. Also -- give it a try with v1.26.3. I made some improvements related to this.
Dashiell
5th September 2007, 18:11
I wrote the code so it will automatically adjust for that during REDISTRIBUTION.
Any way you could post the REDISTRIBUTION.TXT file from the "Inside 9/11" D2VAVS directory? I'd like to see if there are som obvious problems. Also -- give it a try with v1.26.3. I made some improvements related to this.
Ach! I was going to do that very thing and then realized I had deleted the directory. I have made a couple rebuilds since.
Let me know what would be the most helpful... shall I do a re-encode under the same conditions using the new ".3" version or a re-encode without using redist at all. If both, let me know which one should be "priority." I will then check the quality in the same areas and post the .txt file.
jdobbs
5th September 2007, 18:13
All you'd need to do is a PREPARE to get the REBUILDER.TXT file. If you do it from .3 though it could very possibly be different -- especially if .3 fixed it.
If you can compare the two REDISTRIBUTION tables it will help identify whether REDISTRIBUTION had anything to do with the blockiness (or if it was just too hard to encode in the space available).
Dashiell
5th September 2007, 19:24
I do remember on the orginal encode the specified bitrate under "typical" in the H/L/T area was only 1,001. Even at that point I found it odd. I don't know if this info helps. I regret now removing the temp dir.
jdobbs
5th September 2007, 23:29
Wow. If the typical bitrate was that low it would be very difficult to get a good encode out of it.
rack04
6th September 2007, 01:05
jdobbs, do I need to have "apply redistribution to all VTSs (series)" if all episodes are in the same VTS? For your reference I'm refering to Heroes Season 1.
jdobbs
6th September 2007, 02:15
No. If they are all in one VTS just leave it at the standard setting. I found the same thing with "The Sopranos".
rack04
13th September 2007, 02:56
Does something change in the AVS creation with redistribution enabled? The reason I ask is because when I try to open the avs files created by DVD Rebuilder in Media Player Classic all I get is mess.
Dashiell
13th September 2007, 18:42
All you'd need to do is a PREPARE to get the REBUILDER.TXT file. If you do it from .3 though it could very possibly be different -- especially if .3 fixed it.
If you can compare the two REDISTRIBUTION tables it will help identify whether REDISTRIBUTION had anything to do with the blockiness (or if it was just too hard to encode in the space available).
Sorry for the delay...
Here's the redistribution.txt file you were looking for. This is the .3 version redist. (I've also included the rebuilder.txt)
This is the NG "Inside/911" disc 1. The issue occurs frequently within VTS_04
Boulder
13th September 2007, 19:19
Does something change in the AVS creation with redistribution enabled? The reason I ask is because when I try to open the avs files created by DVD Rebuilder in Media Player Classic all I get is mess.Post the contents of the script in question.
rack04
13th September 2007, 20:12
Post the contents of the script in question.
Sorry I don't have access to the files at the moment. I will post them when I get off work.
rack04
14th September 2007, 02:50
Well I found of the problem is with Haali renderer and not DVD Rebuilder. VMR renderer works fine.
Sharc
1st October 2007, 10:17
If there are different matrices in the segments, RB-Opt uses the matrix of the "average segment" for the prediction, and then uses the actual matrices of every segment for the redistribution pass.
Anyway, I'm convinced that if you want to use redistribution, you should use the same matrix for the whole movie.
("average segment" is the segment whose bitrate is more similar to the average bitrate of the movie)
@robot1:
Could it be added as an option (e.g. with an entry in the RBOpt.ini) to use the matrix of the "average segment" for the redistribution pass, i.e. keep the matrix which was used for the prediction?
robot1
2nd October 2007, 14:30
@robot1:
Could it be added as an option (e.g. with an entry in the RBOpt.ini) to use the matrix of the "average segment" for the redistribution pass, i.e. keep the matrix which was used for the prediction?
Sorry for the late reply. I hope to be clear in my poor english.
I think keeping the matrix used for the prediction, in this case, will bring at useless results.
Example: you have a Q factor = 30, calculated using the "average matrix" (let's say a medium-bitrate matrix).
If you have only one segment with a high-bitrate matrix, and you perform the redistribution pass with the medium-bitrate matrix, you will get a filesize lower than the one needed to have a quality similar to Q =30. In the actual encoding by DVD-RB you could get a bitrate equivalent to (let's say) a Q = 45: you could have pixellation.
I'm convinced that if you want to use redistribution, you should use the same matrix for the whole movie.
Sharc
2nd October 2007, 19:32
Sorry for the late reply. I hope to be clear in my poor english.
I think keeping the matrix used for the prediction, in this case, will bring at useless results.
Example: you have a Q factor = 30, calculated using the "average matrix" (let's say a medium-bitrate matrix).
If you have only one segment with a high-bitrate matrix, and you perform the redistribution pass with the medium-bitrate matrix, you will get a filesize lower than the one needed to have a quality similar to Q =30. In the actual encoding by DVD-RB you could get a bitrate equivalent to (let's say) a Q = 45: you could have pixellation.
It's clear what you say. I have found that using the actual matrix - instead of the one that was used for the Q calculation - for the redistribution pass increases the swing: The positive peaks are getting higher and the negative peaks are getting lower - which in tendency exposes the low bitrate cells to the risk of macroblocking. In a way a chicken/egg situation.
After all I agree that using one and the same matrix for Q calculation, redistribution pass and encoding is a good and safe strategy.
blutach
3rd October 2007, 00:18
Which is why limiting the szie of the swings of important IMHO.
Regards
march2006
3rd October 2007, 00:43
I dont know how to use this option for PROCODER3 and CCE SP2 ENCODING
tom942
25th October 2007, 10:31
After all I agree that using one and the same matrix for Q calculation, redistribution pass and encoding is a good and safe strategy.
So, when we are using Bitrate Distribution, is it recommended to use only one matrix for the whole process (CQ calculation, redistribution and encoding) instead of using in the encoding phase different matrices than in the CQ calculation and redistribution?.
I mean, for instance, in "Main feature" use "encoder's default", "low bitrate" use "avamat6" and "very low bitrate" use "avamat7".
Actually, I use the first way (one matrix for all), but I would like to know from the experience and opinions of others in the forum.
Regards.
dstalker
2nd November 2007, 16:52
If you use the preview/edit to change bitrates, you are overriding the decision made by redistribution.
It will reallocate the recovered space just like it always did -- but the new distribution will be used as the baseline. So the benefit of the redistribution is retained.
Yes, so you probably don't want to do that within the segments of the feature. But you could, after redistribution, reallocate bits from extras and they would be used in a way consistent with the redistribution. You could redistribute bits from something like the credits if you wanted to... I personally wouldn't, though.
Hello everyone.
After reading some of the posts I became confused concerning redistribution and segment editor.
To my understanding redist distributes bitrate among cells within VTS (thats why it is usually used just for main feature - to redistribute bitrate inside one VTS). So it should be possible to allocate different total space for individual VTSs and it would distribute that bitrate among cells (or segments) inside them.
But if I use it for all VTSs and then go to editor and change bitrate for extras, will it negate redist benefit?
According to second and third quotes that is not the case, but I don't understand how it retains those benefits. For example I have episodic disc so I use redist for all VTSs. There are some extras and I want to keep them but with lower bitrate then the series.
I can't use option to steal space from extras, because smaller series would be considered extras. Then again some extras are more usefull then others, i.e. I would assign less bitrate for trailers and more to music clips or other interesting extras. In this particular case trailers for some reason are automatically set to "no reencode" which results in them having higher average bitrate than any of the episode, while they are just good to have and quality is not as important.
So finally I would reduce extras and get more space for episodes. Question is if I should leave that extra space and DVD-RB will automatically increase bitrate for series (and not extras which I already reduced) proportionally to redistribution or should I manually increase bitrate for whole VTS (for each episode) and bitrate proportions inside it would be somehow maintained?
I tried to do the last, but when I lower reduction for whole VTS, reduction for individual segments inside it becomes even and the same as VTS, so I can't understant how the results of redist have any influence to final bitrate distribution. It looks the same as if I would adjust bitrate for individual segments inside VTS, and that was said to override decision made during redist.
http://img225.imageshack.us/img225/3021/rb1br7.jpg
Reduction level for VTS_04 after redistribution
http://img225.imageshack.us/img225/7366/rb11kw9.jpghttp://img216.imageshack.us/img216/1465/rb12te6.jpg
Segments inside VTS_04 have different reduction as it should be
http://img232.imageshack.us/img232/802/rb2ic0.jpg
VTS with extras is set to not reencode and gets higher bitrate than main features
http://img232.imageshack.us/img232/6793/rb3rv5.jpg
I reduce bitrate for whole VTS to ~60% to free up more space for main feature
http://img232.imageshack.us/img232/7688/rb4ck7.jpg
http://img232.imageshack.us/img232/8760/rb41oa9.jpghttp://img232.imageshack.us/img232/6684/rb42xg6.jpg
Then I change reduction for the whole VTS_04, and I would expect segments to have their bitrates increased proportionally to the values set by redistribution, but as you can see they are set to the same reduction value. And that makes their bitrates much more similar then it was before changing reduction for VTS.
So final question is - if I use editor not to blank something, but to change reduction for features of secondary importance in order to have more room for main features, how to keep the benefits of redistribution for these features (and maybe for secondary features if they contain several segments in one VTS)? If someone could explain the principle behind it, I would be grateful :)
Sharc
4th November 2007, 11:22
It looks as if the redistribution profile is flushed for VTS_04, i.e. whenever you change the reduction at the VTS_xx level, as all segments assume the same % reduction in proportion to the original.
You may want to give RB-Opt a try in your case.
jdobbs
4th November 2007, 11:32
1. If you reallocate the other VTSs (non-Feature) and then select "Allocate Saved Space to Feature", the feature will retain its redistribution.
2. If you select a reduction percentage at the VTS level (any VTS) -- you are instructing DVD-RB to reduce ALL SEGMENTS in that VTS to that level... so you are manually overriding any redistribution that may have previously occurred on that VTS.
Sharc
4th November 2007, 11:56
Thanks for clarification. May be this should go to the FAQ.
dstalker
4th November 2007, 22:13
Thanks for explaining. But now I'm wondering if "Allocate Saved Space to Feature" means to the main feature, aka biggest VTS? But then what about episodic DVDs?
It would be good to have some way of allocating that saved space to all VTSs that weren't reallocated manually, or maybe just to the selected ones, but I guess I'm asking too much :)
jdobbs
5th November 2007, 02:28
Yes, feature means the biggest VTS. There is no "feature" in an episodic disc... so you shouldn't use it.
JohnGalt
21st November 2007, 17:22
A stupid question: how do I change the percentage of video analyzed in the redistribution phase? Is it a hidden option in rebuilder.ini?
Fishman0919
21st November 2007, 17:34
Yes,
Redist_Percent=##
JohnGalt
21st November 2007, 17:57
great -- thanks!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.