thanks,i was waiting for this!
:D

Let's get ready to rumBLEEEEEEEEEE :lol:
It's playtime :mrgreen:

Thanks SansGrip :wink:
-kwag

heheh enjoy ;).

Works like a charm SansGrip :D
Just a small detail. When you run the "Sample Encoding Helper", and you go to step 2, could you add extensions .m1v and .m2v on the dialog? Because it defaults to .mpg, and the samples are usually video only .m1v of .m2v ( if MPEG-2 ) files.

-kwag

I gathered from the file size prediction thread that one's supposed to encode the sample with a system stream, and hence with a .mpg extension. Wouldn't this more accurate than a .m1v or .m2v without a system stream?

Actually, it should be more accurate using only the video stream, because the audio is already being calculated separately. So the .m1v or .m2v is a video only stream without any other dependencies. And that's the way it's encoded too. At least I encode video stream only ( ES Video Only ) in TMPEG.

-kwag

By "with a system stream" I meant the "System (Video only)" option. Since the final encode will have three streams -- video, audio and system -- and we're factoring out the audio, that leaves the other two streams to account for in the calculations. If you encode the samples as an elementary video stream with no system stream, wouldn't that cause inaccuracies since the final encode will have all three streams in it?

Or am I confused? ;)

Well, at least all the samples that I've done manually with the formula, I always used ( ES Video Only ) stream. The final file size has always been ~2% to ~3% less than predicted.

-kwag

The lack of a system stream might explain it. If your final size with video and audio streams only is, say, 780mb, with the system stream it'll be 780 * (2048 / 2018) = 791mb.

Or maybe I'm barking up the wrong tree. If you think it would be best to add m1v and m2v to the "open file" dialog it'll take me about a minute. My only concern is that if it really is best to encode samples with both a video and system stream, allowing ES files might throw people off...?

Ok, I just ran a test on two prediction samples. One as ES Video only and another as System ( Video Only ).
File sizes:
ES (Video Only): 9,752MB
System (Video Only): 25,705 8O

So obviously, it has to be run as ES stream.

-kwag

Wow, that's a huge difference. I'm going to cancel my current encode and run the same test on my reference source material. If I get that big a difference I'll release 0.2a with .m1v and .m2v in about 20 minutes.

Edit: Just goes to show there's no substitute for testing! Thanks kwag :).

Hey, anytime :D
Maybe TMPEG is screwing up somewhere :roll: . I'm on 2.59 PLUS

-kwag

I guess it's not TMPEG. Just tried it with 2.58 PLUS, and got the same large file size using System(Video Only).

-kwag

2.59 must be acting up, because I get completely expected results from the two encodes.

System (video only): 15.3mb
ES (video only): 15.1mb

In this case, the video and system stream is...

15.1 * (2048 / 2018) = 15.3

...exactly the right size :?: :?:.

This is probably a stupid question, but... are you SURE you're hitting "System (Video only)" and not "System (Video+Audio)"?? 8O

Edit: I'm using 2.58 not-plus...

Yes. 100% sure. Just running it right now to be sure. System(Video only), not the last one(Check button). Same result 8O
So maybe the PLUS is screwed up 8O , but then 2.58 does the same too :!:

-kwag

2.58 "regular" works as expected for me. I'm wondering if this is a PLUS issue? I can't think of anything other than a bug that would account for such a massive difference in file size :?:... Video + system streams should be just over 1.5% larger than video alone 8O.

Downloading TMPEG standard now...

Edit: Same result with the 2.59 free version 8O 8O

-kwag

heheh, and here was me thinking I was just about to go to bed... :mrgreen:

I know I am going to bed :)
It's 4:00AM here 8O .
Good night ( or morning 8O ) everyone :lol:

-kwag