How compute m2ts result files size ?

[jpsdr]

If i have the following :
A raw h264 video file of size V1.
2 audio files of sizes A1 and A2.
Does someone know the formula wich will give me, with an accuracy of around 1MB for files of around 5GB, the size of the resulting m2ts muxed file ? (Blu-Ray authoring). :confused:
If others parameters like bitrate/frame are to be used, notify me.

Thanks.

[Groucho2004]

Check out the source code from Selur's sx264 GUI (http://forum.doom9.org/showthread.php?t=143399&highlight=sx264). His calculations for M2TS overhead are pretty accurate.

[Selur]

here's what I use in Hybrid atm:

qint64 CalculationService::m2tsVideoOverhead(const qint64 completeVideo, const int frameCount, \
const bool audioHandling)
{
qint64 videoOverhead = 0;
qint64 videoSize = completeVideo; //videoOverhead+generalOverhead+rawVideo
if (!audioHandling) {
videoOverhead = frameCount*263 + 9412;
}
videoSize -= videoOverhead;
int packageSize = 192;
int packageFill = 184; //of 192
sendMessage(MYDEBUG, "packageFill", packageFill);
qint64 packageCount = videoSize/packageSize+1;
qint64 packageOverhead = packageCount*(packageSize-packageFill);
videoOverhead += packageOverhead;
return videoOverhead;
}
qint64 CalculationService::m2tsAudioOverhead(const bool videohandling, const int frameCount, const double framerate, const QString format, const qint64 rawsize)
{
int blocksize = 80;
if (format == "ac3" || format.contains("true") || format == "dts"
|| format == "dts-hd" || format == "pcm") {
blocksize = 907;
}
qint64 audioOverhead = qint64((2*blocksize)/180.0 * 8.0 + 17.0 +0.5) * ((qint64)(rawsize*1.0/(blocksize*1.0)+0.5));
if (videohandling) {
double length = frameCount/framerate;
double audiobitrate = rawsize/length;
audioOverhead += frameCount*(262+(audiobitrate/184+1)) + 9412;
}
return audioOverhead;
}

If you find a better way to calculate the overhead please share. :)

[jpsdr]

Thanks for answers. I have no idea of how calculate them, it's why i'm asking.
I need it for using in oposite way : Knowing the size (or bitrate) of my audio and knowing my final avaible size, i need to know how exactly (or as precise as possible) how much data will be avaible for my raw video (=> what bitrate i can use).

@Selar : What unit is the result size ?

[Selur]

What unit is the result size ?
byte

Knowing the size (or bitrate) of my audio and knowing my final avaible size, i need to know how exactly (or as precise as possible) how much data will be avaible for my raw video (=> what bitrate i can use).
Sorry, but if you got a function that helps you how to calculate audio&video overhead, calculating the size of the bitrate available for a given size isn't hard,... ;)
sx264 and Hybrid both do it -> sx264 source code is unorganized, but iirc the X264Model::setBitrateForSizemethodis the method that does exactly what you want with the methods i quoted,.. ;)

Cu Selur

[jpsdr]

I'm having trouble...
Note : 1k=1e3 1M=1e6 b=bit B=Byte.
I have a video of 145037 frames at 23.976fps.
Video bitrate is 5922kb, audio bitrate is 448kb (AC3).
According the formulas, result file should be around 5122MB, with audio header around 119MB and video header around 187MB.
Problem is that my result m2ts file with Scenarist is around 5111MB, so, 11MB smaller than expected !

Edit : Maybe i'm doing something wrong, but i don't see what...

[poisondeathray]

you can try this tool (from avchdcoder author)

http://tools.twanwintjes.nl/index.php?page=avchdcalc

[jpsdr]

Nice tool.
Unfortunately, not fitted to my needs, as i often have severals m2ts files in my result Blu-Ray. Would have been perfect if i have only one m2ts file in result, but it's not always the case.

@selur
About the code you've provided, if there is several audio stream, do i need to add all the overhead audio of each stream, or is there something different again ?

[Selur]

@poisondeathray: afaik AVCHDCalculator is a. closed source and b. doesn't allow custom target size.
But it would be interesting to know which formulas were used.

Problem is that my result m2ts file with Scenarist is around 5111MB, so, 11MB smaller than expected !
better 11MB to small, than 11MB to large ;)
Sorry, should have posted that I know that the calculation isn't the best (most accurate) and everyone is welcome to post a tweak and correct it, it's the best I came up with the data I had. And at least I never encountered a problem with it predicting the file size to low or being really far of. :) (11MB on 5022MB doesn't seem that bad, to me since it's mainly educated guessing :))

With multiaudio the formula will be more off. (assuming to large audio overhead)
Since I personally normally don't encounter multi audio I never spend much time collecting statistical data and thinking about what happens when multi audio is present.
(I was totally happy when I found a way to calculate single audio&video :))


Cu Selur

[Groucho2004]

Sorry, should have posted that I know that the calculation isn't the best (most accurate) and everyone is welcome to post a tweak and correct it, it's the best I came up with the data I had.

We're talking about 0.2 % deviation here. I'd say it's more than adequate considering that one should always shoot for a target size 0.5% - 1% below the disk capacity.

[jpsdr]

I've made some test, and have following results :
Video is 147084 frames at 23.976fps encoded at 5923.32kb.
Audio is AC3 at 448kb. Total overhead is 278286018 bytes.
Audio is AC3 at 192kb. Total overhead is 290556610 bytes.
Video is 119098 frames at 23.976fps encoded at 5921.61kb.
Audio is AC3 at 448kb. Total overhead is 225322715 bytes.
Audio is AC3 at 192kb. Total overhaed is 235254491 bytes.
When audio bitrate goes low, overhead grows.
Actualy, if bitrate audio b is in kilobit (1000 bits), for AC3 audio, one part of the calcul of audio overhead is :
(2000*(C-b)/256)*time, time is duration is seconds. C would be 640 will not surprise me !
Actualy, for my specific cases, with my video bitrate : (2000*(640-audiobitrate)/256)*time + 1830*frames gives a good overhead estimation. If some are interesting to search using this as a base search...

[Selur]

Video is 147084 frames at 23.976fps encoded at 5923.32kb.
Audio is AC3 at 448kb. Total overhead is 278286018 bytes.
Audio is AC3 at 192kb. Total overhead is 290556610 bytes.
Video is 119098 frames at 23.976fps encoded at 5921.61kb.
Audio is AC3 at 448kb. Total overhead is 225322715 bytes.
Audio is AC3 at 192kb. Total overhaed is 235254491 bytes.

In general when posting numbers it would be helpful to see the following infos:
1. raw video size (byte)
2. video frame count
3. raw audio size (byte)
4. average audio bitrate (bit/s)
5. length of video (assuming audio&video length is the same), video frame rate
6. size of video only muxed inside m2ts container (byte)
7. size of audio only muxed inside m2ts container (byte)
8. size of video&audio muxed together inside m2ts container (byte)
this would allow to use them as control values for later tests. :)

Actualy, if bitrate audio b is in kilobit (1000 bits), for AC3 audio, one part of the calcul of audio overhead is :
(2000*(C-b)/256)*time, time is duration is seconds. C would be 640 will not surprise me !
Actualy, for my specific cases, with my video bitrate : (2000*(640-audiobitrate)/256)*time + 1830*frames gives a good overhead estimation. If some are interesting to search using this as a base search...
Here's why I'm reluctant to use this as a base for a search:
1. since the package size of m2ts is 192 it would kind of make sense to see it appear somewhere in the formula
2. some value that is assumed as average package fill would make sense
3. calculation video overhead by only looking at the frame count is definitly a dead end even if video bitrate is 1/5 of the current value, video overhead stays the same,.. ;)

video only overhead example:
video frame count: 109645 frames
video frame rate: 23.976 frames/second
video length: frame count/frame rate = 4573.115 seconds
raw video size: 8.472.672 Bytes
video inside m2ts: 37.502.976 Bytes
-> video overhead: 29.030.304 Bytes


(2000*(640-audiobitrate)/256)*time + 1830*frames would be way of:
(2000*(640-0)/256)*4573.115 + 1830*109645 = 5000*4573.115 + 1830*109645 = 22865575 + 1830*109645 = 22.865.575 + 200.650.350 = 223.515.925
I know you are probably aware that the video overhead formula wasn't good. I just wanted to show an extreme example,..

The main point is that a formula to calculate the overhead should not contain constants that fall from the heavens. ;)

Sadly I lost nearly all my muxing data collection a year ago in a hdd crash, only thing I found was some data about a single video-only source I reencoded with different bitrates:
m2ts - videoOnly

Framecount: 109645
Length: 109645/23,976 = 4573,1147814481147814481147814481

quant 51
37.502.976 Bytes inside container
8.472.672 Bytes raw
29.030.304 Bytes overhead

200
143.388.672 Bytes inside container
111.974.627 Bytes raw
31.414.045 Bytes overhead


300
200.534.016 Bytes inside container
166.799.049 Bytes raw
33.734.967 Bytes overhead


400
257.857.536 Bytes inside container
221.618.987 Bytes raw
36.238.549 Bytes overhead


500
315.033.600 Bytes inside container
276.435.819 Bytes raw
38.597.781 Bytes overhead

1000
601.055.232 Bytes inside container
550.501.276 Bytes raw
50.553.956 Bytes overhead

2000
1.173.006.336 Bytes inside container
1.098.623.746 Bytes raw
74.382.590 Bytes overhead

A side from the lag of suspected variables, a main problem with the audio overhead formula (2000*(C-b)/256)*time for me is that using C = 640 would result in no or negative overheads if the audio bitrate is 640+kbit/s. ;)

Cu Selur

Ps.: aiming for a formula that only works if the target size is i.e. 10GB, DVD9, DVD5 or something like that is a thing that would probably be easier, but will probably not result in a all around working formula

[jpsdr]

As i said, it's for one AC3 audio track, so, in AC3 case, bitrate is not more than 640kb i think, and my actual formula is for now only with the video bitrate i've used.
I'll add later the others files size informations.
I'm currently doing a 10000kb video to try to have video track at different bitrate, to identify video parameter.
I'll also do some tests with 640kb AC3 audio track.
I'm not interested in audio or video only, because they may have different way of doing things, and Scenarist will probably not allow me a track without video stream.

[jpsdr]

Video1 : 147084 frames @23.976fps raw h264 encoded (x264) at 5923.32kb. .264 file size : 4542170174 bytes.
Video2 : 119098 frames @23.976fps raw h264 encoded (x264) at 5921.61kb. .264 file size : 3676859941 bytes.
Audio 1.1 (for video 1) : AC3 encoded at 448kb. AC3 file size : 343538944 bytes.
Audio 1.2 (for video 1) : AC3 encoded at 192kb. AC3 file size : 147230976 bytes.
Audio 2.1 (for video 2) : AC3 encoded at 448kb. AC3 file size : 278170368 bytes.
Audio 2.2 (for video 2) : AC3 encoded at 192kb. AC3 file size : 119215872 bytes.

M2TS files :
(1) : Video1 + audio1.1 => 5163995136 bytes.
(1.1) : Video1 + 2xaudio1.1 => 5532076032 bytes.
(2) : Video2 + audio2.1 => 4180353024 bytes.
(2.1) : Video2 + 2xaudio2.1 => 4478392320 bytes.
(3) : Video1 + audio1.2 => 4979957760 bytes.
(3.1) : Video1 + 2xaudio1.2 => 5163995136 bytes.
(4) : Video2 + audio 2.2 => 4031330304 bytes.
(4.1) : Video2 + 2xaudio2.2 => 4180353024 bytes.

[jpsdr]

Video3 : Video1 encoded at 9971,98kb. .264 file size : 7646802893 bytes.
Video4 : Video2 encoded at 9998,64kb. .264 file size : 6208381775 bytes.
Audio 1.3 (for video1) : AC3 encoded at 640kb. AC3 file size : 490769920 bytes.
Audio 2.3 (for video2) : AC3 encoded at 640kb. AC3 file size : 397386240 bytes.

M2TS files :
(5) : Video3 + audio 1.1 => 8403603456 bytes.
(6) : Video4 + audio 2.1 => 6821910528 bytes.
(7) : Video1 + audio 1.3 => 5348038656 bytes.
(8) : Video2 + audio 2.3 => 4329375744 bytes.

Now, i think there is globaly enough relevant data to create a good estimation of video/audio overhead in case of AC3 audio file.

[jpsdr]

For now, i think, for video + audio :
Video overhead is rawvideosize/23 (or rawvideosize/23 + constant).
For at least 448kb and 192kb, audio overhead is : "something"-rawaudiosize/16.
Still not found what this "something" is for audio.
For 192kb and 448kb, a working formula is (1000*(2134-bitrate)/128)*time, but it's only considering if the "something" is directly linked to the time.

[jpsdr]

According the data, i have for now the following formulas :
Video overhead = rawvideosize/23
Audio :
AC3 192kb & 448kb : K=696*frames (or K=29*fps*frames, i don't know, only tested with 23.976fps video)
Audio overhead = K-rawaudiosize/16. I don't know for which bitrate value formula switch.
AC3 640kb : Audio overhead=800*frames.

[Selur]

may be also worth a try:
qint64 CalculationService::m2tsVideoOverhead(const qint64 completeVideo, const int frameCount, \
const bool audioHandling)
{
qint64 videoOverhead = 0;
qint64 videoSize = completeVideo; //videoOverhead+generalOverhead+rawVideo
if (!audioHandling) {
videoOverhead = frameCount*263 + 9412;
}
videoSize -= videoOverhead;
int packageSize = 192;
int packageFill = 185; //of 192
sendMessage(MYDEBUG, "packageFill", packageFill);
qint64 packageCount = videoSize/packageFill;
qint64 packageOverhead = packageCount*(packageSize-packageFill);
videoOverhead += packageOverhead;
return videoOverhead;
}

qint64 CalculationService::m2tsAudioOverhead(const bool videohandling, const int frameCount, const double framerate, const QString format, const qint64 rawsize)
{
int blocksize = 80;
if (format == "ac3" || format.contains("true") || format == "dts"
|| format == "dts-hd" || format == "pcm") {
blocksize = 907;
}
double packageSize = 192.0;
double packageFill = 182.0;
qint64 audioOverhead = qint64((2*blocksize)/packageFill * 8.0 + 17.0 +0.5) \
* ((qint64)(rawsize*1.0/(blocksize*1.0)+0.5));
if (videohandling) {
double length = frameCount/framerate;
double audiobitrate = rawsize/length;
audioOverhead += frameCount*(packagesize+(audiobitrate/packageFill+1)) + 9412;
}
return audioOverhead;
}

[jpsdr]

I've allready try your formulas you give in the post #3, error is too big for me... Has i said, your formulas give around 11MB over a stream with subtitles ! Wich indeed result of around 30MB too much for a stream (subtitles was around 20MB), resulting in 360MB error for 12 streams (my need). Way too much out of the league for me, i'm looking for error <1MB (by stream) !

[Selur]

You did notice it's a modified version in the last post didn't you?

[jpsdr]

My humble mistake !!
I'll try these asap.
I nevertheless still need with my data, to check (unless you've already done), how compute audio overhead with 2 audio tracks.

How much is "generaloverhead" for video, knowing only "rawvideosize" ?

[Selur]

How much is "generaloverhead" for video, knowing only "rawvideosize" ?
The assumtion is that the total overhead is a combination of:
rawVideoSize + videoOverhead + rawAudioSize + audioOverhead + generealOverhead
where generalOverhead is some sort of Overhead that occures when audio,video and other stuff are combined in a source.
-> so for videoOnly there would be no generalOverhead ;)
I deliberately only mentioned it in the comments, so ignore it (assume generealOverhead = 0) :)

Here's how to use the formulars in general:
1. decide if you got audio&video or video- or audio-only
2. assuming you have audio&video
3. you start with the m2tsAudioOverhead calculation
the result of this is than taken to calculate targetVideo - audioOverhead - audioRawSize, which is called completeVideo in the m2tsVideoOverhead call. :)
then you calculate your m2tsVideoOverhead
This would later result in an assumed target size of:
rawVideoSize (here we take the result we really got as rawVideo) + calculated videoOverhead + rawAudioSize + calculated AudioOverhead


As a side note:
I doubt it is even possible to produce a 1MB accurate size prediction when reencoding, since most encoders (x264 too) are not that accurate (1MB on DVD5 size (4479MB) isn't really much) and you would have to predict how much the encoder would stray from your target size. So I would be really happy if we end up with a formula that will at maximum deliver a prediction that will cause the result to be 5MB smaller than the size wanted. (and I'm not even sure if 5MB is to high of a goal)

Cu Selur

[jpsdr]

Size prediction accuracy is one thing yes, formula accuracy is another.
My need is for several streams on one Blu-Ray, so the little program i've made is using a basic dichotomy algorithm to find the bitrate.

[jpsdr]

@Selur
I've compared with my little program.
Stream (1) :
Your formulas : m2ts = 5168064090 / Total overhead = 282349047
Mine : m2ts = 5164100177 / Total overhead = 278385134
Reality : m2ts = 5163995136 / Total overhead = 278286018
Mine is less than 1MB higher, yours is around 4MB higher.
Stream (3) :
Your formulas : m2ts = 4924849338 / Total overhead = 235442604
Mine : m2ts = 4980061137 / Total overhead = 290654403
Reality : m2ts = 4979957760 / Total overhead = 290556610
Mine is less than 1MB higher, yours is around 55MB lower.
Stream (7)
Your formulas : m2ts = 5350475154 / Total overhead = 317528880
Mine : m2ts = 5348099365 / Total overhead = 315153091
Reality : m2ts = 5348038656 / Total overhead = 315098562
Mine is less than 1MB higher, yours is around 2MB higher.
Case of stream (3) is totaly off...

My formulas may be a little less generic, more specific case, but more accurate apparently.
I think, nevertheless, my formulas are probably not usable for other audio than AC3.

[jpsdr]

For 2 audio streams, i found audio overhead is 1008*frames-totalsize/16. Works for 2x192 and 2x448.
Will try to produce more data to check if 448/192 is the same than 192/448, and check with 640...

[jpsdr]

Note : Files is the same with either audio 192/448 or 448/192.
M2TS files :
(9) : Video1 + audio 1.1 + audio 1.2 => 5348038656 bytes.
(10) : Video2 + audio 2.1 + audio 2.2 => 4329375744 bytes.
(11) : Video1 + audio 1.3 + audio 1.2 => 5532076032 bytes.
(12) : Video2 + audio 2.3 + audio 2.2 => 4478392320 bytes.
(13) : Video1 + audio 1.3 + audio 1.1 => 5716113408 bytes.
(14) : Video2 + audio 2.3 + audio 2.1 => 4627415040 bytes.
(15) : Video1 + 2*audio 1.3 => 5900150784 bytes.
(16) : Video2 + 2*audio 2.3 => 4776431616 bytes.

According these data, for AC3 video files, audio overhead is, using my formulas for video overhead :
1 audio track :
AC3 with bitrate 192/448 : 696*frames-rawaudiosize/16
AC3 with bitrate 640 : 800*frames.
2 audio tracks :
AC3 track with bitrate 192/448 : 504*frames-rawaudiosize/16
AC3 track with bitrate 640 : 608*frames.
I think formula 192/448 works for any ac3 bitrate <=448.
I don't know for 512/576 what formula is to use.

[Sharc]

If i have the following :
A raw h264 video file of size V1.
2 audio files of sizes A1 and A2.
Does someone know the formula wich will give me, with an accuracy of around 1MB for files of around 5GB, the size of the resulting m2ts muxed file ? (Blu-Ray authoring). :confused:
If others parameters like bitrate/frame are to be used, notify me.

Thanks.
Maybe you want to check out this (http://jvance.com/pages/BitrateCalc.xhtml).

[jpsdr]

It doesn't fit my needs, i can have several m2ts streams in final (at least until 12).

[Selur]

Mine is less than 1MB higher, yours is around 55MB lower.
Yup, I see the problem. :) 192is an 'evil' bitrate, since the package fill is probaby way lower than anticipated with my formula.

[Groucho2004]

Maybe you want to check out this (http://jvance.com/pages/BitrateCalc.xhtml).

Haven't tried it but a quick look at the source code reveals this function:

private static int GetM2tsAudioOverhead(AudioCodec audioType, int samplingRate, double length)
{
// TODO: ??
return 0;
}


:D :D :D

[jpsdr]

Yup, I see the problem. :) 192is an 'evil' bitrate, since the package fill is probaby way lower than anticipated with my formula.
I'll try later to check if 96 still match my formula. If it did, it means error with your formula my increase as bitrate decrease.

[jpsdr]

Audio 1.4 (for video1) : AC3 encoded at 96kb. AC3 file size : 73615488 bytes.
Audio 2.4 (for video2) : AC3 encoded at 96kb. AC3 file size : 59607936 bytes.
Audio 1.5 (for video1) : AC3 encoded at 128kb. AC3 file size : 98153984 bytes.
Audio 2.5 (for video2) : AC3 encoded at 128kb. AC3 file size : 79477248 bytes.

M2TS files :
(17) : video1 + audio 1.4 => 4906340352
(18) : video2 + audio 2.4 => 3971721216
(19) : video1 + audio 1.5 => 4906340352
(20) : video2 + audio 2.5 => 3971721216
(21) : video1 + 2xaudio 1.4 => 5016760320
(22) : video2 + 2xaudio 2.4 => 4061134848
(23) : video1 + 2xaudio 1.5 => 5016760320
(24) : video2 + 2xaudio 2.5 => 4061134848
(25) : video1 + audio 1.4 + audio 1.5 => 5016760320
(26) : video2 + audio 2.4 + audio 2.5 => 4061134848

Apparently, overhead audio size for 96kb and 128kb have another formula...

[Selur]

did some testing and atm it seem like:
complete overhead = X*audioOverhead + videoOverhead - (frameCount * 2*packageSize/3)
where packageSize is 192
X = number of audiostreams
audioOverhead = overhead caused when muxing a raw audio stream on it's own
videoOverhead = overhead caused when muxing a raw video stream on it's own

[jpsdr]

You mean :
videoOverhead = frameCount*263 + 9412;
audioOverhead = qint64((2*blocksize)/packageFill * 8.0 + 17.0 +0.5)*((qint64)(rawsize*1.0/(blocksize*1.0)+0.5));
For on their own ?

[Selur]

video-only overhead is probably something like:
double packageSize = 192.0;
double packageFill = 186.0;
double packageFactor = packageSize+packageFill/4+packageFill/8;
double frameOverhead = frameCount*packageFactor;
qint64 videoOverhead = frameOverhead + (size - frameOverhead)*8/packageFill;

hadn't had any time to test it and audioOverhead neeeds a rework too. ;)

[jpsdr]

More trouble with 96kb and 128kb... It seems that audio overhead, with one track, for these is something like K-rawaudiosize.
Actualy, i have K of 1133*frames for 1 audio track, and 942*frames for 2 audio tracks.

[jpsdr]

According my datas, you should have, when there is audio (d=delta/difference) : d(videooverhead)=d(videosize)/23, or at least, a N/M factor very very near to 1/23...

[Selur]

a N/M factor very very near to 1/23...
yup, at least for large files,..
As far as I can tell you got two part building the videoOverhead:
1st part being the frameOverhead (which only relies on the frame number and the average fill of the packages and explains the huge overhead on low bitrate files with high frame count)
2nd part depends on the rawSize of the video and the average fill of the package and easily overtakes the frameOverhead when for larger rawFileSize

[jpsdr]

As i said, i've get the 1/23 ratio making differences, so, even on small file, the 1/23 should appear somewhere.
For exemple : (1) and (5) have exact same audio.
h : global header = m2ts-videosize-audiosize
h1=278286018, h5=413261619, h5-h1=134975601, video3-video1=3104632719, 3104632719/134975601=23.0014
Idem for (2) and (6).
h2=225322715, h6=335358385, h6-h1=110035670, video4-video2=2531521834, 2531521834/110035670=23.0064
These results make me think (but maybe wrongly) that, in the formula of the video header, there is something very very near to size/23.
At least, doing this, all offsets or things linked only to number of frames are removed. Stay only bitrate/size related data, as in both exemples for m2ts [1,5] or [2,6] :
Time is the same, frames are the same, audio is exactly the same, only bitrate/videosize change.

[Selur]

here are some numbers I just collected (encoding elephants dream):

raw Video 45496754 bytes 15910 frames
raw Audio: 35562240 bytes
muxedAV: 89972736 bytes ->totalOverhead: 8913742
muxedAudio: 40642560 bytes ->audioOverhead: 5080320
muxedVideo: 51357696 bytes ->videoOverhead: 5860942

raw Video 131747982 bytes 15910 frames
raw Audio: 35562240 bytes
muxedAV: 179976192 bytes ->totalOverhead:12665970
muxedVideo: 141367296 bytes ->videoOverhead: 9619314
muxedAudio: 40642560 bytes ->audioOverhead: 5080320


raw Video 61194876 bytes 15910 frames
raw Audio: 35564032 bytes
muxedAV: 106352640 bytes ->totalOverhead: 9593732
muxedVideo: 67737600 bytes ->videoOverhead: 6542724
muxedAudio: 40648704 bytes ->audioOverhead: 5084672


raw Video 86650038 bytes 15910 frames
raw Audio: 10161152 bytes
muxedAV: 106248192 bytes ->totalOverhead: 9437002
muxedVideo: 94310400 bytes ->videoOverhead: 7660362
muxedAudio: 13977600 bytes ->audioOverhead: 3816448



raw Video 16232616 bytes 15910 frames
raw Audio: 10161152 bytes
muxedAV: 32741376 bytes ->totalOverhead: 6347608
muxedVideo: 20797440 bytes ->videoOverhead: 4564824
muxedAudio: 13977600 bytes ->audioOverhead: 3816448

muxed2*AV: 44169216 bytes ->totalOverhead: 7614296
muxed2*A: 25405440 bytes ->audioOverhead: 5083136
videoOverhead: 4564824

total overhead = X*audioOverhead + videoOverhead - (frameCount * 2*packageSize/3)
where packageSize is 192
X = number of audiostreams
audioOverhead = overhead caused when muxing a raw audio stream on it's own
videoOverhead = overhead caused when muxing a raw video stream on it's own
seems to bit okay, 'totalOverhead - x*audiOverhead - videoOverhead' is always around: 2033664
and frameCount * 2*packageSize/3 = 15910 *2 * 192/3 = 2036480

[jpsdr]

Now, just have to figure out audioOverhead and VideoOverhead... :).
I'll soon make test with AC3+THD.

[Selur]

especially the audioOverhead is a mystery ;)
(having in mind, that m2ts allows at least: ac3, true-hd, dts, dts-hd, pcm and mpeg audio with bitrates from 96kbit/s to multiple MBit/s, when looking over to BDs)

for 'higher' datarates:
audioOverhead = (rawSize/packageFill + length + rawSize/length/blocksize)*packageSize - rawSize
seems to be fairly good,...

[jpsdr]

Maybe there is realy as i use actualy : Different formulas for different cases. Only for AC3, and only some bitrate, i'm using 3 different formulas...
New datas :
video5 : 63803 frames @23.976fps encoded at 23703kb : 7847751856 bytes.
video6 : 57925 frames @23.976fps encoded at 23703kb : 7148686802 bytes.
audio5.1 (for video5) : AC3 core encoded @640kb : 212894720 bytes.
audio5.2 (for video5) : THD track : 776107718 bytes.
audio6.1 (for video6) : AC3 core encoded @640kb : 193280000 bytes.
audio6.2 (for video6) : THD track : 759722044 bytes.

M2TS files size :
video5 + audio5.1&audio5.2 : 9686513664 bytes.
video6 + audio6.1&audio6.2 : 8838414336 bytes.

[Selur]

I'm still aiming for the one formula to rule them all ;)

[jpsdr]

Yes, but if muxing rules differs with different audio parameters, formula unfortunately, can't be only one...
But, unfortunately, we don't know the rules...

[Selur]

.. there definitely have to be some strange rules, looking at these numbers:

length = 636,4s

640
raw Audio: 50805760
m2ts Audio: 59701248
audioOverhead: 8895488

576
raw Audio: 45725184
m2ts Audio: 52076544
audioOverhead: 6351360

512
raw Audio: 40644608
m2ts Audio: 48267264
audioOverhead: 7622656

384
raw Audio: 30483456
m2ts Audio: 36839424
audioOverhead: 6355968

320
raw Audio: 25402880
m2ts Audio: 33024000
audioOverhead: 7621120

256
raw Audio: 20322304
m2ts Audio: 25405440
audioOverhead: 5083136

224
raw Audio: 17782016
m2ts Audio: 21596160
audioOverhead: 3814144

192
raw Audio: 15241728
m2ts Audio: 21596160
audioOverhead: 6354432

160
raw Audio: 12701440
m2ts Audio: 17786880
audioOverhead: 5085440

128
raw Audio: 10161152
m2ts Audio: 13977600
audioOverhead: 3816448

112
raw Audio: 8891008
m2ts Audio: 13977600
audioOverhead: 5086592

96
raw Audio: 7620864
m2ts Audio: 13977600
audioOverhead: 6356736

80
raw Audio: 6350720
m2ts Audio: 10162176
audioOverhead: 3811456

64
raw Audio: 5080576
m2ts Audio: 10162176
audioOverhead: 5081600

56
raw Audio: 4445504
m2ts Audio: 10162176
audioOverhead: 5716672

48
raw Audio: 3810432
m2ts Audio: 10162176
audioOverhead: 6351744

40
raw Audio: 3175360
m2ts Audio: 6352896
audioOverhead: 3177536

32
raw Audio: 2540288
m2ts Audio: 6352896
audioOverhead: 3812608

Cu Selur

[jpsdr]

And it's only for AC3...
Edit : What is the number of frames ? Or the framerate of the audio ?
When authoring Blu-Ray, you have to specify on the audio what framerate it has.

[Selur]

Looking at m2tsVideoSize, rawAudio, length I think I found a decently working formula for the audio overhead. :)
double packageSize = 192.0;
//ac3FrameSize = (averageBitrate in Byte/s)*4
int ac3FrameSize = int(rawSize/length+0.5)*4;
//number of packages needed per ac3Frame
int packagesPerAc3Frame = ac3FrameSize/packageSize+0.5;
//number of ac3 Frames needed for the audio
qint64 ac3FrameCount = rawSize/ac3FrameSize +0.5;
//NO CLUE ;) just fits
int unknownMult = 21;
//m2ts packages needed for the stream
qint64 packageCount = ac3FrameCount*packagesPerAc3Frame + length*unknownMult;
//m2ts audioOverhead
qint64 audioOverhead = packageCount*packageSize - rawSize;

+ audioOverhead -= frameCount * 2.0 * packageSize / 3.0; //if video muxing with video;

Aside from the 'unknownMult' I'm quite happy with the formula, since it seems kind of logic. :)

Cu Selur

Ps.: just wondering: is anyone besides jpsdr and me reading this thread?

PPs.: if someone owns a dts encoder it would be nice if he could encode the elephantsdream audiotrack with multiple bitrate and a. upload these files somewhere or b. mux each of these files using tsMuxer and post raw audio size, muxed audio size and length of the files.

[Zathor]

Ps.: just wondering: is anyone besides jpsdr and me reading this thread?
Yes, I read it with interest. As discussed in the PMs I am looking forward to replace the calculation in MeGUI with this one. I have already added the first calculation of this thread and replaced the totaly strange old calculation of MeGUI. Once again thank you very much!

[jpsdr]

More THD datas.

Video5 : 63804 frames @23.976fps raw h264 encoded (x264) at around 23703kb. .264 file size : 7847751856 bytes.
Video6 : 57925 frames @23.976fps raw h264 encoded (x264) at around 23703kb. .264 file size : 7148686802 bytes.
Audio 5.0 (for video 5) : THD. File size : 776107718 bytes.
Audio 5.1 (for video 5) : AC3 encoded at 640kb. AC3 file size : 212894720 bytes.
Audio 5.2 (for video 5) : AC3 encoded at 448kb. AC3 file size : 149026304 bytes.
Audio 5.3 (for video 5) : AC3 encoded at 256kb. AC3 file size : 85157888 bytes.
Audio 6.0 (for video 6) : THD. File size : 759722044 bytes.
Audio 6.1 (for video 6) : AC3 encoded at 640kb. AC3 file size : 193280000 bytes.
Audio 6.2 (for video 6) : AC3 encoded at 448kb. AC3 file size : 135296000 bytes.
Audio 6.3 (for video 6) : AC3 encoded at 256kb. AC3 file size : 77312000 bytes.

M2TS files :
(27) : Video5 + audio5.0&5.1 => 9686513664 bytes.
(28) : Video5 + audio5.0&5.2 => 9606678528 bytes.
(29) : Video5 + audio5.0&5.3 => 9542811648 bytes.
(30) : Video6 + audio6.0&6.1 => 8838414336 bytes.
(31) : Video6 + audio6.0&6.2 => 8765933568 bytes.
(32) : Video6 + audio6.0&6.3 => 8707952640 bytes.
(33) : Video5 + audio5.0&5.1 + audio5.1 => 9926019072 bytes.
(34) : Video5 + audio5.0&5.1 + audio5.2 => 9846183936 bytes.
(35) : Video6 + audio6.0&6.1 + audio6.1 => 9055856640 bytes.
(36) : Video6 + audio6.0&6.1 + audio6.2 => 8983375872 bytes.
(37) : Video5 + audio5.0&5.2 + audio5.2 => 9766348800 bytes.
(38) : Video6 + audio6.0&6.2 + audio6.2 => 8910895104 bytes.

@Selur : I'll try your new formula.
When you said :
+ audioOverhead -= frameCount * 2.0 * packageSize / 3.0
"+ audioOverhead -"... do you mean, that, after your 1rst calcul, you must do :
audioOverhead -= frameCount * 2.0 * packageSize / 3.0