D2SRoBa 3.80 Released

[manolito]

Another bitchy post. Who dreamed up this cut last image thing?
If I remember it right you would have to shoot r6d2. :scared:

But maybe you want to shoot me too, because I strongly suggest to not remove this feature. The reason for its existence is that D2S provides some slack in its calculations. Without this feature it happend to me all the time that the encode was just slightly oversized (maybe by 0.5%) and D2S would cut off this 0.5%. When checking the size it would always turn out that the file would have easily fit on the CD without cutting. I have the value for cut_per_over set to 0.5%, and it never gave me any trouble. Of course Tylo has a point when he says that since we have the transcoder this thing is no longer needed, but why should we even take the slightest risk to decrease quality when it's not absolutely necessary?

Cheers
manolito

[DDogg]

If I remember it right you would have to shoot r6d2.We tend to shoot at each other on a regular basis, but we make sure not to actually hit each other..LOL.

Look, I don't have a problem if it has to be enabled in the INI by an advanced user that specifically wants this feature and understands its odd and esoteric usage. However, having it enabled when D2SRoBa is freshly installed, especially for DVD, is what concerns me greatly. Btw, my reasons are my great respect for the D2SRoBa effort. Noobs are going to take one look at "Oversized: Cutting last CD image off by 4.4%", not have a clue what is going on, and discard D2SRoBa. That makes me crazy to think about.

Also, I thought 'cut_per_over=0.0' turned this off?

[jsoto]

However, having it enabled when D2SRoBa is freshly installed, especially for DVD, is what concerns me greatly Agree. I've to rerun a encoding because of that, but with D2SRoBa it does not take so time, he, he.

IMO, the best solution is to change the installation default. BTW, I wrote 9.9 in my ini file.

jsoto

[r6d2]

Originally posted by DDogg
Also, I thought 'cut_per_over=0.0' turned this off? Sort of. The problem is, as manolito pointed out, that inaccuracy in D2S BR calculations will have an impact. In DVD mode, which you are mostly interested in, it does not matter because you only need the elementary streams and no cutting is done.

BTW, as Tylo pointed out, the transcoder may eliminate the need for this feature, but eventually you'll end up with bigger images than expected. So be prepared to overburn at times :)

PS: Please don't shoot the pianist. :D

[DDogg]

Ok, I'll set it to 20 like tylo said. That should make sure it is never activated. One of the reasons this feature does not work for many is where frame selection has been used to trim credits as the user specified out point. For it to properly fulfill its purpose it would have to check and deactivate itself when FS has been used.

[bobwillis]

Hi all,

I use the following settings; Cond. sizing pass: Yes (Encode if opv sz < -1.5%, or > 0.0% oversize, or Q > 20). I have never seen this cut problem, so I hypothesize that having the oversize set to 0.0 eliminates the possibility of it occuring. I appreciate that my settings increase the probability of the second pass occuring, but I don't care, because I'm a quality freak and would prefer to have a vbr sizing pass correct matters anyway.

Regards,
Bob

[r6d2]

@Tylo,

When RoBaConditional is used, there is a slight, albeit non-null probability, that when applying KISS you end up needing 2 less media instead of one. Apparently the plugin still just reduces the media count by 1 in this case. Can you check for it, please?

You might easily reproduce the problem by selecting a small media size, like 200 for instance. This is relevant for DDogg's 1/8 - 1/16 idea, very suitable for putting multiple movies on a single DVD minimizing the wasted space.

Thanks in advance.

[DDogg]

I think I remember checking it several versions back and it would decrement multiple 'slices'. I wonder if something changed?

[r6d2]

Originally posted by DDogg
I think I remember checking it several versions back and it would decrement multiple 'slices'.Yes, I remember that. However, I found this happening once, I used 1/16 (282-MB). Please try it to see if you can reproduce it or if something is wrong on my end. Thanks.

[windtrader]

I've seen Bach state that GOP size n/m=5 should be used and it reduces the overall file size by about 10%.

Does D2SROBA take this into account when calculating Q?

[jorel]

Originally posted by windtrader
I've seen Bach state that GOP size n/m=5 should be used and it reduces the overall file size by about 10%.

Does D2SROBA take this into account when calculating Q?

looking D2S folder i have:
dvd.ini ---> MN GOP=4
svcd.ini---> MN GOP=5
vcd.ini ---> MN GOP=5
:)

[r6d2]

Originally posted by windtrader
I've seen Bach state that GOP size n/m=5 should be used and it reduces the overall file size by about 10%.I never saw Bach stating that, but GOP size being 12 or 15 (or whatever) is transparent to D2Sroba since it uses the same GOP for samples and for the encode. Tylo however has reported lower level of precision in the prediction pahse with one GOP size over the other. I cannot confirm that though.

[windtrader]

Tylo however has reported lower level of precision in the prediction pahse with one GOP size over the other. I cannot confirm that though
The latest version of RoBa are predicting VERY well for me. However, I have had runs of good luck then get a bad streak of bad prediction. I sure would not want to mess up the prediction by the change in GOP but it seems, given the same sample pct., larger GOPS might be less accurate due to the larger GOPS "blending" more action (less precision) and has less absolute number of samples for the same size video (less precision).

But who really knows.... Tylo :) Where are u?

r6d2 - check PM

[r6d2]

Originally posted by windtrader
r6d2 - check PM Already done that. Interesting. I'll try to check if GOP size affects output size. In theory, it should, since 3/4 has less B-frames than 3/5.

[tylo]

Yes, Bach has stated that longer GOPs give smaller file size (haven't seen anyone tesing it). It should have most effect on movies with many static scene's though. I have always used GOPs=15 for SVCD for that reason.

GOP length does not significantly affect the Q prediction. But I have experienced that Adjust % could maybe be a little higher when GOPs=12 vs. GOPs=15, which also makes sense in theory. Next version (soon) will have separate settings for DVD and SVCD, so you can set a different Adjust % if you're using diferent GOP length for SVCD and DVD.


/(made bold): D2SRoBa v3.60 is now released. - check first post.

[DDogg]

/add: D2SRoBa v3.60 is now released. Gee, at least put that in bold or something! :) The conditional for DVD and fixed Disk SVCD is a huge new feature.

[FredThompson]

Originally posted by tylo
Yes, Bach has stated that longer GOPs give smaller file size (haven't seen anyone tesing it).
Yup. This is one way MPEG2 satellite is tweaked. Variable length GOPs which can be looooooong save bandwidth.

[jorel]

Originally posted by DDogg
Gee, at least put that in bold or something! :)

oh yes DDogg, but it deserve!

thank you tylo for new version!
:)

[r6d2]

Originally posted by FredThompson
Variable length GOPs which can be looooooong save bandwidth. This is probably why Kwag promotes use of 24 frame length GOPs for KVCD.

[FredThompson]

Originally posted by r6d2
This is probably why Kwag promotes use of 24 frame length GOPs for KVCD.
...and why his samples are from movies without a lot of action.

[jorel]

Originally posted by FredThompson
...and why his samples are from movies without a lot of action.
it's not true my friends, i have lots of kvcds from action movies(rock musicals,lots)and the results are very cool,believe me,the "secret" (well,never was a secret) is the kvcd notch matrix and i sometimes low the gop to 12 and the results are short. see that Nic is using the kvcd notch in QuENC and the default gop is 12 and the compression is great.i'm not posting to "defend" the kvcd way,only showing my results.see that here i post that i like D2S with Roba,QuENC,the new dgmpgdec,Kwag's MA script,Mug Funky/Sh0dan script,HybridFuPP script, and lots more that i use all the time cos i always search and use good programs,scripts and the kvcd nothch is one of the best way to get compression/short size.my opinion is short but my results are great! ;)

[FredThompson]

Those scripts use temporal softening which "smears" one frame into another in an attempt to reduce variations. Large variable-length GOPs can save a lot of bandwidth. Smearing adjacent frames is different.

[jorel]

Fred,
it means that using this scripts turn the image worse? seems a paradox for me. of course, i don't know all parameters, i only see the results and they are good and have quality. i'm using the "kiss" script too...it fall in the same case? please, give your opinion and explanations that are always welcome. :) (if it's not off topic here)
thank you!

[FredThompson]

I suppose this is "on topic" becuase it will help keep the focus of this thread on D2SRoBa compression savings and not filter affects.

VBR MPEG2 is based on periodic full frames (i-frames) and 2 types of interpreted frames which are, basically, recordings of the differences between neighboring frames. GOP is an i-frame and the "differences" for frames until the next i-frame. i-frames use the most storage space.

Thus, a larger GOP can mean a smaller file. It is best if an i-frame is used at each scene change so the "differences" between frames inside the GOP are small. Temporal smoothing reduces the differences between sequential frames. Basically, it replaces each frame with the average of itself and the frames before and after it. Thus, the difference between adjacent frames is reduced. However, this also means detail is removed and new items in the frames are fuzzy at first.

Most MPEG2 uses a fixed GOP length. The earlier comments in this thread were discussing how a larger GOP would mean a smaller file. The optimal solution would be variable-length GOPs with an i-frame at each scene change. This is what some MPEG2 satellite transmissions use. (This is a very simple explanation, not complete.) Since most encoders don't support variable-length GOPs, a length must be chosen. The DVD standard has required GOP lengths. Chosing one of those gives higher compatibility.

That's what they were discussing, GOP length.

[windtrader]

Since most encoders don't support variable-length GOPs, a length must be chosen. The DVD standard has required GOP lengths. Chosing one of those gives higher compatibility.

Are you thinking that an I-frame from a scene change is likely to be smaller than one taken at random, thus the further reduction?

With all the encoders available to us these days, which ones support variable GOP and which software players support this? It would be quite interesting to do some experimentation to see how much of a difference it can have.

Does anyone have any idea of how many DVD STBs can handle variable GOPs if any? It would not be a issue for me since I play the backups 99% on my HTPC.

[FredThompson]

Originally posted by windtrader
Are you thinking that an I-frame from a scene change is likely to be smaller than one taken at random, thus the further reduction?No, scene changes inside the GOP increase b and p sizes.
With all the encoders available to us these days, which ones support variable GOPI don't know of any which are available to hobbyists. Would make a nice addition, though.and which software players support this?Everything I've tried.It would be quite interesting to do some experimentation to see how much of a difference it can have.

Does anyone have any idea of how many DVD STBs can handle variable GOPs if any? It would not be a issue for me since I play the backups 99% on my HTPC.

[windtrader]

I don't know of any which are available to hobbyists. Would make a nice addition, though
Thanks for the quick reply; although it seems this is an academic rather than a practical topic. At least we have the GOP size to optimize.

[QUOTE]No, scene changes inside the GOP increase b and p sizes. /QUOTE]
Does this imply the intra GOP B and P frames are deltas from the prior I frame rather than the prior frame that is composed of the starting I frame merged with the following B frames?

If so, I follow along; otherwise, if the process "builds" the next frame based on the I frame and merging each following B frame, then it seems the additional savings would be marginal.

[bobwillis]

Hi Tylo,

Did an encode with FACAR and the filtering worked as expected. On the next encode, I turned off the filter, but it remains enabled:

--------------------------------------------------------
D2SRoBa v3.60, by Tylo
--------------------------------------------------------
- WIN_XP - AutoIt 3.0.101.0
- 2004-06-12 20:09:42
--------------------------------------------------------
- Output type : DVD
- CD size : 4470
- Threshold Q : 40
- Sample size : 2.0%
- Adjust estimated : 1.4%
- Cond. sizing pass : Yes (Encode if opv sz < -1.5%, or > 0.0% oversize, or Q > 20)
- Cond. filtering : No
- Run mode : Normal
--------------------------------------------------------
- Waiting for CCE window ...
- Detected a CCE encode window
- Detected the movie encode window - shutting down
--------------------------------------------------------
- 2004-06-12 20:26:35
- Project dir: C:\rotk scen\source\
- Avisynth setup: FACAR
- Configured cond. filter: C:\Program Files\DVD2SVCD\Tylo\RoBaConditional.avs
- D2S ver. 1.2.2.5, CCE ver. 2.67.0.27
--------------------------------------------------------
- Movie length : 03:12:46 (289160 frames, 25 fps)
- D2S audio select : 448 + 0 kbps
- D2S video calc. : 2713 kbps, 1 CDs
- Select ranges : every 600, select 12 frames
- Sample frames : 5784
--------------------------------------------------------
Calculations:
- 1 CD: video_br=2713 (2713) audio_br=448+0 video_sz=3922455400 fill=100% cbr=0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Using num CDs : 1
- Target mpv br : 2713 (max 9400) kbps, size=3922455400 bytes
--------------------------------------------------------
Search for Q:
- Sample enc. Q=40 : 2749 kbps, err=1.3%, size=3975838015, sample sz=79527760
- Sample enc. Q=41 : Skipped. Restarting search with cond. filter
- Sample enc. Q=40 : 2478 kbps, err=-8.7%, size=3583627071, sample sz=71682456
- Sample enc. Q=34 : 2758 kbps, err=1.7%, size=3988240900, sample sz=79775852
- Sample enc. Q=35 : 2705 kbps, err=-0.3%, size=3912216816, sample sz=78255160
--------------------------------------------------------
- Determined Q : 34 = Round(35 + (-0.3 - 1.4)/2)
--------------------------------------------------------
- 2004-06-12 20:45:32
- Start movie OPV encoding (Q 34)

Regards,
Bob

[FredThompson]

Originally posted by windtrader

No, scene changes inside the GOP increase b and p sizes.
Does this imply the intra GOP B and P frames are deltas from the prior I frame rather than the prior frame that is composed of the starting I frame merged with the following B frames?

If so, I follow along; otherwise, if the process "builds" the next frame based on the I frame and merging each following B frame, then it seems the additional savings would be marginal. If the GOP size can be variable, the logical place for an i-frame is where frame n varies significantly from frame n+1. That would help to enforce the goal of only small changes within the GOP itself. When a scene change happens inside a GOP, the GOP must have more bytes to maintain the quality level. If the goal is some level of constant quality in minimal space, you'd have the best results with an i-frame at each scene change and variable-length GOPs.

It sure would be nice if this kind of thing was available without paying pro prices. I wonder if scene detect could be added to QuEnc so it could do variable-size GOPs.

[tylo]

Did an encode with FACAR and the filtering worked as expected. On the next encode, I turned off the filter, but it remains enabled:
This I fixed right before the release. (Sorry, I was sloppy with versioning of the test releases). Download again. You should verify that you have an older version by comparing dates, e.g. D2SRoBa.au3 inside the D2SRoBa_src.rar archive.

[bobwillis]

Thanks Tylo.

When I uninstalled my existing version and installed the latest version, the FACAR script was not modified by D2SRoBa.

I had to uninstall D2SRoBa, then uninstall FACAR, reinstall FACAR and then reinstall D2SRoBa in order to get "!RoBaConditional.avs=C:\Program Files\DVD2SVCD\Tylo\RoBaConditional.avs" to re-appear in the facar script.

I notice that when you uninstall D2SRoBa it leaves "0=# Import(...)" behind. I know this does nothing, but I'd thought I'd make you aware of it. Could you not just delete the whole line?

Anyway, it all appears to be working ok now - many thanks.

Regards,
Bob

[manolito]

It has been quiet around here for some time, which of course means that D2SRoBa has reached a very stable and mature state. I use it all the time, and I don't know how I could ever have lived without it.

But I do have some tiny requests for the next version. After testing version 3.60 for some time I did go back to 3.50, mainly because I miss some of the features that have been removed. Would it be much work to reintroduce the "Sample_estimation_fix" entry in the INI file? It`s almost funny because it was me who originally discovered jonny's trick in his thread and brought it up here. In the majority of cases this trick does give you a more accurate Q estimation, but to me it happened twice that I got an OPV encode that was way undersized (15% to 18%). Turning this option off gave me an encode well within my normal range (between 3% under and 5% oversized). So I went back to the old way, and it would be real nice to have this option back.

The other thing I miss is the "Clean previous sample files" option in the GUI. I don't use it often, but sometimes I find it quite useful.

Cheers
manolito

[manolito]

Here comes another one of my "brilliant" ideas that might smell like a lot of work for Tylo. Don't worry, so far this is just a theoretical thing, and maybe my logic is all wrong, but I'd really like to have it discussed here.

It's about how Q factor and aspect ratio of the movie are related. With D2SRoBa we do not care about bitrate, we do quality based encodes here, and the CCE Q factor is a direct measurement of the encoding quality. If we consider filtering and quantization matrices as constants, then two encodes with the same Q will have the same quality. (This is probably oversimplified, but it basically comes from some very old posts from Bach himself.)

In D2SRoBa we have to decide on the highest Q (worst quality) we are willing to accept, then we enter this value into the "Auto Q" or "Threshold Q" box. If we end up with a Q above this value, D2SRoba will apply a remedy like using a conditional filter or increasing the number of CDs to ensure that our quality will be equal or better than the Q we specified.

But if we do a non-anamorphic (letterboxed) encode, the black areas of a 16:9 movie will be a part of the encode and thus also be considered in CCE's Q calculation. (For SVCD most of us have to use the "16:9, borders added, encoded as 4:3" option, because most standalone DVD players do not support the anamorphic flag for SVCDs.)

Example: For a cinemascope 2.35:1 movie almost half of the 4:3 TV screen consists of black pixels. (To keep it simple, I just say half of the pixels are black). Even at ultra low bitrates it is probably safe to assume that CCE will encode these black pixels at a Q of one (or zero). If the real user data (the actual film) came out with a Q of 50, then the overall Q would be something like 25. (I think the Q function curve is pretty linear as long as we do not get close to the maximum bitrate.)

If this is true, then a 2.35:1 encode with a Q of 25 would have the same quality as a 4:3 encode with a Q of 50.

For D2SRoBa this means that for letterboxed encodes a correction factor for "Threshold Q" would have to be implemented according to the movie aspect ratio. Probably not a trivial thing. Somehow D2SRoBa would have to determine the ratio between black pixels and movie pixels. For FACAR users the values could be extracted from the FACAR script, but for the standard resizer scripts...?


Well, this is my theory, let's see if someone can prove me wrong. BTW this theory translates well into the real world. Lately I have been doing a lot of 4:3 encodes, and even at a Q around 60 they look quite OK while 2.35:1 movies with a Q higher than 35 show visible artefacts.


Cheers
manolito

[windtrader]

I always thought the calculation of Q would account for the various sized black bars. It does sampling which would (could) "see" the amount of constant black areas in the samples and adjust Q accordingly.

However, based on your observation that 1:33 encodes can have higher Q than higher aspect ratio before quality falls off, it makes me wonder as well what is being calculated.

[r6d2]

@manolito,

Interesting idea. However, I'm with windtrader here. I think Q takes that effect into account as much as D2Sroba is concerned.

But please do a simple test. Use OPV Q=30 or whatever number you like best. First do a 4:3 5 minute clip and encode it uncropped. Then encode it again as if it were a 2.35:1 movie. I mean, crop top and bottom parts with FACAR.

This way you'll encode "the same" material, at the "same overall Q". See if you can find a difference between the two side by side (taking into account only common film pixel area).

I think you'll find that both encodes have different sizes (and hence different BRs), but same Q, and will look exactly the same. Please see if you can check that.

[jorel]

hy boys! :)
first,don't need to write(but i'm writing) that D2SRoba is wonderful!
sometimes the system crash if (and only if) i'm on internet and encoding at the same time,if i live the pc alone only encoding,it run fine. i'm using with CCE2.50 adjusting "idle" in process priority on D2S and if i'm right,it means that all programs will run in idle,include CCE! trying to find a way to encode and still use the pc,i read the cce faqs,D2SRoba faqs and D2S faqs. i saw that in Q60 of D2S faqs have recomendations to use "Safe mode (frameserving)" option in "Encoder" tab,but Roba don't work with this option. in Q9 of CCE faqs,i saw an option to run CCE in lower process priority:
@echo off
start "CCE" /LOW <path to CCE executable>
but i don't know if D2s running in idle priority is running CCE in this condition,turning this recomendations useless. using CCE266 with eclcce the same happen as CCE250 : the system sometimes crash if i not let it encoding alone. well,after this big details and doubts,i ask: what can i do to run D2SRoba with CCE in very very low priority to still use the pc for other little jobs without crash? ...time to encode is not important,i'm only don't want to stay out waiting the end of the job without use the pc at the same time.i have athlon xp 2000+ with 512mb ram and 2 hds with 7200rpm that seems fine to run without crash in idle mod using others programs together with D2SRoba/CCE. can anyone give me more hints and help me please?
thanks in advance! :)

[tylo]

@manolito: It really depends on how CCE determines the Q. If it simply looks how close the source is encoded to the target for each pixel, and then takes the average for all pixels, you are right. It could also "weight" the problematic parts of the scene much higher. For example if 90% of the scene is simple to encode, but 10% is extremely hard, the Q could reflect how close the encoding is to the source in hardest part of the frame. I believe CCE does something like that.

If your theory where right, you should get a *much* worse Q if you droppet the AddBorder() line in a 2:35 movie, and created a smaller frame size with no black borders in. Try it and report, if you like.

@jorel: does this problem only occur when you use D2SRoBa, and not with D2S alone? D2SRoBa uses a small proggy in the ./dist folder to set the CCE process priority equal to D2S.

[jorel]

hy tylo,thanks for answer (ask) me!
the true is....i don't know :p cos i don't use D2S without Roba but i don't think that Roba is giving me that problems, i post the doubt here cos i can't use "Safe mode (frameserving)" with Roba and if have one more way to really "slow down" the process....like i told, time needed to encode is irrelevant(i really don't mind),i only want a system just a little more "stable", CCE use cpu in "heacy way",right?
D2SRoba give me perfect size and if don't have any way to decrease the cpu use, better is left the system alone encoding with Roba.
believe me,i don't want to test without Roba cos it's not guilty and i still want perfect size in my target and using CCE in D2S without Roba is very hard to find the target size!
nobody knows D2SRoba more than you and nobody knows D2SRoba less than me.......but we all know that Roba is working perfect,then i'm calling for another possible alternative to decrease the cpu charge!
thank you ! :)

[bobwillis]

Hi Tylo,

Do you have to check the 'conditional sizing pass' box in order to get the 'transcode if oversized' feature to work.

I have just done an encode with 'conditional sizing pass' unchecked and 'transcode if oversized' checked (albeit greyed out) and the transcoder wasn't executed. Is this as you expect?


--------------------------------------------------------
D2SRoBa v3.60, by Tylo
--------------------------------------------------------
- WIN_XP - AutoIt 3.0.101.0
- 2004-07-24 13:12:08
--------------------------------------------------------
- Output type : DVD
- CD size : 4470
- Threshold Q : 40
- Sample size : 2.0%
- Adjust estimated : 1.4%
- Cond. sizing pass : No
- Cond. filtering : No
- Run mode : Normal
--------------------------------------------------------
- Waiting for CCE window ...
- Detected a CCE encode window
- Detected the movie encode window - shutting down
--------------------------------------------------------
- 2004-07-24 13:36:55
- Project dir: C:\goldeneye\source\
- Avisynth setup: LanczosResize
- Configured cond. filter: C:\Program Files\DVD2SVCD\Tylo\RoBaConditional.avs
- D2S ver. 1.2.2.6, CCE ver. 2.67.0.27
--------------------------------------------------------
- Movie length : 02:04:12 (186306 frames, 25 fps)
- D2S audio select : 448 + 0 kbps
- D2S video calc. : 4460 kbps, 1 CDs
- Select ranges : every 600, select 12 frames
- Sample frames : 3732
--------------------------------------------------------
Calculations:
- 1 CD: video_br=4460 (4460) audio_br=448+0 video_sz=4154623800 fill=100% cbr=0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Using num CDs : 1
- Target mpv br : 4460 (max 9400) kbps, size=4154623800 bytes
--------------------------------------------------------
Search for Q:
- Sample enc. Q=17 : 4315 kbps, err=-3.3%, size=4019726674, sample sz=80521400
- Sample enc. Q=16 : 4449 kbps, err=-0.2%, size=4144639755, sample sz=83023604
--------------------------------------------------------
- Determined Q : 15 = Round(16 + (-0.2 - 1.4)/3)
--------------------------------------------------------
- 2004-07-24 13:39:39
- Start movie OPV encoding (Q 15)
- OPV pass result: 106.4% on target, 4747 kbps (4421994756 / 4154623800) Speed: 2.77
--------------------------------------------------------
- 2004-07-24 14:24:35
- Recover DVD2SVCD: Muxing

Best Regards,
Bobs

[manolito]

Do you have to check the 'conditional sizing pass' box in order to get the 'transcode if oversized' feature to work.
Yes you do. The transcoding pass is nothing but a sizing pass, it just uses a transcoder instead of CCE in VBR mode. So if you do not check the "conditional sizing pass", no resizing will take place at all.

Cheers
manolito

[bobwillis]

Cheers manolito. Just wanted confirmation that's how it's supposed to work!

Regards,
Bob

[xp_eric]

I started using D2SRoBa in combination with DVD2SVCD and mDdvdAuth to create DVDs. The problem is that mDdvdAuth uses the SVCD mode of DVD2SVCD and thus D2SRoBa is thinking a SVCD is created. Can I force D2SRoba to DVD mode despite the SVCD setting of DVD2SVCD and if not which settings should I use?

DVD2SVCD settings are :
output file type : SVCD
resize to : DVD (720 x 480/576)
CCE GOP sequence : M=3 N/M=4

Eric :)

[Boulder]

Is there a way to make D2SRoBa encode 15-frame GOPs (N/M=5) instead of the twelve frames it uses by default? I've edited the appropriate .ini files so that the PVA2DVD portion uses 15-frame GOPs but D2SRoBa doesn't seem to respect them.

[r6d2]

Originally posted by Boulder
I've edited the appropriate .ini files so that the PVA2DVD portion uses 15-frame GOPs but D2SRoBa doesn't seem to respect them.Did you try changing the settings inside DVD2SVCD or using a template? (you did not post your log so I'm assuming you're using CCE)

[Boulder]

Originally posted by r6d2
Did you try changing the settings inside DVD2SVCD or using a template? (you did not post your log so I'm assuming you're using CCE)

It seems that changing the settings inside DVD2SVCD doesn't work because it won't go for M=3, N/M=5, thus it uses 12-frame GOPs. I've got it working when I've saved the settings in an ini file, then edited this file so that the N/M value is 5 and loaded the ini file, then starting the process without editing any CCE related parameters.
However, D2SRoBa appears to use 12-frame GOPs no matter what I do.

[ralphthedog]

Hmmm......I thought the GOP parameters did change with the settings on DVD2SVCD, did you look in the .ecl file @Boulder?

In the past I always thought my CCE templates were in control, but I seem to remember the DVD2SVCD settings were actually used?

[Boulder]

The problem is that DVD2SVCD won't let me put 5 in the N/M box, the highest value possible is 4. If I edit the ini file so that the value is 5, I get 15-frame GOPs.

It's not a big problem, I've set D2SRoBa for my dad's TV captures so that he gets full-size DVDs without any need to be a tech person. He puts max 3 hours per disc so the extra compression shouldn't be necessary 95% of the time.

[Venom_IL]

the output file shows the following avisynth error

"deen need a yv12 input"

D2SRoBa_Q36.mpv.unfiltered.mpv doesn't show this which makes sense and means the problem occurs only when the filter is run

is there a way to simply not use the filter? (or is it completely nesseccary in this case)

maybe an avisynth command i could add somewhere to convert to yv12 or something of the sort?

would updating avisynth or deen to their newest versions (betas) do any good?

here is the log

--------------------------------------------------------
D2SRoBa v3.60, by Tylo
--------------------------------------------------------
- WIN_XP - AutoIt 3.0.101.0
- 2004-08-14 20:01:37
--------------------------------------------------------
- Output type : SVCD
- CD size : 800
- Number of CD's : auto (max 32)
- Threshold Q : 36
- Sample size : 1.0%
- Adjust estimated : 1.2%
- Cond. sizing pass : Yes (Transcode if opv sz > 0.0% oversize, and Q <= 40)
(Encode if opv sz < 2.5% undersize, or Q > 40)
- Cond. filtering : If configured, and estim. oversize for Num CDs-1 is below 25%
- Audio after video : Yes (9% of video, min 160 kbps)
- Adjust max br : Yes (total: 2754, max avg offset: 300 kbps)
- Run mode : Normal
--------------------------------------------------------
- Waiting for CCE window ...
- Detected a CCE encode window
- Detected the movie encode window - shutting down
--------------------------------------------------------
- 2004-08-14 20:04:47
- Project dir: F:\DVD2SVCD\3\
- Avisynth setup: BilinearResize
- Configured cond. filter: C:\Programs\DVD2SVCD\Tylo\RoBaConditional.avs
- D2S ver. 1.2.2.1, CCE ver. 2.67.0.23
--------------------------------------------------------
- Movie length : 01:19:48 (119705 frames, 25 fps)
- D2S audio select : 160 + 0 kbps
- D2S video calc. : 1196 kbps, 1 CDs
- Select ranges : every 1500, select 15 frames
- Sample frames : 1200
--------------------------------------------------------
Calculations:
- 1 CD: video_br=1196 (1196) audio_br=160+0 video_sz=715835900 fill=100% cbr=0
- 2 CD: video_br=2504 (2504) audio_br=224+0 video_sz=1498706600 fill=100% cbr=1
--------------------------------------------------------
Computing target number of CDs:
- Sample max br : 2594 (adjusted for 1 CDs)
- Sample enc. Q=36 : 1200 kbps, err=?%, size=718236783, sample sz=7200068
- Estim. oversize : 0.3% for 1 CDs
Conditional filter test:
- Sample enc. Q=36 : 233 kbps, err=?%, size=139812248, sample sz=1401568
- Cond. filter success - reducing num CDs to 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Using num CDs : 1
- Target mpv br : 1196 (max 2594) kbps, size=715835900 bytes
--------------------------------------------------------
Search for Q:
- Sample enc. Q=6 : 233 kbps, err=-80.5%, size=139848957, sample sz=1401936
- Switch to binary search
- Sample enc. Q=3 : 233 kbps, err=-80.5%, size=139853347, sample sz=1401980
- Sample enc. Q=2 : 233 kbps, err=-80.5%, size=139882874, sample sz=1402276
- Sample enc. Q=1 : 233 kbps, err=-80.5%, size=139854544, sample sz=1401992
- Sample enc. Q=0 : 233 kbps, err=-80.5%, size=139854544, sample sz=1401992
--------------------------------------------------------
- Determined Q : 1 = Round(0 + (-80.5 - 1.2)/-1.#IND)
--------------------------------------------------------
- 2004-08-14 20:06:57
- Start movie OPV encoding (Q 1)
- OPV pass result: 0.3% on target, 3 kbps (1928492 / 715835900) Speed: 1408.63
--------------------------------------------------------
- 2004-08-14 20:07:03
- Start VBR sizing pass (1196 kbps)
- Sizing pass result: 0.2% on target, 2 kbps (1690628 / 715835900) Speed: 1371.04
--------------------------------------------------------
- 2004-08-14 20:07:09
- Executing: C:\programs\DVD2SVCD\BeSweet\BeSweet.exe -core( -input "F:\DVD2SVCD\3\Encoded_audio_1.mp2.wav" -output "F:\DVD2SVCD\3\Encoded_audio_1.mp2" -logfile "F:\DVD2SVCD\3\Encoded_audio_1.log" ) -ota( -g max ) -shibatch( --rate 48000 ) -2lame( -e -b 160 -m j )
--------------------------------------------------------
- 2004-08-14 20:07:19
- Recover DVD2SVCD: Muxing
--------------------------------------------------------
- 2004-08-14 20:08:13
- D2SRoBa successfully finished
--------------------------------------------------------

thanks in advace, i really feel this can be resolved in a simple command like converttoTv12() or something, im just really ignorant in this business :confused:

[tylo]

@Boulder: D2S forces GOP N/M=4 on DVD output, because Scenarist requires it. However, DVDAuthor and possibly others do not (so it's kind of a bug). FYI, the latest internal beta test version allow you to set GOP N/M=5, so the next release will too.

@Venom_IL, do one of the following:
A. Uncheck "Use cond. filter if configured", and select Num CDs=1.
B. Or, edit C:\Programs\DVD2SVCD\Tylo\RoBaConditional.avs. You may try an alternative conditional filter that does not require yv12 input. If Fluxsmooth is such a filter, you may try that.

Cheers.

[manolito]

@VENOM_IL

This is just one of the catches you may encounter when converting AVIs. Most filters for AviSynth 2.5x require YV12 source material. For a DVD source this is already the case, but if your source is a captured AVI file it will mostly be YUY2.

But there is no need to get rid of your filters. Just edit your RoBaConditional.avs and insert the following line before the first filter call:

ConvertToYV12()

If your source is interlaced, the command should be

ConvertToYV12(interlaced=true)

Before turning over the clip to CCE it has to be converted back to YUY2. AVI2SVCD does this automatically (Encoder tab, Advanced, Color conversion), but the AviSynth documentation recommends to use the command "ConvertBackToYUY2()" if the clip was YUY2 before. So IMHO it can't hurt to insert the line

ConvertBackToYUY2()

after the last filter command in your RoBaConditional.avs.

If you do not have DivX installed you might get a complaint that a YV12 capable codec must be installed. If you do not want to install DivX, the "LocoCodec" works just fine.


Another catch if you want to deinterlace your clip in AVI2SVCD: If you want to use the built-in SmartDeinterlacer you cannot use Mpeg2dec3.dll in the Frameserver tab. Use Mpeg2dec.dll instead.

Good luck
manolito