Bitrates: Calcumatic and Video Streams

J-Wo · #1 11-27-2003, 02:59 AM

I want to fit 13 1hr episodes of a TV show into a 4.7gb dvdr. They are vcd quality, so I think I can squeeze them in. If I were to do prediction for each file, I tried to use CalcuMatic with 13 video streams onto 1 4.7gb dvd, but calcumatic only supports a max of 10 video streams. Kwag, do you think this could be fixed?

A workaround I'm trying right now is to take 4.7 GB and convert it to MB (4.7 x 1024 = 4812.8mb), then divide that by 13 (4812.8 / 13 = 370 mb). This gives me how many MB each episode should be. I then stick this into calcumatic as the custom size. Does this sound like an appropriate alternative?

Dialhot · #2 11-27-2003, 04:15 AM

How do you put several streams in Calcumatic ? I didn't know you can.

EDIT: Okay ! I just see it ! But that settings does nothing, it just divide the total size by the number of streams, exactly as you do yourself manually. As I told you just below, that is not accurate at all ! You must do an avs script that loads ALL the 13 sources and do a prediction on that. That's the best thing to do.
(but 13h seems to be a very long time and CQMatic will probably fails to find an accurate CQ).

incredible · #3 11-27-2003, 04:18 AM

Quote:

Originally Posted by J-Wo

A workaround I'm trying right now is to take 4.7 GB and convert it to MB (4.7 x 1024 = 4812.8mb), then divide that by 13 (4812.8 / 13 = 370 mb). This gives me how many MB each episode should be. I then stick this into calcumatic as the custom size. Does this sound like an appropriate alternative?

WATCH OUT!

DVD-5 = 4.3 GB!!

So use your formula on 4,3x1024/13 !!

But (as I remember) watch out for varmesquita's tools on his website ... I think he implementated a calculator where you can set the numbers of videostreams to fit on one DVD-5.

And Clacumatic..... ähm .... As I also remember you can set the number of videos?! So use the DVD preset as dest.Media and also your audio bitrate for each videostream to encode ... this will give you the AVG Bitrate to encode each videostream.

But in case of DVD-R I always use a manual calculation cause in a case of that you have movies with diff. lenghts it makes more sense to apply to each videostream its perfect AVG Bitrate

Dialhot · #4 11-27-2003, 04:25 AM

Quote:

Originally Posted by J-Wo

A workaround I'm trying right now is to take 4.7 GB and convert it to MB (4.7 x 1024 = 4812.8mb), then divide that by 13 (4812.8 / 13 = 370 mb). This gives me how many MB each episode should be. I then stick this into calcumatic as the custom size. Does this sound like an appropriate alternative?

That's what I do also very often but is not very accurate as it leads to have a movie encoded at, let say, 70 and an other one at 80 where both would have been encoded at 75 if the prediction was done on the whole data.

incredible · #5 11-27-2003, 06:11 AM

Quote:

But in case of DVD-R I always use a manual calculation cause in a case of that you have movies with diff. lenghts it makes more sense to apply to each videostream its perfect AVG Bitrate

Thats also what I wanted to say refering to diff CQs ...

If you want to be utltra-exact to give every stream the same quality...
just let CQmatic do on all streams its first turn at a default cq like 65 ... after the first turn stop CQmatic and compare the size output of the 3000 frames ... you'll see the difference which comes out and by this you can assume how to set each stream individual by finetuning the AVG Bitrates to get perfect same-quality based outputsizes which as a whole do match the needed 4.3GB incl. overheat.

incredible · #6 11-27-2003, 06:28 AM

Another sexy trick to get a linear same quality according to all different streams which have to match as a whole the 4.3 GB.

Code:

a = avisource(........ part 1) or Mpeg2source(..... part1
b = avisource(........ part 2)
c = avisource(........ part 3)
d = avisource(........ part 4) .... and so on

addblack(300)

function addblack (clip c, int "lof") { 
lof= default(lof, 50) 
wi=width(c) 
hi=height(c) 
fr=framerate(c) 
ty= (IsRGB24(c)==true) ? "RGB24" : (IsRGB32(c)==true) ? "RGB32" : (IsYUY2(c)==true) ? "YUY2" : "YV12" 
ch= (AudioChannels(c)==2) ? true : false 
ar = Audiorate(c)  
z=BlankClip( Pixel_Type=ty,audio_rate=ar, stereo=ch, length=lof, width=wi, height=hi, fps=fr, color=$000000) 
Return a+z+b+z+c+z+d ..... and so on 
}

You have to change the parameters in the function to their specific stream parts so as you see it here its not set right!

This function bases on a "addblack()" avsi I created to add black frames adaptive to the source on captures ...
http://www.kvcd.net/forum/viewtopic.php?t=7645

So the logic would be .... that this implementated function adds for example 300 black frames between every stream when encoding as a WHOLE! So after encoding you could "cut" a ready muxed 4.3GB whole stream (after whole prediction and encoding) at its needed points to receive separated streams again which you can author as tracks using an DVD authoring Appl! And they will match!

As I said, the function above in its parameters is still not correct, it's just a thought based on my addblack() script .... but the logic should work in this case to get a most effective output ?!

You understand what I mean Dialhot? I think we should focus this .... and rewrite the function based on multiple import streams in the avs script.
Im here in the office and so I can't do my try and errors to approach to correct script settings

But I think maybe you don't need these 300 Frames between the streams as TmpgEnc's cutting engine supports frame by frame approach to the needed cut points, so the script above could have its logic but without the BlankClip() command!

And if it still doesn't match the whole DVD-5 Media size (maybe overflow of bad prediction)... this logic lets you also nice reduce the size by using the M2VRequantizer on the WHOLE stream so even by this ... the quality will be linear through all streams and no seperate "transformation" is needed = Nice!

So you predict all the movies as a whole. Muxing them and do the "cut" afterwards in TmpgEnc .... BUT!: How does TmpgEnc behave when cutting muxed AC3s??? Well we should try and if it doesn't support AC3 cutting well, we have to look out for another method to exact-frame split the whole-stream afterwards incl. AC3 supporting.

Or you do perform the BlankClip() command by adding one "lightning green" frame to directly see the cut point ... so if you split the m2v afterwards without included AC3s ... after this the sync and size of the AC3 should match when doing the following muxing job in a DVD authoring appl... hmmmm

Tonight I'll have to pack my stuff for a Weekend trip to Prague which starts tomorrow at 4.45 h in the morning

, so I'll not have the time tonight to check this out

But maybe you could do DialHot ....

J-Wo · #7 11-27-2003, 10:11 AM

woaaaah this topic has become very informative! My only question is I don't think I can put all 13 files in one avs script because some of them have different resolutions, thus you can't join them with a simple '+'. Am I right?

Dialhot · #8 11-27-2003, 10:26 AM

Quote:

Originally Posted by incredible

So the logic would be .... that this implementated function adds for example 300 black frames between every stream when encoding as a WHOLE! So after encoding you could "cut" a ready muxed 4.3GB whole stream (after whole prediction and encoding) at its needed points to receive separated streams again

If the idea is just that, you really do not need to add black stream like this. All you need is to make a scritp that load all the source for making PREDICTION ONLY. Then you encode manually and separately all the movies one by one using the CQ found in the first step.

You can even use the batch functionality of TMPGEnc for that !

Quote:

Originally Posted by J-Wo

My only question is I don't think I can put all 13 files in one avs script because some of them have different resolutions, thus you can't join them with a simple '+'. Am I right?

You are

incredible · #9 11-27-2003, 12:33 PM

Quote:

Originally Posted by Dialhot

Quote:

Originally Posted by incredible

So the logic would be .... that this implementated function adds for example 300 black frames between every stream when encoding as a WHOLE! So after encoding you could "cut" a ready muxed 4.3GB whole stream (after whole prediction and encoding) at its needed points to receive separated streams again

If the idea is just that, you really do not need to add black stream like this. All you need is to make a scritp that load all the source for making PREDICTION ONLY.

Thats what I also meant here...

Quote:

Originally Posted by Incredible

But I think maybe you don't need these 300 Frames between the streams as TmpgEnc's cutting engine supports frame by frame approach to the needed cut points, so the script above could have its logic but without the BlankClip() command!

It was just a thought the adding of ONE "green" frame with the addblack() function( or something else) to the end of each stream so you could better find the nedded "kick-ins" for cutting afterwards.

Quote:

Originally Posted by Dialhot

Then you encode manually and separately all the movies one by one using the CQ found in the first step.

I think this won't work cause you do the prediction on the WHOLE and therefore you have to encode the whole. You can't set to the separate encodings the same output CQ as you got by predicting the Whole combination of all movies ... cause its the average CQ of all streams together. Thats why my thought was, also to encode as a whole and afterwards to cut ... "iF" cutting of a muxed video/ac3!! is well supported by TmpgEncs cutting function. "If not": ... we should apply that mentioned "one green frame" between each stream to see the "sync/kick ins" to separate the whole stream to the speparated ones and therefore the audio will be inSnyc afterwards when adding to each of the separated streams the AC3 in a DVD Authoring Appl.

Dialhot · #10 11-27-2003, 02:05 PM

[quote="incredible"]

Quote:

Originally Posted by Dialhot

I think this won't work cause you do the prediction on the WHOLE and therefore you have to encode the whole. You can't set to the separate encodings the same output CQ as you got by predicting the Whole combination of all movies ...

Don't blame me but you think wrong.
I would have said that I did this for two BABYLON5 seasons (42 videos), 3 episodes by CD, each predicted by this "3 by 3" method and encoded individualy with the CQ found each time. It works perfectly.

And that's normal. The idea is the same to say : I have a movie that I predicted with CQMatic and it found CQ=70. I launch the encoding but after one third there is a power shutdown. I restart the process but I jump directly to the first frame not encoded (with tmpgenc range selection or by adding a trim command in avs script). One hour after, an other power shutdown ! I then do the last part the same way.

What do you think it will happen when I will merge the three mpegs generated ? They will do exactly 800 Mb.

incredible · #11 11-27-2003, 03:23 PM

Shure you're right *bong*

Cause as I said (and not well thought until the end by myself) this gives you the average (up to this this I was right) and therefore if one of the streams will come out to large the other one would come out to small ... and both together will .... :

(which also matches to your explanation)

So I won't blame you because there's a speech in German: "Cause of too many trees I wasn't able to see the forest". And I think this exactly matches to this here