Update...
 

Just so you know progress is being made...

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

:)

Oh boy, this is getting better by the hour :lol:

Thanks SansGrip :wink: :mrgreen:

-kwag

Hey, Hey!
Wait there... I think you 2 are talking about different things.
(It should be, or I'm not drunk... I'm crazy! :lol: )
SansGrip is talking about the sample size, and kwag is talking about the mpeg final size (like I was).

With that same formula...
If you want to find the final size from an encoded sample, then if you increase the factor, the final size goes up.
But, if you want to find the sample size from a fixed final size, then if you increase the factor, the sample size goes down (like you said).

Man... is that right? :roll: :lol:

Yes :!: :lol:
That is the correct behaviour when obtaining the sample size.

Re: Update...
 

Man, that’s GREAT!

There is just one thing I would like to suggest...
In Step 3, when you show the size of the encoded sample and the target size; would be good if you also show the predicted final size with this encoded sample. I think that this information will make the decision between stop or try another CQ_VBR easier.

You could add just a complement to the message you are using now. Something like this:
“(…) The sample strip is 0.62 megabytes smaller than the target size, and will produce a mpeg file of an approximate 999.99 megabytes.”

What you think?

Re: First release
 

Hey SansGrip.. I dont know C++.. but i do know VB..
and i made a program that will let you select a media file (MPEG or AVI)
and it will tell you the length in HH:MM:SS MMM and SSSS
as well as how many frames, and the (estimated) frame rate
(Total Frames / SSSS). It also does other things too, but if you want the code to get the frame and playing time, i would be more then happy to give it to you.. I just dont know if it will help you out, since its in VB
(its all API tho)


let me know

Phew! :D

Re: Update...
 

Yes, very good idea :).

At the moment that dialog doesn't actually do the calculations -- it's just a mock-up I made after completing the design of the user interface. I'm going to make it work now, and will incorporate your suggestion.

Re: First release
 

The main problem is that I'm using .NET, and it doesn't incorporate any video classes yet. While I could read the metadata directly from the AVI header this wouldn't work with AVS files, so I need to use the Video for Windows API instead. Normally this would be easy but because .NET is what's known as "managed" code (it has garbage collection, and so on) I'm going to have to write a "managed C++" class to access VfW, which I can then call from C#.

Luckily I just this morning bought a book on C++ .NET, and it looks like this will be easier than I imagined.

In related news, I also got a book on assembly language, so I'm hoping to start optimizing my filters pretty soon :).

I've used VfW before from C++ so that's not a big deal -- what's new for me is accessing a C++ DLL from C#. Thanks for the offer though, I appreciate it :).

BTW, how do you get the MPEG metadata? Do you read the header directly or use DirectShow?

Re: First release
 

"Managed C++" or "UnManaged C++" 8O 8)

-kwag

Re: First release
 

Managed C++ is MS-speak for C++ with garbage collection. It's the only kind of C++ you're allowed to call from C#. The good news is I've "managed" to get the C# GUI calling a C++ method. Now I just need to make that method return the correct values... ;)

Quick update
 

I thought I'd let you all know the current status of development...

I just finished the "Get movie length from source file..." functionality, so from version 0.2 you'll be able to select a .avs, .avi or .d2v file and have KVCD Predictor automatically determine the running time of the movie. I'll implement MPEG support in a later version if there's any demand for it.

(Side note: In the course of writing the .d2v-parsing code I discovered that FitCD does not use the correct algorithm for determining how many frames are in the movie when reading the .d2v file. This means it can be out by several seconds, at least with NTSC forced film material, so it would be best to let KVCDP read the file instead of simply typing in the values you see in FitCD.)

Before 0.2 can be released I need to finish the sample encoding helper. I've changed my mind slightly about how exactly it's going to work, but hopefully the new way will be more intuitive.

I'm hoping it'll be ready in the next couple of days. I'll keep you posted :).

Re: Quick update
 

Maybe that's the reason the prediction fluctuates between 2% to 5% :roll:
Thanks again Sansgrip :D

-kwag

Hi Kwag,

Kwag wrote:
If that's the case how reliable is "Framecount" in avs script for
file size prediction. I used VirtualDub to check framecount against
Tmpgenc's source range and they differ. :) Is there a way to view
what value is being used in the script to calculate file size :?: Between
the 3 of them, which one is correct?

-black prince

I would say if two programs disagree on the frame count and one of them is Avisynth, the other program is wrong ;).

That's strange. By how much did they differ?

All programs accepting input from Avisynth should report the same number of frames as Avisynth shows with Framecount(), unless that program is doing something funky like IVTC.

Hi Kwag and SansGrip,

Just used "ShowFrameNumber()" in avs script:

Tmpgenc ....................--> 146,654 total frames
ShowFrameNumber .....--> 146,654 "
VirtualDub ..................--> 146,655 "
FitCD .........................--> 146,661 "

Seems that framecount is only off if you hardcoded FitCD's value.
The file size formula should be correct. 8)

-black prince

You can use IfoEdit to open your .IFO file, and then read the exact number of frames. But it will give you the total frames AT 30 FPS , so if you're encoding with "Force FILM" on DVD2AVI, your actual number of frames fed to TMPEG are ~Total frames = ( FramesReadByIfoEdit / 30 ) * 24 )

-kwag

...or you could just use KVCDP :P

Of course!, how could I forget :lol:

-kwag

New version 0.2
 

Here's version 0.2 (and source code).

Changes:

See the docs for more information.

I've tested this one a bit and it seems to give the correct results. The helper gives pretty good results -- normally very close to target size within three iterations.

@kwag - I altered the binary search algorithm slightly. Now, if the resulting sample is larger than the target it'll drop down a little more than according to your formula. This seems to speed things up when the CQ is too high, since it's obviously desirable to be slightly below the target size rather than above. I think the algorithm can still be improved, though, perhaps by remembering previous iterations and somehow applying that information when calculating the new CQ... Any thoughts?

Well, have fun and let me know what you think. Hopefully this one won't need two bugfix releases ;).