D2SRoBa Plugin

[DDogg]

Gee, these are going to be a major work to reply to. Oh, well, part of my penance.

@r6d2
Yes, by definition it is. However, Tylos's statement is still correct, since what he does is precisely add RoBa support for OPV encoding method in DVD2SVCD. No it is not correct. This is a contradiction of terms. Tylo does not do a second avg BR pass, so by definition it is not RoBa, so he does not "precisely add RoBa support for OPV encoding". Even if he did add the second pass, it would still not be RoBa. At this stage, the important thing for the reader to understand is that Tylo's plug-in is not RoBa in the purest definition in that it is not a 2 pass. Rather, it is a derivative of 1-pass Bach which does not require the second pass. Some loss of accuracy (small) of final file size is the reult of not having the second Averaging VBR path.

Now, I think there are some things he could do that would make it a hybrid RoBa and in fact be even a better process than Roba, but let's get in to that later.

The nature of OPV requires you to find a Q in the accepted range defined by [0, Worst Q], in order to fill the CDs to the edge (or at least try). Fine, but OPV has nothing to do with RoBa.

With a huge difference to DVD2SVCD's CQ mode: you define the least quality you're satisfied with, and the plug-in determines the size. You cannot do that in standard CQ mode. This is correct ONLY if you use Auto or the ranges, else it is no different from the TMPG CQ predictive method D2S uses now.

Hope I'm not putting more hairs into the soup. Kinda, but the point of this whole thing is discussion, challenge and rebuttal (in a friendly way).

@Tylo
Robshot: selects a (Worst) Q for the initial pass, which creates the vaf file, and establish the compressibility of the movie. This is then used for computing the number of CD's required (as you say - inherent in the method).

Did you not mean to say above RoBA instead of RobShot?

The original RoBa method takes the long road with: one pass creation of the vaf, then redistribute the bits, then a second pass using the modified vaf information in order to 'achieve practical size targets', as you say.

You seem to be mixing the terms Robshot and RoBa. What you described immediately above is Robshot. To the best of my knowledge, Bach never said his method was possible without the second VBR pass using an average bitrate.

Instead, we cut the path by just finding a better Q (instead of doing bit-allocation redistribution), and then doing only one full VBR pass -the OPV method! Yes, that is exactly that. The OPV method. But it destroys the essence of RoBa in that OPV is a size control method instead of a quality control method. It is useful, but has nothing to do with RoBa.

That being said, although I am still in fuzzy think mode, I think it may be possible to actually create a hybridized system that does measure the potential compressibility of a source. However, that could never be a standard sampling as we are now using now as that is dependant on the sources length. It seems we must measure the compressibility of a source by using a randomized BUT exact same frame-count on all source.

As background, and for furthering conversation, let's all do an exercise. This is not randomized, but it illustrates the point. Take two or three sources and encode the first 10000 frames inset 10000 frames from the start. That is, trim(10000,19999). Do a 1-pass vbr @ Q=32. Record the size generated. It will all be different. The ideal case would be source 1 is something easy to compress like the Mtrx and the second source is very difficult, like SPR.

What results, with further refinement, is a form of constant such as bits per pixel or something like that which could be used to generate predictive information on how an encode would compress and use intelligent algorithms to give predictive information to guide the encoder in a better way. It would still use or provide as an option the true RoBa method's N passes using avg bitrate for sizing.

Tylo, Now THAT would be a mofo Plug-in!

Whew! I am tired! Ok, group, please work to tear up and refine the logic. I think we can get somewhere good if we work on it together.

/Add: Tylo, ain't it a pain trying to read a thread where the main poster erased everything. Arghhhh! Yes, I see your point in that I think your system certainly does approximate the 1-pass Bach method which differs from the RoBa method. The 1-Pass Bach method, IMO, is inherently flawed as it can never give exact size prediction or more importantly constant quality. Would you agree or disagree with that statement?

Given the faster speed of inexpensive processing power available now I think the original RoBa method using just two passes (1 opvbr, 1 avg BR VBR) is the best compromise. D2S internal RoBa mode does this very well (I have not had any more problems with it). However, not knowing how many disks you will end up with is a little difficult for a control freak to swallow :) A tool that would generate a size prediction based upon the apparent compressibility of a source would be useful.

[Holomatrix]

I’m glad you guys are working this out :) I started getting a headache a few posts back :)
“em ot sdrawkcab lla s’ti”

[tylo]

Did you not mean to say above RoBA instead of RobShot?
-- Yepp, I mixed up.

But it destroys the essence of RoBa in that OPV is a size control method instead of a quality control method. It is useful, but has nothing to do with RoBa.
-- I don't think you ever understood the [NumCDs=auto, Worst Q=X] combo. When you set Worst Q=X, it will encode a representative sample with Q=X. Now, the plugin computes the minimum number of CDs that guarantees that the final encoding uses an equal or better Q than X. That, my friend - is quality control, and has alot to do with RoBa.

generate predictive information on how an encode would compress and use intelligent algorithms to give predictive information to guide the encoder in a better way
-- You may well be on to something, but I think I'm too tired think about it now.

the main poster erased everything. Arghhhh!
-- I'm a forgiving person, but I'm having a hard time with this one. :mad:

1-Pass Bach method, IMO, is inherently flawed as it can never give exact size prediction or more importantly constant quality.
-- It is not exact, but that was never the point either - its close enough. The speed/quality is unbeatable. Constant quality can be achieved as explained above.

Given the faster speed of inexpensive processing power available now I think the original RoBa method using just two passes (1 opvbr, 1 avg BR VBR) is the best compromise.
-- I tend to agree, but we're not quite there yet with the speed. (maybe in a year or so).

not knowing how many disks you will end up with is a little difficult for a control freak to swallow
-- I thought that I was the control freak? :p ;)

/Edited.

[DDogg]

-- I don't think you ever understood the [NumCDs=auto, Worst Q=X] combo. When you set Worst Q=X, it will encode a representative sample with Q=X. Now, the plugin computes the minimum number of CDs that guarantees that the final encoding uses an equal or better Q than X. That, my friend - is quality control, and has alot to do with RoBa.

Yes, you may well be right on this and I promise I will work with that mode more so I may better understand it. [edit] As you know I was always fixated on controlling the final output size. Because of that, I think I never fully appreciated the other modes.

As for compression prediction, a friend suggested this simple method and it works well. Something is not right about it as the "2" is supposed to be 2 percent and if I increase it the frame count actually gets smaller. Maybe somebody can give me a fix. I am also too tired to think about it anymore.

Anyway, use the below and then divide the filesize by the framecount you get in CCE when you load the script. This will give a representative and comparative number that will definately indicate the compressibility of a source. It is very clear. This is just a rough concept and I am sure not very original, but it may help us.

SelectRangeEvery(Round((FrameCount() / (FrameCount() / 100 * 2))*60),60)

[r6d2]

Originally posted by DDogg
No it is not correct. This is a contradiction of terms. Tylo does not do a second avg BR pass, so by definition it is not RoBa, so he does not "precisely add RoBa support for OPV encoding".
You're making me confused by semantics, let me rephrase...

Robshot: Use Q="your target quality" to encode at the quality you want with OPV, then patch manually to get the size you want.

RoBa: Modify Robshot's CCE parameters to correct "conceptual errors" (quoting Bach), include automation. Still OPV first pass, Multipass from then on.

RoBaTy: Introduces the sample idea to find, based on your Q (conceptually the same Q of RoBa) a Q', equal or even better than Q, that gives you filled CDs and with one single pass.

Don't want to start an argument on mere semantics, but to me it is quite clear that Tylo's plugin is precisely based on RoBa method and he "adds RoBa support for OPV".

Your point is that by definition RoBa is multipass, I grant you that. But the concept behind RoBa is not multipass, which is just an encodig mode. The concept behind RoBa is: get always the quality you want and don't waste CDs.
Now, I think there are some things he could do that would make it a hybrid RoBa and in fact be even a better process than Roba, but let's get in to that later.
Our positions are not too far apart, I guess. Long live RoBaTy!
This is correct ONLY if you use Auto or the ranges, else it is no different from the TMPG CQ predictive method D2S uses now.
You are right, but support for fixed CD sizes is a byproduct of D2SRoBa, not its leit motif.
the point of this whole thing is discussion, challenge and rebuttal (in a friendly way).
Yep. I guess we are being very friendly then! :)
But it destroys the essence of RoBa in that OPV is a size control method instead of a quality control method.
@DDogg, OPV is the quality control CCE has, as CQ is to TMPGEnc.

In OPV, you define the Q.factor you want, and get the size (BR) as a result.

On the other hand, in Multipass VBR you set the BR you want, and get the Q.factor it yields as a result.
The 1-Pass Bach method, IMO, is inherently flawed as it can never give exact size prediction
Getting in again, I think you cannot get 100% precision but you can get close by sampling properly.
[...] or more importantly constant quality. Would you agree or disagree with that statement?
I disagree. Reasons on the paragraph above where I explain OPV.
D2S internal RoBa mode does this very well [...] However, not knowing how many disks you will end up with is a little difficult for a control freak to swallow
I also think the internal RoBa is great and best of both worlds.

My only problem with it is that since audio is encoded before video in DVD2SVCD, you are in danger to make choices about audio that turn out to be sub-optimal. For instance, going for 160 audio and the movie results to fit reasonably well in 1 CD... You might have reduced audio to get a better picture!

Or the opposite: you go for 224 audio and end up with 3 CDs, and the movie would have fitted correctly in 2 CDs with 160 audio.

Sometimes you might add a second audio track, too, but you're affraid to because you don't know beforehand how compressible the movie is.

Also, since we are in fuzzy thinking mode here, if a tool which analyzes the video before audio would exist, you could also make decisions on whether filters are needed or not, of if they are convenient or not, if the time impact they have is worth, etc.

ToK, for instance, lets you predict-only. You can make your audio and filter decisions before doing the actual encoding, with good data in your hands.

[DDogg]

Don't want to start an argument on mere semantics, but to me it is quite clear that Tylo's plugin is precisely based on RoBa method and he "adds RoBa support for OPV".

Yes, I think it is actually the wording that has caused me confusion. Actually I think it would be more accurate to say "Tylo's plugin is precisely based on the 1-pass Bach method" (which is another method, but not RoBa by a strict definition of the term. Assuming there is such a thing as a strict definition :))My only problem with it is that since audio is encoded before video in DVD2SVCD, you are in danger to make choices about audio that turn out to be sub-optimal. For instance, going for 160 audio and the movie results to fit reasonably well in 1 CD... You might have reduced audio to get a better picture!

Or the opposite: you go for 224 audio and end up with 3 CDs, and the movie would have fitted correctly in 2 CDs with 160 audio.

Sometimes you might add a second audio track, too, but you're affraid to because you don't know beforehand how compressible the movie is.

Also, since we are in fuzzy thinking mode here, if a tool which analyzes the video before audio would exist, you could also make decisions on whether filters are needed or not, of if they are convenient or not, if the time impact they have is worth, etc.
BTW, I think D2S is quite open to revisiting the automated internal RoBA mode as it is ideal for DVDs and would add a lot of sizzle to the package. I think Tylo sounds like he is also open to suggestions also. To that end I would suggest a condensed wish list, such as the excellent thoughts you brought up in your post and listed immediately above as a quote.

[Very Fuzzy mode on]
They, along with a intelligent method of indexing the compression characteristics of a source coupled with some form of rule based approach would be very special indeed. No, I have not thought it out, but something like the ability to establish certain actions based upon certain criteria. Maybe a separate rulebase tab that would simulate logic and allow the user to establish some user directions or guidelines for the program to help it deal with some of the decision problems you mentioned above.

[tylo]

Bach also suggested to switch the sequence of audio and video generation (without getting much credits for it). His motivation was that we could increase the audio bitrate to exactly fill the CDs (padding).

r6d2's suggestion is more useful, though. E.g. it allows to determine audio bitrate based on the 10% rule (audio 10% of video). Or, we can use it to adjust down the audio when the video oversizes a little (so that it still fit the number of CDs).

It should be fairly easy to add to the plugin (independant of using the D2S internal RoBa): Exchange BeSweet with a dummy prog that only creates an empty audio file (required by D2S). Then after the video is created, do the real BeSweet run with an adjusted bitrate.

Something is not right about it as the "2" is supposed to be 2 percent and if I increase it the frame count actually gets smaller.
/Edit: I was slow here: You want to add a SelectRangeEvery() in your avs?. I think this line should pick up about 'sample_frames' number of frames from the 'total_frames':

SelectRangeEvery(Round(sample_gops * goplen * total_frames / sample_frames), sample_gops * goplen)

In the example, sample_gops=4, goplen=15, total_frames=400000, sample_frames=100000

[homerjay]

:scared: oh my god :p :p

ive got one question that i havent seen mentioned above which im sure r6d2 will love but a few of us are trying...that is the 1cd method
i just want to clarify that currently what happens is that when you select number of cd's = 1 the program attempts to match your worst Q but in tests always ends at 63 given that Adjust Q is set to 0.7 or 0.8
my question is what does it do about the bitrate, when you do a 1cd encode in dvd2svcd itself you can rig the bitrate screen to have all lengths as 1 cd giving for eg a range for an 80 to 100 min film a bitrate between 1226 and 952 and for those adventurous types 100-120 mins 952-769
as i am writing this i am wondering whether i should just enter these in the d2sroba.ini for

max_est_brate=
min_est_brate=

any clarification would help at this stage and pleeeeeease ....not to techy ;)

[tylo]

@homerjay: Previous to version 2.4.6, the highes Q was 63, but the new version will automatically go up to 112. If the bitrate is still to high to match the target bitrate, I will highly recomend you to use 2 CDs instead!

The min_est_brate, max_est_brate are for the '?' option, so that will not help.

PS: If you really want to strech the Qs, there is another option: Set the really_worst_q in the ini file to e.g. 160. Remember that you must consider the 'Min bitrate' in D2S also. If that is set too high, you may never hit the target bitrate, no matter how high Q you use.

Try it, but be prepared to see some really blocky encodings :p

[homerjay]

thanks for reply tylo

but think if you havent looked you might want to scan ddoggs initial post in this thread regarding blockiness and motion adaptive filtering

http://forum.doom9.org/showthread.php?s=&threadid=58886

1cd encodes are on the increase and with kvcd being able to condense 2hours plus onto 1cd people are wanting to do the same with dvd2svcd

shame it wasnt as easy as setting the max_est_brate= & min_est_brate=
could this be encorporated ??

[r6d2]

@homerjay,

I think Tylo already answered you in his previous posting. You can get a 1 CD rip with D2Sroba a la KVCD, just sometimes its Q will be higher that 63. Try and see for yourself if blocks are there or not, and please tell us.

[telemike]

Hmmm.. I gots a problem. I tried making a copy of "Bad Boys" using D2SRoba (800mb disc, 1% sample, Q adjust .8) and my 2nd image file was oversize by about 20 MB making it too large to fit on a cd....

I was using the motion adaptive script.

I am trying it now with a cd-size of 740 for safety.

ANy ideas on what happened?

[r6d2]

Originally posted by telemike
Hmmm.. I gots a problem. I tried making a copy of "Bad Boys" using D2SRoba (800mb disc, 1% sample, Q adjust .8) and my 2nd image file was oversize by about 20 MB making it too large to fit on a cd....

This is a case of underestimation. I think your sample was too small. The higher the sample, the higher the precision, the longer the predictive phase. I'd not go for less than 2%.

Using 740 will do, but I really think that's not the point.

[Holomatrix]

Originally posted by telemike
Hmmm.. I gots a problem. I tried making a copy of "Bad Boys" using D2SRoba (800mb disc, 1% sample, Q adjust .8) and my 2nd image file was oversize by about 20 MB making it too large to fit on a cd....

I was using the motion adaptive script.

I am trying it now with a cd-size of 740 for safety.

ANy ideas on what happened?
What does the 20meg file contain? just credits? usually, just ignore the second image and use the first image. I use a 5% sample with good results.

I just tried to encode "Agent Cody Banks", Angie Harmon is awsome :), anyway I can't remember right now the minutes but it's not to long, anyway this is a very un-compressable movie. I ended up with a Q of 96 on one CD. Wow :( Looks like S**t using the MAF script.

[homerjay]

@holomatrix - that surprised me - using dvd2svcd i produced a fantastic quality 3pass 1cd of the same film two months ago ( it was an avi source though )took about 12 hours which is why i have been so interested in trying to understand this plugin :confused:

[Holomatrix]

I think I had mentioned such an opinion a little ways back about wouldn't I still get better quality if I just stick to a 3-4 pass encode rather than trying to fight with this OPV stuff :)

Are you talking NTSC as well?

[DDogg]

I ended up with a Q of 96 on one CD. See, this is where the compression index comes in. Once we get it figured out, a first small sampling pass will tell you immediately whether you have the possibility of doing a 1cd encode.

Holomatrix, would you please do me a favor and paste this in on the bottom of your script for that movie:

[/Edited - Avisynth seems to have a strange way of doing math]
SelectRangeEvery(Round((FrameCount() / ((FrameCount() / 100) * 1))*60),60)

Run a cce 1passvbr with Q=32 min=0 max =2616 (It will only take a few minutes. Divide the filesize of the MPV by the number of frames you see in CCE. Post back that number.

[telemike]

I did Cody Banks on 2 cd's. I just use D2SRoba in auto mode with a "Q" of 40 as my limit. I just figured out that I need to ajust my DVD2SVCD settings on the bitrate tab for BBmpeg to cut properly with Tylo's plugin.

This is what I think happened. My Q was underestimated causing the enode to be too large for 2 cd's. When DVD2SVCD recovered and started muxing it muxed it as 2 cd's and the second file was too large. I need to adjust the settings so that it would mux as 3 cd's and cut to size the 2nd one and have a leftover 3rd file........:angry:

Is there any way Tylo can add in his plugin that when DVD2SVCD recovers and starts muxing that it can increase the cd count by one just in case?

[Holomatrix]

Originally posted by DDogg
See, this is where the compression index comes in. Once we get it figured out, a first small sampling pass will tell you immediately whether you have the possibility of doing a 1cd encode.

Holomatrix, would you please do me a favor and paste this in on the bottom of your script for that movie:
SelectRangeEvery(Round((FrameCount() / (FrameCount() / 100 * 2))*60),60)

Run a cce 1passvbr with Q=32 min=0 max =2616 (It will only take a few minutes. Divide the filesize of the MPV by the number of frames you see in CCE. Post back that number.
Ok, I'll pump the modified script into CCE and get back to you with that number when I get back home.

[homerjay]

@holomatrix it was indeed ntsc - im in pal land myself though :rolleyes:

[r6d2]

Originally posted by Holomatrix
I think I had mentioned such an opinion a little ways back about wouldn't I still get better quality if I just stick to a 3-4 pass encode rather than trying to fight with this OPV stuff :)
My thoughts on the matter, just hoping to get a respectfull rebuttal:

In VBR, the more passes you do the more the encoder refines the high quantization spots. It does so by removing BR from the places where quantization is lower and moving it to places where it is needed. This will end up, in theory, leveling and uniforming quantization along the movie.

On a 1 CD rip you have little or none BR to spare. Even if there is some, multipass will just end up uniforming quantization. And guess what: OPV does just that from the start. It keeps quantization at the same level throughout the movie.

So, I see no reason why a multipass would produce a better encode than OPV. Of course I may be terribly mistaken, so if somebody could just tear apart the logic of this reasoning I'd be glad to learn about it.

[Holomatrix]

Originally posted by r6d2
My thoughts on the matter, just hoping to get a respectfull rebuttal:

In VBR, the more passes you do the more the encoder refines the high quantization spots. It does so by removing BR from the places where quantization is lower and moving it to places where it is needed. This will end up, in theory, leveling and uniforming quantization along the movie.

On a 1 CD rip you have little or none BR to spare. Even if there is some, multipass will just end up uniforming quantization. And guess what: OPV does just that from the start. It keeps quantization at the same level throughout the movie.

So, I see no reason why a multipass would produce a better encode than OPV. Of course I may be terribly mistaken, so if somebody could just tear apart the logic of this reasoning I'd be glad to learn about it.
Ok, I'll test this once and for all too :) When I get home I'll test a chapter with 3-pass (I'll check what bitrate Tylo's plugin picked and use the same bitrate for Max avg. for my 3-pass ofcourse) then test same chapter again with 1pass Q=96 and see what looks better. Do I need to change my Max bitrate to the bitrate noted above when doing this Q test?

[r6d2]

Originally posted by Holomatrix
Do I need to change my Max bitrate to the bitrate noted above when doing this Q test?
Use DDogg's magic numbers. As long as you use the same in both tests, the results should be comparable.

[Holomatrix]

Sorry, don't understand. Do you mean use Q=96 min=0 max =2616 ? So it's the Q number that is doing the "Max Avg" bitrate thingy, right?

[jsquare]

I tried D2SRoba with some interlaced/NTSC music videos and the results comes out with those interlace lines all over, works fine with film based movies.
Without D2SRoBa using 2-pass VBR the lines are gone but the video quality suffers, got some macroblocks even at high bitrates.

Any subjections?

[DDogg]

Holo,

The compression index we are working on has nothing to do with any individual encode. I am sorry if I confused you and note I edited the range line above to:

SelectRangeEvery(Round((FrameCount() / ((FrameCount() / 100) * 1))*60),60)

Please use 1-pass vbr Q=32 Min=0 Max =2616 No VAF, no audio, and RB's progressive template which has all the checkboxes turned off except 9, zigzag and progressive. (That Max is ONLY because I used that and I want to compare my numbers to your numbers. We will probably change that number later if this goes anywhere and tylo may have some better ideas on the script line.) Oh, I forgot to say, use Gert's standard semi-auto.

You might also then want run it using other scripts or add a filter as this will give you a clear indication of how they will increase compression, but that is another use entirely from the common index we can use.

What we are working on is a test that always uses the same EXACT numbers and always results in a replicatable indicator of the potential compression of a source. Once we get that, a program such as Tylo's, could do this test and potentially use that extra information to assist and guide you. Hey, it is just a thought and may not go anywhere.

Again, it has NOTHING to do with any individual encode. The reason I asked you to do it was because I am expecting the "number" on that encode you are doing to be much higher than say, "the Mtrx" which returns a remarkable lower number than most sources.

[Holomatrix]

@ddogg - yes, your test I understand, I was refuring to the second test I'm going to do comparing 1pass to 3pass.

[tylo]

No need to do all this. The information lies in the D2SRoBa_log.txt file.
- Movie length : 01:43:35 (149030 frames, 23.976 fps)
- Audio size est : 124315983. bytes (160 + 0 kbps)
- CD user data size : 833237920. = (800 - 5)*1024*1024 - 380000
- SelectRangeEvery : every 750, select 15 frames
- Num. sample frames : 2985
--------------------------------------------------------
Calculations:
- Estimated mpv size : 666565608. (Q=40, 857 kbps, 13350992 sample sz)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Number of CDs : 1
- Target mpv size : 689790437. (887 kbps)
--------------------------------------------------------
- Binary search for Q:
- Estimated mpv size : 759827533. (Q=32, 977 kbps, 15218984 sample sz)
- Computed mpv size : 713196571. (Q=36, 917 kbps, (Q40+Q32)/2)

Take the 'Estimated mpv size' for Q=32, and divide on ' Num. sample frames'
In this example: 759827533 / 2985 = 254548.58

This number should tell you something about the compressability of the given movie. The smaller number, the better compressability.

[DDogg]

Tylo, you are saying if Holo and I both run it on "the mtrx" we will both get the same number?

Ideally, I think it needs to be standalone, don't you? An app that loads a d2v and runs a compression test giving a index number. So that if Holo and I both run it on "The Mtrx" we both get the same number.

/add:
I guess if the plug-in had a compression test only button?

[Holomatrix]

I would assume we would get the same numbers :) and am I being stupid in asking if I use Q=96 min=0 max =2616 So it's the Q number that is doing the "Max Avg" bitrate thingy, right? I just need to know for my compairison test between 1pass and 3pass so I don't screw up the bitrating on the Q encode.

[tylo]

Originally posted by DDogg
Tylo, you are saying if Holo and I both run it on "the mtrx" we will both get the same number?

Ideally, I think it needs to be standalone, don't you? An app that loads a d2v and runs a compression test giving a index number. So that if Holo and I both run it on "The Mtrx" we both get the same number.

/add:
I guess if the plug-in had a compression test only button?
I'm getting a little lost here. :confused: Why would you want a standalone app. You must run D2S up to the video encoding anyway (except the audio creation).

When D2SRoBa terminates CCE (started by D2S), it begins its process by creating a new avs file, and running CCE compression tests. After the Q=32 test, simply right click the icon, then Exit the plugin. (D2S is terminated at this point anyway). Look at the log file and you can calculate the compression (Q32 mpv size / sample frames).
Why shouldn't you get the same size for the same source?
It differs with different avs-scripts of course.

@holomatrix: sorry - I don't undestand your question.

[r6d2]

Originally posted by Holomatrix
I would assume we would get the same numbers :) and am I being stupid in asking if I use Q=96 min=0 max =2616 So it's the Q number that is doing the "Max Avg" bitrate thingy, right? I just need to know for my compairison test between 1pass and 3pass so I don't screw up the bitrating on the Q encode.
Do the OPV with the above numbers and then the VBR with the same numbers plus the AVG you got from the OPV (size/time).

[Holomatrix]

Originally posted by tylo

@holomatrix: sorry - I don't undestand your question.
Ok, let me ask it this way then. To do a single chapter quality comparison test between a Q=96 1pass OPV encode and a 3pass VBR encode would I set the Q 1pass test up like; Q=96 min=0 max=2530 bitrate and the 3pass test up like; Max bitrate= 2530, Min bitrate= 200 and Max Avg. bitrate= 870 ? If that does not make sence then may you can give me instructions on how both test encodes should be set up.
Thanks

@r6d2 - posted right when you did :) right, so I should look in my D2Sroba ini for my line that says somthing like "Q=96, 870 kbps" and use the 870 as my Max Avg. when doing the 3pass?

[r6d2]

Originally posted by Holomatrix
@r6d2 - posted right when you did :) right, so I should look in my D2Sroba ini for my line that says somthing like "Q=96, 870 kbps" and use the 870 as my Max Avg. when doing the 3pass?
Yes, but actually it may be better if you take the total encode OPV size and divide by the length. The Q=96 line on the log is an estimate, not the real thing.

Also, if you're encoding just a chapter you'll have to adjust the CD size to accomodate for the corresponing fraction of the whole movie. Otherwise you'll surely get Q=1 :D

A simple proportion may do the trick, but it will not be exact because of the base size any CD has. If you want to match your 96 number you'll have to iterate changing the CD size (do it in both D2Sroba and DVD2SVCD).

Don't complain ;), you volunteered :)

[DDogg]

Tylo,

Well the whole point of the compression index is to have it incorporated INTO the app (not necessarily your plug-in) so that it automatically provides additional information for the decision process. In the case of your particular plug-in, I guess it already is incorporated in a way as you can look at the file-size from the Q32 run and perhaps incorporate more AI. Perhaps that information might be used to shorten your process somewhat. Dunno. That's your business.

My comment about the standalone was to provide a pre-diagnostic tool to allow people to know in advance what the compression characteristics of their source was. If this tool got into common use, a person tends to come to know what index is worth trying on say 1cd. That is to say, once a person is slightly experienced they know it would be just a waste of time to try 1 cd if the compression index is larger than XX.xx. Also, in the case of DVD2SVCD, the rule base tab we slightly discussed could use that as part of the decision process by way of an input box. If CI less than X then do X, else do Y

That common index number then also becomes a tool for communication. "Dear User, if the CompIndex is larger than XX.xx, then do you must increase the number of your target media by 1"

Also, in a forum environment, it would provide a better method of communication between us. "The CI on that DVD is way up there, like XX.xx, don't even try anything under X"

Like I said, this is just something I am throwing out to the group. Perhaps I should have stated a separate thread.

[Holomatrix]

Ofcourse I deleted the original encode but still have the d2sroba log. I just did that little test 1-pass vbr Q=32 Min=0 Max =2616 SelectRangeEvery(Round((FrameCount() / ((FrameCount() / 100) * 1))*60),60) on a chapter. 472 mpv/60 frames = 7.8666666. If I select a different chapter, would that not be different results.

Here is that log from the whole movie encode if it helps. The actual Q=96 mpv size was 39,924 7365 sample frames


D2SRoBa v2.4.6 - DVD2SVCD plugin, by tylo
OS Version: WIN_2000
--------------------------------------------------------
- DVD2SVCD Shutdown
- 2003-08-11 08:29:49
--------------------------------------------------------
Settings:
- CD size : 800
- Number of CD's : 1
- Worst Q. factor : ---
+ One pass VBR Robshot/Bach : 1
- Sample percentage : 5.0
- Sample GOPs : 1
- Adjust Q. : 0.8
- Safety Zone : 30
+ Do credits bitrate tweak : 0
- Start time : 0:00:00
- Bitrate : 1000
--------------------------------------------------------
- Movie length : 01:42:12 (147041 frames, 23.976 fps)
- Audio size est : 0. bytes (0 + 0 kbps)
- CD user data size : 833237920. = (800 - 5)*1024*1024 - 380000
- SelectRangeEvery : every 300, select 15 frames
- Num. sample frames : 7365
--------------------------------------------------------
Calculations:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Number of CDs : 1
- Target mpv size : 814106420. (1061 kbps)
--------------------------------------------------------
- Binary search for Q:
- Estimated mpv size : 1388297035. (Q=32, 1810 kbps, 69537120 sample sz)
- Estimated mpv size : 1190890670. (Q=48, 1553 kbps, 59649416 sample sz)
- Estimated mpv size : 902406569. (Q=80, 1177 kbps, 45199804 sample sz)
- Estimated mpv size : 816196661. (Q=96, 1064 kbps, 40881716 sample sz)
- Estimated mpv size : 780912411. (Q=104, 1018 kbps, 39114396 sample sz)
- Computed mpv size : 798554536. (Q=100, 1041 kbps, 39998056.=(Q104+Q96)/2)
- Computed mpv size : 807375598. (Q=98, 1053 kbps, 40439886.=(Q100+Q96)/2)
- Computed mpv size : 811786129. (Q=97, 1058 kbps, 40660801.=(Q98+Q96)/2)
--------------------------------------------------------
- Q Weight : 1.0 - (814106420. / 19.9648336727766 - 40660801.) / (40881716 - 40660801.)
- Adjust Q : (97 + (0.473920280414964) - (0.8)) = 96.673920280415
- Determined Q. : 96
--------------------------------------------------------
Replace values in ecl file:
- opv_q_factor : 96
- opv_brate_max : 1055 ==> 2530
- vbr_brate_avg : 2320 ==> 1061
--------------------------------------------------------
- Encoding Movie
- 2003-08-11 09:21:19
--------------------------------------------------------
- Actual mpv file size:
11/08/2003 11:56a 762329908 Encoded_Video_CCE_NTSC.mpv
--------------------------------------------------------

[DDogg]

You would have to do it on the whole movie as the source and as Tylo said, just use SelectRangeEvery(750, 15)

Not to worry if that is too much hassle. However, I think if you will do the process, and then divide the resulting file size by the frames and record the resulting number it will be of benefit to you.

Next time you do another encode, also do the same procedure. You will start to see a pattern in the number. Say you have recorded the number for one source which easily fits on 1 cd. If another source you want to try has a same or similar number, it too will probably fit on 1 cd, conversely, this problem encode you are doing now will probably throw a much higher number. Next time you see one like that you will know what to do.

[tylo]

One of the main motivation for writing the plugin was to automatically find and set optimal number of CDs.

But many other settings have to be done from one DVD to the next. So I then thought we needed an intelligent module. A rule based tab, where we could set up customized rules based on characteristics of the DVD, which could perfrom propriate actions/settings in DVD2SVCD. Well, we don't have that - but my plugin does help on some parts.

So yes, a built-in OPV test with Q=X could have given DVD2SVCD more to play with, when e.g. deciding the number of CDs to use.

Say you have recorded the number for one source which easily fits on 1 cd. If another source you want to try has a same or similar number, it too will probably fit on 1 cd
The CI (mpv sample sz/sample frames) says how well the movie compresses, which is interesting, but not so useful in itself. That is because it's independent of the length (you divide with it). If you only simply compare the 'Q32 sample size', from one DVD to the next, that may be more helpful for this type of decisions.
[A medium long movie with good compression, and a short with normal, may get similar 'Q32 sample size'. If one of them looks nice on 1 CD, the other will probably too].

You are wearing me out, folks - I think I'll need a rest :)

[Holomatrix]

Ok, Ok, :) I did my little test and r6d2 you will be happy to know that I didn't find that much quality difference between the two :)

@tylo - I can't wait to see what your next version of D2Sroba is going to look like :)

[DDogg]

The CI (mpv sample sz/sample frames) says how well the movie compresses, which is interesting, but not so useful in itself. That is because it's independent of the length (you divide with it). If you only simply compare the 'Q32 sample size', from one DVD to the next, that may be more helpful for this type of decisions.

As you well know, I am no math guy, but it seems to me you could calulate the length into the index somehow. Anyway, I'm not getting any support on the subject and I am tired also, so let's just consider it a mental hairball and let it go.

[r6d2]

Originally posted by Holomatrix
Ok, Ok, :) I did my little test and r6d2 you will be happy to know that I didn't find that much quality difference between the two :)
@Holo, I'd be surprised if you find any at all :D:D:D

[r6d2]

Originally posted by tylo
You are wearing me out, folks - I think I'll need a rest :)
You already had some vacation time, so here is my latest wishes added to the list :)

1. Would you implement a third encoding option besides OPV and Multipass, called RoBaTy, which selects RoBa in DVD2SVCD, and finds the Q for Internal RoBa?

2. Would you implement (or explain how it's implemented by the really_worst_q parameter) a threshold (as a percentage) to end the binary search when the result is found?

That's it and I promise to turn fuzzy thinking off ;)

(Edit: BTW, DDogg and I have exchanged some ideas on a Complete Idiot's guide to this stuff. We are working and you are not alone.)

[telemike]

Personally, I would like Tylo to keep the interface as simple as possible.

Not sure why the GOP thingee is there :confused:


I do like the option of picking Auto or the number of cd's.

I would like the option of having Tylo's plugin make CCE run at a low priority as an option so i can do other things while it enocodes.

Somehow make the status window not be on top of all other windows. It's cool to have, but would be nice if it didn't have to be on top all the time....:rolleyes:

Next would be to see if DVD2SVCD the programmer would incorporate the Tylo plugin into the program DVD2SVCD?

[tylo]

Hi, telemike

Personally, I would like Tylo to keep the interface as simple as possible.
Not sure why the GOP thingee is there
Agree, I put it there for experimental reasons and wanted to take it away, but was requested not to...

I would like the option of having Tylo's plugin make CCE run at a low priority as an option so i can do other things while it enocodes.
Has been up before. In EclCCE you can set idle priority permanenly. I may do that during the D2SRoBa setup from next release.

Somehow make the status window not be on top of all other windows. It's cool to have, but would be nice if it didn't have to be on top all the time
Has been up before. AutoIt (programming tool) can only open such a window - sorry

Next would be to see if DVD2SVCD the programmer would incorporate the Tylo plugin into the program DVD2SVCD?
Yes, if it was possible to skip the CCE phase from DVD2SVCD, it could rather call this plugin. Would be smoother.

[telemike]

I would like the option of having Tylo's plugin make CCE run at a low priority as an option so i can do other things while it enocodes.

What about CCE 2.50? I have not upgraded to 2.66+ since I have 2.50 running smoothly.

[tylo]

Don't think I can do it from the plugin. You can do it manually by opening the task manager | Processes, and change the priorty there.

[Holomatrix]

@Tylo - Can you please do me a favor and increase Auto extend q search to max 126 or higher. Or tell me how to do it thanks. I'm doing some testing right now with coloryuv(opt="coring", Autogain=true) and am getting great results even with Q 112 and with the movie above Cody Banks removing blocks and stuff. With this tuff compressable movie even at Q 96 and the script I'm using it looks good and with the chapter I'm doing I didn't even realize it was raining at one part until I added the line above and by using a res of 720X480 everything is looking clearer and no noticable blocking effect. Please and Thanks

[tylo]

Can you please do me a favor and increase Auto extend q search to 126 or higher Fortunately I added an alternative way: Set really_worst_q=126, or whatever, in the D2SRoBa.ini file, and you're all set.

[Holomatrix]

Awesome, thanks :)

[homerjay]

some test results and a question to all :sly:

ok im doing a 1cd conversion from a 102 minute PAL source using telemikes script from the MAF thread i got a very good copy (thankyou :D ) with a Q of 61

i then had a go with the big dog mysemiautocropandresizescriptMAF which came up with a Q of 48 except i had missed out the part where i was supposed to take the figures from autocrop preview and feed into the actual script :o so my film had lost a big chunk off the bottom :(

can anyone see where this is leading yet ;)

finally i am now running again with correct borders selected and have got a Q of 67 :rolleyes:

which leads me to my question - what is the cleanest of the 'dirty' methods that can be implemented to convert PAL to NTSC thus reducing overall Q with an example if possible please ( dont think this would qualifty as an enhancement request for tylo really )

thanks

hj