The web is full of VB API call examples ;)
(I wish I would have the same "ready-made-source-el-dorado" like you have as VB user/coder ;) )

Look for accessing the dgdecode.dll in the forum.doom9.org. Doom9 had the same question related to c++ access BUT AFAIK Neuron even integrated Standard-calls for VB accessing into his dll.

I am taking a look at dgdecode sources, but what file I need to see in detail?

Here you go :)
The "very sloppy!!!" code below is in the file "vfapidec.cpp"

-kwag

Thanks but I don't understand nothing. Forget it.

Now comming back to Calcumatic.
Could you add a mod to calculate proportional space related to complexity.
I was talking with Boulder a time ago and he did give me a spreadsheet that calculates space not only related to playing time, but also complexity evaluated for bitrate in a sample.
Im working on a calculator, but think that it would be easier for you, as you have a tool developped.

I want to show you some pics of my tool, then maybe you can have an idea of what I am talking about.

First, a pic of my VB6 form:

http://www.digitalfaq.com/archives/i.../2005/06/8.png

Now only time based mod:

http://www.digitalfaq.com/archives/error.gif

And frame based mode (time is inherent, of course), but you need to do previous samples and know how many frames they have and how many Kbps also.

http://www.digitalfaq.com/archives/i.../2005/06/9.png

Also it has, as you can see, a section to calculate avg bitrate when you want to put several series chapters (almost same playing time) in one DVD.

Could you do something like this in a way easier than me (for me is really hard).
Thanks.

What exactly do you mean by that :?:
I mean, if you calculate a file size for X average bitrate, you will always get Y file size.
I don't understand what you mean by proportional complexity, because anyway you look at it, if you calculate complexity for a piece (segment) of a movie, what are you going to do with the rest of the movie :?: :roll:

-kwag

Hi Karl :),
Actually I was going to do something similar to what Pro is refering to.
Take it that you have 2 movies.
They have different sizes and different average bitrare - the sources, I mean.
You could go and encode them as if they were the same size and the same bitrate, that is, splitting the available media size by 2.
But then you end up with 2 movies with different quality!
What Pro is suggesting is that we balance the figures so that both movies end up with the same visual quality, thus occupying different space on the target media.
That's what Boulder's spreadsheet is all about ;-).
I was going to work on that on my own spreadsheet for HC encoder, but since I can't get HC to do some decent prediction I abandoned the whole thing...
You just encode 5% of the 2 movies on the same CQ.
The difference in filesize of both samples and the movie duration will tell you how how much share both movies will take up on the target media.
Cheers

Why not just take the total amount of minutes of the two movies and plot that into calcumatic. That gives an average bitrate that will work for both movies, that's what I do and it haven't failed me yet...

-Anerboda

A version of DGdecode using stdcall wrappers for VB usage:
http://neuron2.net/dgmpgdec/DGDecode131b1.zip

Functions of the dll:

openMPEG2Source_SC
getFrame_SC
getRGBFrame_SC
closeVideo_SC

But These _getXXXX Functions do give pointers to Bitmaps in memory!
So no Info about the video architecture.

So do search for a dll-parsing utility in VB which shows you the accessable functions within a dll. Then do a search on the Web on that dll to see what parameters are needed as such dll-function-parsers only do show the functionnames but not all needed parameters.

Or you do access the AvisynthC.dll by using the Invoke command to send parameters for accessing Invoke/mpeg2sorce.


But the worse side on that is: 99.9% of the users wont have that dgdecode including the stdcall wrapper installed, means, you have to provide it within your package, means, :arrow: GPL :!:

So accessing the AvisynthC.dll will be independent from providing GPLlled Stuff in your Package.

Wrong, further on I explain why.
It just hasn't failed you so far maybe because your sources have similar bitrates and types (high action/low action).
Since a high action movie ends up needing more bitrate than a low action movie, it is obvious that just splitting the target media size by 2 taking it proportionally to the movies durations is not enough.
In your calculations you need to take into account the source bitrate otherwise it will fail you.
Of course, if you just encode the first few frames (until you reach 5%) of both movies, you will probably get wrong figures.
That's where Andrej's Slicer function comes in.
It takes x% of your movie getting the frames from many different sectors of the movie.
I know Karl can do that easily.
Cheers

@red: Thanks, I couldn't explain it so clearly.

@Inc: Thanks, now I see it easier to do.

Here is the speadsheet:

http://www.saunalahti.fi/sam08/kbps_eng.xls

http://www.kvcd.net/forum/viewtopic.php?p=117425#117425

[quote="incredible"]OT
Can somebody tell me if I should release my tool with LGPL and what it means, maybe Kwag, in spanish by PM, or any other people in english.
END OT

Im not shure if a direct accessing of a compiled .dll makes you automatically forced to release rights to the outside, means releasing the sources. But I guess so, AFAIK not only the calculating engine of FitCD_to_Moviestacker was an issue but als the accessing of the warpsharp.dll for avisynth previewing.

And that's exactly what I was going to say, because that's exactly what I do :!:
Add up the total play time of all movies, feed it to CalcuMatic, and bingo!, use the average bitrate given. :roll:

-kwag

Hi Rui,

Err, am I missing something here :roll:
The fact is, that for an X length footage on a Y target media will always yield a specified average bitrate.
The longer the playtime, the lower the average bitrate for the same target. And vice versa.
This has nothing to do with the sources :roll:
Say you have 2, 3, 10 movie :!:
The total average bitrate is what must be calculated for a particular target.
If one of those movies is a high action film, and you want to increase the bitrate, one of the other movies will have to give it's bitrate, in order to accomodate the total calculated average bitrate. If not, the size of the whole will exceed the target's size.

-kwag

That only take in account times but not complexity.

An that is the point.
Analizing a sliced sample, and compare it in 2 films, applying spreadsheet maths and you will have different avg bitrate for each movie, with same visual quality result.

@Karl
Let's try to put it simple and easy, even for me to try to explain.
I want to put 2 different movies on a DVD-5.
Movie A has 125 minutes while movie B has 97 minutes.
Movie A is a very high action movie and movie B is a low action movie.
Let's forget about if the movies are bright or dark, ok?
Both movies have are anamorphic PAL 720x576 with 1 AC3 5.1 track and both AC3 tracks are 384Kbit.
Now, I want both movies to look exactly as good as the other.
And I mean quality ;-).
Movie A is nearly 29% bigger than movie B.
Let's say that a DVD-5 capacity is 4,375GB == 4480MB == 4.587.520KB.
Movie A audio:
((125*60)*(384000/8 ))/1024 = 351.563KB
Movie B audio:
((97*60)*(384000/8 ))/1024 = 272.813KB
That's 351.563+272.813 = 624.376KB
Then you have 4.587.520-624.376 = 3.963.144KB
If (125*100)/222 = 56,3 and (97*100)/222 = 43,7 then:
Movie A == 3.963.144 * 0,563 == 2.231.250KB
Movie B == 3.963.144 * 0,437 == 1.731.894KB
So, based on these figures for final encoded stream (I forgot to include calculation for the muxing...) you're telling me that both movies will end up with the same quality?
I don't agree with that Karl.
Or maybe am I missing something of what you're saying?
Cheers

If you have different average bitrates for each movie, the TOTAL average (sum) of the bitrate still must be the calculated for the target size.
If you gave more bitrate to the action movie, the other movies will have LESS bitrate, and that's a fact :!:
Look at this in a simple way:
You have 2 movies, #1 is action and #2 is drama, each with the same average bitrate, targetting X final space.
Both will look identical, sort of, depending on complexity, and will fit exactly on X space.
Now, increase the average bitrate for movie #1 by 50%.
What are you going to do with movie #2 :?:
You HAVE to reduce the bitrate by 50% on movie #2, in order to maintain the same target size for the movies.
I hope this is clear now. :roll:

-kwag

We want to distribut 2 movies in different space, not only related to movie time, but bitrate needs.
I can't explain myself better.
It would be better that you take a look to the spreadsheet and see the maths and how changes related to differents inputs.

What "space" :?:
Isn't it to the same target space, which will always be fixed :?: (DVD-5 ~4.3GB, 800MB CD-R, etc.)

-kwag

My 2 cents...

What I usually do for a 2 film KDVD is to build a script with the 2 films I want to fit in KDVD, and with slicer. And run prediction.
I end with a Q value that is the same for both films... are they supposed to look the same quality with same Q value?. I thought yes.
Then I encode each of them separately, with the Q obtained. And each of them have a length (Kb), depending on their lenght (seconds) and bitrate (same Q for 2 different films will need different bitrates, depending on film complexity).

Is this what you all are talking about?. I'm afraid not. And maybe it is not of a help since you talk about CalcuMatic and finding out avg bitrate, and not Q. But just in case it is of a help...

The same point of view here DigiDoc.

I also just got into this subject ....

That approach is meeeeeega old and works flaweless ;)

I think what "they" try to explain is, same Bitrate doesnt mean same quality.
But If I want to have 2 Movies on one DVD-R I would also like to get a linear subjective quality on both films to be the same in their visual quality.

So whats responsable for visual quality "during the encoding" (not that avs stuff before):
Mainly the quantisation.

So if we take two movies, one action Movie with much uneasy water scenes and the other one is just a mainly dark one and do encode them using the same quantizer both will kome out at different sizes.

So what is beside other things the Goal of CQ/OVP encodings? Its the keeping of a qunatization to be at the almost same level during the whole movie = Almost constant Quality.

Take "Message in a bottle" and use in TmpgEnc a CQ at 80
+
Take "Seven" and also here do use a CQ at 80.

Seven will take almost 60-70% of the final size of "Message in a bottle" cause MessInABot. gots a lot of uneasy Waterscenes but both will have the SAME quality as we did our focus on the CQ when predicting both movies and not on the Bitrate.

Both Movies together will have an amount of needed Bitrate. So if that amount of bitrate overheads the wanted final bitrate for fitting on one DVD-R, we just lower the CQ on BOTH using the same value and we still keep both Movies at the same Quality but STILL different Bitrate.

Thats the way I did all my 2Movie DVD encodings till now and my eyes did underline that subjective recognisable constant quality when watching both movies of THAT DVD-R where they both are authored to.

So for me thats for 99& clear, ..... but every discussion is intended to maybe result in new things, so I keep watching :D

Suposse you have 2 movies * 100 min each one, one with high action scenes the other a drama.

If you want to fit any of them, twice in 1 dvd (forget audio), each one will fit 2202 Mb aprox. or so.
If you want to fit the 2 differents movies in 1 dvd, each one will fit 2202 Mb if you do calculate as usual.
If you do slicer samples with same CQ and see its final bitrates, you will see, for example that one have avg btr = 3500 and the other 2000.
If you apply calcs that the spreadsheet gives you, the target size won't be 2202 for each one. It will be big for high motion movie.

Please I beg you take a look at the spreadsheet, if you are interested in doing such kind of tool. If not I will be ahead with my one tool, and will do that I can.

Of course, and that's clear. :)
But the total size of both movies (or any total of movies) still HAS to be no larger than the size of the target media, and that's what I'm trying to make you see :!:
Remember :arrow: your target is FIXED :!:
You can add bits to one movie, and take bits from another movie, but the total number of bits MUST BE the same, because if it's not, then it will either be over or under the wanted target. That's what I'm trying to say.

-kwag

@Inc: What about 2 pass vbr encoding/encoders?

Maybe Boulder could explain it better than me.
I am not specially brillant with my english today.

I understand that.
For that you can see in my project:

http://www.digitalfaq.com/archives/i.../2005/06/9.png

last two columns avg kbps for final video and Kb for final video (forget values you see in picture, it don't reflect correct calculations).
After calculations you must to use that avg bitrate to fit that Kb for each individual film.
I don't talking about TMPGEnc or whatever CQ encoding, but 2 pass VBR ones.

Forgive me for butting in here I know im a relative noob and most of this stuff just goes over my head but looking at digitall.doc's post above could we use that method to calculate a two movie KDVD.

To find the correct Q factor could we not say split the target size for example 4482 MB and divide that by 2 to say 2241 MB per movie and use what Q factor we get from the two seperate scripts and their movies?

Just an idea, please go gentle on me and don't flame me to much. :D

Hi Michael :)
Of course you can do that.
Actually that's what I've been doing for almost 1 year.
But that's IMHO totally screwed method.
Because following your words above, if you have 1 movie with 20minutes and another one with 220minutes...
:arrow: Then your 20mins. movie encode will most probably look exactly like the original and your 220mins. will most definitly look very poor quality :arrow: bad bitrate allocation :mrgreen:.
So, what I've been saying is that we should try to share the available MB not equaly but proportionaly.
Again imagine that you have the same 20 vs 220.
You do your math and you get to the conclusion that just by looking at their duration you should target the 20mins. to 400MB and the 220mins. to 4.000MB.
BUT you forgot about something!
Since the 20mins. are (for instance) underwater action and the 220mins. are drama, you end up with a 20mins kinda ugly encode and with a veeery good drama encode.
What do you need to do then?
Spare some MB from the 220mins. encode to the 20mins encode so that you get ~750MB for action and ~3.650MB.
Maybe now you have 2 movies perfectly fitting 1 DVD-5 with almost the same quality ;-).
I really can't explain it better than this.
Cheers

And it is the better explanation I could to give (If I could express better in english, of course).

I don't know why Karl don't want to take a look at the spreadsheet.
It is very clarifier about what we are talking about.

Hey, Karl didn't say he won't look at it.
One thing we can't say about Karl is that he is not open minded.
Actually he may have already taken a look at it and spotted a mistake on it.
He is probably trying to tell us we're wrong and we're just not listening :lol:.
Looking at the spreadsheet or not we'll end up sorting out this issue, that I am sure of :).
Cheers

@rds_correia

Thank you for your clear explanation in response to my last post, now I fully understand the dynamics as there are so many variables to take into account.

So even if both movies were say an hour and a half, 3 hours in total and one was a drama and one was an action movie you would still not evenly distribute the bitrate needed in proportion.

Now I understand why these extra details need to be taken into account.

Again Rui thank you for such a clear explanation now I fully understand what is needed. :)

No need to thank Michael.
That's what we're here for :arrow: to discuss and to clear these issues and all are welcome to the discussion :).
Cheers

Sorry, I didn't want to give to think that. :oops:

And that was the key for my brain to trigger and understand what this is all about :lol:
Even though ALL movies will still have to have the average bitrate sum equal to the wanted for the final size, each movie should have a different size allocation, depending on the type.
For example, two movies on one DVD. One action and one drama.
The action movie might require 3GB, but the drama would only require 1GB.
So we need a DIFF calculation between both movies, to get a % offset for space allocation.
For example the drama's % will be 25% and the action will be 75%.
This way, the media (DVD, etc.) can be pre-splitted before CQ calculations are performed. Right :?: :D
Well, what we need is an MPEG parser/analyzer that can quickly analyze each source (VOBs, etc.), and generate that wanted % automatically.
After analyzing both movies, or more movies, it automatically decides what slice of the pie (space) will be allocated for each movie.
Guess I should crank up my dev system and run some experiments :cool:

@Rui,

Thanks for the enlightening chat on Skype ;)

-kwag

:ole:

And for that I was asking how to use a dll from VB6.
I think we need to use:

mediainfo - lib

http://sourceforge.net/projects/mediainfo/

It shows between another things, stream bitrate.

Now that is a really interesting idea Karl, and the method you described here sounds like a excellent one, I wonder how difficult this would be to put into practice, I hope not to difficult.

I hope your experiments turn out well, this could be very exciting. :D

@rds_correia

Thank you Rui, you are a real Gentleman, as are all the guys on this forum. :)

The mean approach is clear, to give space to each movie proportionally so both result in same quality.

But what do you expect by analyzing the "sources" bitrates of each?

Lets guess one source gots an average of 6000kbit and the other one only 5000kbit ... that would mean nothing as finally the 5000kbit source could be the one which needs more bits by keeping the same average quality than the 6000kbit one. ---- So the 5000kbit one was just encoded that "low" as the DVD-R did contain much more extras/motionMenue etc.

The only way is to parse out the m2v Videocontend on its included AverageQ!

Then you can make a calculation on the simple math of movietime and kbits incl. the difficult to parse out average Q of each movie.

That shows the proportion of a resulted quantisation at xxxxKbit.
But also here .... quants are different from encoder to encoder, so you would have to use the same encoder as the productioner of the DVDstream used ..... and that we also could parse ... if!! stored in the mpeg header.

Mediainfo.dll doesnt show Quantisations and the avg kbit calc is a simple math.

Take a deep breath .... and reset your thoughts ;)
2pass is NOT quality based.

2pass is exactly the opposite, as 2pass forces to reach the wanted avg Bitrate and not the wanted Quality.

Means you would have to encode slices in 2pass and parsing out the average Q and by that increasing/decreasing the avg values to obtain the Quality you want.
But thats like breaking into the locked back door of house where the main door at the front is unlocked and left open - just get in ;)

HC encoder does output the used avg quant, but as we know we shouldnt trust in that value for continous OVP usage.