11-20-2002, 10:23 PM
|
Free Member
|
|
Join Date: Nov 2002
Location: Ontario, Canada
Posts: 1,135
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Just so you know progress is being made...
|
Someday, 12:01 PM
|
|
Site Staff / Ad Manager
|
|
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
11-20-2002, 10:29 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Oh boy, this is getting better by the hour
Thanks SansGrip
-kwag
|
11-21-2002, 01:28 PM
|
Free Member
|
|
Join Date: Jun 2002
Location: São Paulo - Brasil
Posts: 879
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by kwag
Quote:
Originally Posted by SansGrip
Nope, I'm the one who's drunk . I should've run some real numbers through and I would've spotted the error.
I think what's confusing me is that when you adjust the scale factor down in KVCD Predictor, the sample target size goes up, and vice versa.
Is that the correct behaviour?
I've been thinking way too much about noise and averages today to think properly about anything else .
|
Hi SansGrip,
It should be the other way around. When you increase the factor, the file size goes up
-kkag
|
Hey, Hey!
Wait there... I think you 2 are talking about different things.
(It should be, or I'm not drunk... I'm crazy! )
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?
|
11-21-2002, 01:32 PM
|
Free Member
|
|
Join Date: Jun 2002
Location: São Paulo - Brasil
Posts: 879
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by SansGrip
sample_size = 710 / (5728 / 100) / 0.90 = 13.77
sample_size = 710 / (5728 / 100) / 1.05 = 11.80
As you can see, the sample size rises when the scale factor falls, and vice versa. Either this is the correct behaviour when obtaining the sample size from the final size, or my rearrangement of the formula is wrong, or the formula itself is wrong.
|
Yes
That is the correct behaviour when obtaining the sample size.
|
11-21-2002, 01:58 PM
|
Free Member
|
|
Join Date: Jun 2002
Location: São Paulo - Brasil
Posts: 879
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by SansGrip
Just so you know progress is being made...
|
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?
|
11-21-2002, 03:31 PM
|
Free Member
|
|
Join Date: Oct 2002
Location: USA
Posts: 12
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by SansGrip
In this version the "Get movie length from source file..." option doesn't work, because it's going to be a lot more complicated than I imagined (for programmers amongst you, I have to learn how to write a managed C++ class to access the Video for Windows framework. Any hints appreciated ). I'm going to work at it though, and hopefully it'll be ready for 0.2.
|
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
|
11-21-2002, 04:02 PM
|
Free Member
|
|
Join Date: Nov 2002
Location: Ontario, Canada
Posts: 1,135
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by muaddib
Yes
That is the correct behaviour when obtaining the sample size.
|
Phew!
|
11-21-2002, 04:05 PM
|
Free Member
|
|
Join Date: Nov 2002
Location: Ontario, Canada
Posts: 1,135
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by muaddib
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.
|
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.
|
11-21-2002, 04:12 PM
|
Free Member
|
|
Join Date: Nov 2002
Location: Ontario, Canada
Posts: 1,135
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by johneboy
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).
|
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 .
Quote:
Originally Posted by johneboy
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'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?
|
11-21-2002, 06:45 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by SansGrip
I'm going to have to write a "managed C++" class to access VfW, which I can then call from C#.
|
"Managed C++" or "UnManaged C++"
-kwag
|
11-21-2002, 09:18 PM
|
Free Member
|
|
Join Date: Nov 2002
Location: Ontario, Canada
Posts: 1,135
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by kwag
"Managed C++" or "UnManaged C++"
|
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...
|
11-22-2002, 07:53 PM
|
Free Member
|
|
Join Date: Nov 2002
Location: Ontario, Canada
Posts: 1,135
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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 .
|
11-22-2002, 08:30 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by SansGrip
(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.)
|
Maybe that's the reason the prediction fluctuates between 2% to 5%
Thanks again Sansgrip
-kwag
|
11-22-2002, 08:45 PM
|
Free Member
|
|
Join Date: Jul 2002
Posts: 1,224
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Hi Kwag,
Kwag wrote:
Quote:
Maybe that's the reason the prediction fluctuates between 2% to 5%
Thanks again Sansgrip
|
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
|
11-22-2002, 09:20 PM
|
Free Member
|
|
Join Date: Nov 2002
Location: Ontario, Canada
Posts: 1,135
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by black prince
If that's the case how reliable is "Framecount" in avs script for file size prediction.
|
I would say if two programs disagree on the frame count and one of them is Avisynth, the other program is wrong .
Quote:
Originally Posted by black prince
I used VirtualDub to check framecount against Tmpgenc's source range and they differ.
|
That's strange. By how much did they differ?
Quote:
Originally Posted by black prince
Between the 3 of them, which one is correct?
|
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.
|
11-22-2002, 09:22 PM
|
Free Member
|
|
Join Date: Jul 2002
Posts: 1,224
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
-black prince
|
11-22-2002, 09:26 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by black prince
Hi Kwag,
Kwag wrote:
Quote:
Maybe that's the reason the prediction fluctuates between 2% to 5%
Thanks again Sansgrip
|
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
|
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
|
11-22-2002, 09:27 PM
|
Free Member
|
|
Join Date: Nov 2002
Location: Ontario, Canada
Posts: 1,135
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by kwag
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 )
|
...or you could just use KVCDP :P
|
11-22-2002, 09:32 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by SansGrip
Quote:
Originally Posted by kwag
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 )
|
...or you could just use KVCDP :P
|
Of course!, how could I forget
-kwag
|
11-23-2002, 01:12 AM
|
Free Member
|
|
Join Date: Nov 2002
Location: Ontario, Canada
Posts: 1,135
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Here's version 0.2 (and source code).
Changes:
Quote:
Changed numeric spinners to textboxes (I prefer their behaviour for this application). Added "Sample points" textbox. Renamed "Scale factor" to "Error margin" and changed algorithm accordingly. Implemented "Get movie length from source file..." functionality; can read running time from .avs, .avi and .d2v files; also works with drag 'n' drop. Added "Sample encoding helper" to ease finding the correct CQ_VBR setting for the movie. Added version to title bar.
|
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 .
|
All times are GMT -5. The time now is 04:30 AM — vBulletin © Jelsoft Enterprises Ltd
|