How compute m2ts result files size ?

[Selur]

More THD datas.
Nice ! :)

do you mean, that, after your 1rst calcul, you must do :
This should come after the audio overhead of all the audiostreams is calculated.
So first calculate and sum up all the audio overheads, then lower them by 'frameCount * 2.0 * packageSize / 3.0'.

Cu Selur

[drmpeg]

The m2ts overhead for AC3 audio can be calculated like so:

audio packet size (in bytes) = bitrate (in bps) / 250.

The PES overhead is always 17 bytes.

So for 640 kbps AC3, the PES packet is 2577 bytes.

Each Transport Stream packet can hold 184 bytes. 2577 / 184 = 14.00543478

But you can't have fractional TS packets, so it takes 15 packets to send the audio frame (with the last packet having 181 stuffing bytes).

192 * 15 = 2880

So the m2ts overhead for 640 kbps AC3 audio is 2880 / 2560.

Ron

[jpsdr]

@drmpeg
Thanks for this information.
Is what you've explained for m2ts with audio+video ?
Is it always the same, even with more than one audio track (only AC3 tracks for now).

I like it, it explains the identical final result 96/128 kb , as 96 give around 2.2 and 128 give around 2.8, but both finaly result in 3x192, so padding is more important for 96 than 128.

[drmpeg]

@drmpeg
Thanks for this information.
Is what you've explained for m2ts with audio+video ?
Is it always the same, even with more than one audio track (only AC3 tracks for now).
Yes, the video stream doesn't have any effect on the audio stream(s) and vice versa. Also, the number of audio tracks does not have an effect.

Ron

[jpsdr]

Wonderfull, we are near something.
Using your formulas to substract total audio from (1), (2), (5) and (6) m2ts files i've created, i've the following exact result :
Total video for (1) = 24978738*192
Total video for (5) = 41851698*192
Total video for (2) = 20220382*192
Total video for (6) = 33978494*192
So, formula for total video may have a similar rule...

Don't know exactly the right english word, but bigger common divider for [(1) and (2)] or [(5) and (6)] : Different videos with bitrate mostly identicall (=> in theory would result in same package size using something similar to audio) is only 2.

[nixo]

Very cool!

I guess I'll never encode another 192kbps AC3 file for BD since 224kbps files will mux to the exact same size. :-)

The question is how to deal with different muxers; it's my understanding that output from TSMuxer is not identical in size to that of Scenarist or some other professional muxer.

--
Nikolaj

[jpsdr]

Warning : All my results are from Scenarist.

[jpsdr]

If video follow the same kind of rule than audio, but with bitrate wich is the "local" bitrate, it will never be possible to get the exact size of the total video...

Considering 2 is bigger common divider. My computations shows video header is around size/23.
Like audio, video is something like M0/N ratio, both intergers. M0=M*192.
So... (192*M)/N=1+1/23 => 23*192*M=24*N => 184*M=N.
184, 192, i dont know you, but i love these numbers.... If we chose M=2 (bigger common divider), we have N=368.=> Video would be 192/184... But, it doesn't match experimental datas.... Too bad...
......... Or.... there is something else...
Total m2ts = Audio according drmpeg data + 192/184videosize + TBD
TBD can be frame related, or length or... If i adjust result from post #55 considering video is 192/184.
It leave for :
(1) : 293030*192
(2) : 237447*192
(5) : 292986*192
(6) : 237288*192
.... Very very near to frames*2 !!!
I think, m2ts is :
Audio : acording drmpeg
Video : trunc((videosize/184)+1)*192
m2ts = audio+video+frames*2*192.
At least, for AC3 audio.
And one thing seems for sure : 192 & 184 rules !

[jpsdr]

Others results, for checking :
(39) : Video5 + audio5.2 => 8373024768 bytes.
(40) : Video6 + audio6.2 => 7626620928 bytes.

[jpsdr]

My formula for video is not correct, don't work with high bitrate...

[jpsdr]

Madshi, Neuron2, any x264 developper !!!!
If you read this, maybe you can help us.
Note : If for video it's tricky, assume video is constant bitrate...
:thanks:

[jpsdr]

Still some little something. If i take datas from post #14, results (1) and (3), exact same video, different audios.
For (1), i found muxed video is 24978738 packet (of 192), for (3) i found 24978745.
Others results, using data from post #14 also give me 24978745 a second time, and 24978756 another time...
Difference is short, but even an error of 1, make impossible to try to correlate datas trying to find things like bigger common divider...

[drmpeg]

The m2ts overhead for video cannot be precisely calculated. However, you can calculate a worst case.

PES overhead is 14 bytes for B-Frames and 19 bytes for I and P-frames.

The worst case stuffing for the last packet of a PES packet is 183 bytes.

For an IBBP video GOP, the equation would be:

max bytes total = ((number of frames in video elementary stream * (15.666 + 183)) + (bytes in video elementary stream)) * 192 / 184

A good estimate can be made by assuming that the last packet stuffing averages out to 183/2 bytes.

estimated bytes total = ((number of frames in video elementary stream * (15.666 + (183/2))) + (bytes in video elementary stream)) * 192 / 184

Ron

[jpsdr]

Thanks. I'm happy to find out that somehow, my 192/184 wasn't wrong in a way. But your formula is for the total size, not only the overhead, no ?
15.666 is a true constant, or related to framerate ?
If you have any others informations about others streams, like others audio format or subtitles (for wich input data would be the .pes file created by scenarist), we gladly take them.
Again,:thanks:

[drmpeg]

Thanks. I'm happy to find out that somehow, my 192/184 wasn't wrong in a way. But your formula is for the total size, not only the overhead, no ?
The 15.666 is a true constant, or is it related to framerate also ?
If you have any others informations about others streams, like others audio format or subtitles (for wich input data would be the .pes file created by scenarist), we gladly take them.
Again,:thanks:
Yes, the total size. I'll edit the post to show that. 15.666 is the PES overhead for an IBBP GOP. (19 + 14 + 14) / 3.

Ron

[jpsdr]

Thanks allready, your help have been realy very greatfull.
So, do you have by any chance informations about others streams ????:rolleyes:

[jpsdr]

Do you have any idea, with these encoding parameters, what will my structure be ?

x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.8 --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%


As i've put bframes to 3, i though it would be IBBBP...
So more to 15.25 ?

[Selur]

I'm still confused about the audio overhead calculation.
Here's how I interpreted the post from drmpeg:

> The m2ts overhead for AC3 audio can be calculated like so:
HAR, HAR,.. here we go :)

> audio packet size (in bytes) = bitrate (in bps) / 250.
int averageBitrate = int(rawSize/length+0,5)*8; //got length and rawSize as input i.e. 640000
int audioPackageSizePerSecond = int(averageBitrate/250+0.5); //+0.5 to round up; i.e. 2560

>The PES overhead is always 17 bytes.
> So for 640 kbps AC3, the PES packet is 2577 bytes.
int effectiveAudioPackagePerSecond = audioPackageSizePerSecond+17; //+17 due to PES overhead //i.e. int(640000/250+0.5)+ 17 = 2560 +17 = 2577

> Each Transport Stream packet can hold 184 bytes.
double packageFill = 184.0;

> 2577 / 184 = 14.00543478
> But you can't have fractional TS packets, so it takes 15 packets to send the audio frame (with the last packet having 181 stuffing bytes).
int containerPackagesCountPerAudioPackagePerSecond = effectiveAudioPackagePerSecond/containerPackageFill+0.5; //+0.5 to round up; i.e. 2577/184 +1 = 14,005434782608695652173913043478 -> 15

> 192 * 15 = 2880
int containerPackageSizePerAudioPackagePerSecond = containerPackageSize * containerPackagesCountPerAudioPackagePerSecond; //192*15 = 2880

So the m2ts overhead for 640 kbps AC3 audio is 2880 / 2560.
and here I'm uncertain, what this really means.
I assumed, that '2880 / 2560' is a factor to multiply the raw size to get the effective m2ts output size and when subtracting the raw size I should end up with the audio overhead, which would give me:
qint64 audioOverhead = rawSize * containerPackageSizePerAudioPackagePerSecond / audioPackageSizePerSecond - rawSize;

looking at this source (http://www.multiupload.com/46MDJLGCC0):

length: 636.4s
raw audio: 3175360
m2ts audio: 6352896
audioOverhead: 3177536
(which you get if you take the audio stream of elephants dream, downmix it to stereo with sox, reencode it with acid aiming for 32bit/s ac3 and multiplex it with tsMuxeR)

I get:
averageBitrate = int(3175360/636.4+0.5) * 8 = 4990 *8 = 39920
audioPackageSizePerSecond = int(39920/250+0.5) = 160
effectiveAudioPackagePerSecond = 160 + 17 = 177
containerPackagesCountPerAudioPackagePerSecond = int(177/184+0.5) = 1;
containerPackageSizePerAudioPackagePerSecond = 192*1 = 192;
audioOverhead = 3175360*192/160 - 3175360 = 3810432 - 3175360 = 635072
since this isn't anywhere near the audio overhead the stream actually has, I suspect I made a mistake somewhere and since I can't see the mistake I thought I ask you guys. :)

-----------------------------

As i've put bframes to 3, i though it would be IBBBP...
So more to 15.25 ?
for mkv video overhead I normally assume:
ulong nbIframes = ulong(frameCount/framerate/2+0.5);
ulong nbBframes = 0;
if (bframes) {
nbBframes = ulong(((frameCount - nbIframes)/2)+0.5);
}
ulong nbPframes = frameCount - nbIframes - nbBframes; which at least for mkv works kind of good. :)


Cu Selur

[jpsdr]

I don't know, audio seems to work fine for me with AC3 stream...
If you check all the AC3 file size i provided with their bitrate, calculate the packet size : bitrate/250, and divide their raw size by this packet, you've always an integer result.

[Selur]

and you use the same calculations I do?

[jpsdr]

Yes, but for bitrate i use the value i've encoded with, not computed from size.
For your file : 40000/250 = 160 (encoded at 40kb according post in previous page).
3175360/160=19846
(160+17)/184=0.9 => 1 => Total audio size = 3810432.
Now, maybe m2ts audio only have something else within them...
I've been able to check and verify it using the datas i've provided, calculating differences and all, it's the formula for audio. You have 13242 packets (of 192) of something else.
For B frame, i think "typical" pattern could be tell according the encoding parameters i use.

[Selur]

Yes, but for bitrate i use the value i've encoded with, not computed from size.
okay, sad thing is that doesn't change the result. ;)

Now, maybe m2ts audio only have something else within them...
seems like it (hoping drmpeg can shed some light on this)

You have 13242 packets (of 192) of something else.
since I use tsMuxeR and tsMuxer adds them I probably have to look for a solution myself :(

[jpsdr]

I just remember that i'm doing encoding for now....
According x264 logs, i've (with a 2s gop on 23.976fps video) around 2.6% of I frames, 28.2% of P frames and 69.2% of I frames.
Wich give me around 15.54.

[Selur]

yup, problem is normally you want to calculate the m2ts file size to adjust your bit rate so you hit a specific target or stay below a specific size, so you need to find a good approximation before you have the x264 stats. ;)

seems like adding an additional int(length*(20+(184-17)/192)+0.5)*192 works fine for tsMuxer, so they add two additional packages per second

[jpsdr]

Yeah.... Doom9 is back !!!
I've found something aroud 1.435*frames*192 added.

[Selur]

Did any one find out how to compute the audio overhead for dts(-hd) audio inside m2ts?

the following doesn't seem too far off:
int DTSFrameCount = length*1000/10.67+1; //rounded down and length in seconds
int frameSize = 2013;
int packagesPerFrame = frameSize/packageFill+1; //rounded down
int packageCount = DTSFrameCount*packagesPerFrame;
int averageBitrate = rawSize/length+1;
double mult = 1;
if (averageBitrate > 192000) {
mult = averageBitrate/194000.0;
}
packageCount = packageCount*mult;
int tsMuxerAddition = int(length+1)*(20+167/192);
qint64 audioOverhead = (packageCount + packageCount/184.0/8.0 + tsMuxerAddition)*192 - rawSize; //rawSize in byte

Cu Selur

[jpsdr]

And PackageFill is ???

Personnaly, still found no formula for THD+AC3...

[Selur]

oh, forgot, packageFill is 184
Got no THD+ac3 data,... so I never thought about it :)

[jpsdr]

Euh..... And what about what i've posted here (http://forum.doom9.org/showpost.php?p=1474499&postcount=50) ?

I have some DTS-HD Master audio data, i'll try to see if i can correlate datas with yours, but i don't think it will be before the end of this month.

[Selur]

You posted only the raw sizes
Audio 5.0 (for video 5) : THD. File size : 776107718 bytes.
Audio 6.0 (for video 6) : THD. File size : 759722044 bytes.
and the size muxed with videos of different length. (Video5 : 63804 frames @23.976fps and Video6 : 57925 frames @23.976fps)

But to work on a formula for the audio overhead I need:
1. raw size (got that)
2. length of the audio (don't have that,.. normally audio equals video length,... but not in the cases you provided)
3. the size of a m2ts file with only the audio in it (don't have that)
4. data with different audio length and different bitrates,...

Cu Selur

[jpsdr]

You can't on Scenarist mux stream without video, and, of course, you can't also mux THD stream without an AC3 core, both are not Blu-Ray compliant.
Length is defined by the associated video, so, here length of audio is video. Why do you think it's not the case here ?
If there is different muxes with different stream, it's to be able to work by differences.
Doing :
[video 5 + audio5.1 + (audio5.0+audio5.1)] - [video 5 + audio 5.1] resulted in 7672704 packet of 192 byte (so size 7672704*192) for (audio5.0+audio5.1).
[video 6 + audio6.1 + (audio6.0+audio6.1)] - [video 6 + audio 6.1] resulted in 7066432 packet of 192 byte (so size 7066432*192) for (audio6.0+audio6.1).
THD is a lossless compression pattern by Dolby. It means there is no bitrate, at least, in the way like "encode with bitrate X".

[Selur]

You can't on Scenarist mux stream without video,...
Since I'm not using Scenarist I'm not bound to this restriction. :)

Length is defined by the associated video, so, here length of audio is video. Why do you think it's not the case here ?
I hope Scenarist then prevents you from muxing audio&video is their length doesn't match up. (otherwise predicting the overhead is probably more complicated)

THD is a lossless compression pattern by Dolby. It means there is no bitrate, at least, in the way like "encode with bitrate X".
Yes, but the THD information does account for content that need to be muxed in the container and as such will cause a container overhead.

Cu Selur

[jpsdr]

Since I'm not using Scenarist I'm not bound to this restriction. :)

As all my data are Blu-Ray compliant, and don't see the point to try to get data from non compliant Blu-Ray things, unless you're not trying to do only Blu-Ray compliant structure.
In that case, it's different.


I hope Scenarist then prevents you from muxing audio&video is their length doesn't match up. (otherwise predicting the overhead is probably more complicated)

If Blu-Ray standard allow you to do that, it will not prevent it. What it prevents is different framerates. You can't mux a 23.976fps audio with a 24fps video. For information, when you import an audiofile, you have to define his framerate.


Yes, but the THD information does account for content that need to be muxed in the container and as such will cause a container overhead.
I don't realy understand what you mean by that. My THD files come from a Blu-Ray i've bought, extracted with eac3to.

I've personnaly try to figure out things, but i've not been able to figure out any formula pattern.
Now, i've provided datas of 2 differents lenght files, and i've unfortunately nothing more to provide. You're absolutely free to try, if you want, to figure out things. The hard part is that i've no idea how the steam is seen. As one big file ? As 2 files ?

[Selur]

1. I really don't care about the Blu-ray Standard, when trying to find a formula to calculate the overhead caused by muxing something into a m2ts container.
2. Sorry, but the data sets you provided don't help me. :)

For information, when you import an audiofile, you have to define his framerate.
Okay, and here you lost me audio doesn't have a frame rate it has a length, it might be synchronized against a video with a specific frame rate but that doesn't change the audio.

My THD files come from a Blu-Ray i've bought, extracted with eac3to.
good, and if you would multiplex the audio with tsMuxeR and post
a. the raw file size (byte)
b. the muxed file size (byte)
c. the length of the clip (seconds)
I would have some data I could use. :)

Cu Selur

[jpsdr]

Okay, and here you lost me audio doesn't have a frame rate it has a length, it might be synchronized against a video with a specific frame rate but that doesn't change the audio.

I know... But it works like this.


good, and if you would multiplex the audio with tsMuxeR and post
a. the raw file size (byte)
b. the muxed file size (byte)
c. the length of the clip (seconds)
I would have some data I could use. :)

Can you with tsMuxer said that you want to create a THD with AC3 core audio track, and so give to it the THD and AC3 files ?

[Selur]

Can you with tsMuxer said that you want to create a THD with AC3 core audio track, and so give to it the THD and AC3 files ?
Sorry, but I can't make head or tails of this sentence. :)
with tsMuxeR you can extract/mux a 'THD with AC3 core'-audio track from/into a m2ts container.

Cu Selur

[jpsdr]

Ok. But i've just remember that i've deleted the files, so, i must re-rip my Blu-Ray... :(
I'll do this when i'll go time, either this week or next.

[jpsdr]

with tsMuxeR you can extract/mux a 'THD with AC3 core'-audio track from/into a m2ts container.

How do you do that ?
I've TSmuxerGui 1.10.6, and i can only open AC3
files with the ADD button, and my THD track is not recognized even if y choose "*.*" files to open it...

[Selur]

if I give it a .ac3 extension it worked last time I tried. :)

[jpsdr]

I must specify one thing : I've 2 files : the ac3 and the "pure" thd (file1.ac3 and file2.thd) extracted with eac3to. So, you said that if i rename the .thd in .ac3 it will work ? I've some doubts, but i'll try this evening when back home...
Problem is that in TSMuxuerGui, i've not found any "THD with AC3 core" option, so...

[Selur]

Nope, no clue how to handle files where THD and core are separated. When I use tsMuxer for extraction, THD&ac3 is one file.

Cu Selur

[jpsdr]

Well, in that case, it's a dead end, and the only thing avaible are the data i've already provided.
You posted only the raw sizes
Audio 5.0 (for video 5) : THD. File size : 776107718 bytes.
Audio 6.0 (for video 6) : THD. File size : 759722044 bytes.
and the size muxed with videos of different length. (Video5 : 63804 frames @23.976fps and Video6 : 57925 frames @23.976fps)

But to work on a formula for the audio overhead I need:
1. raw size (got that)
2. length of the audio (don't have that,.. normally audio equals video length,... but not in the cases you provided)
3. the size of a m2ts file with only the audio in it (don't have that)
4. data with different audio length and different bitrates,...
Cu Selur

1. : You have the size of both the THD and AC3 files used to create the "THD with AC3 core" track (and for the 2 results). A big AC3+THD file name .ac3 is not relevant, as it's somehow something already partialy muxed.
2. : You have, audio length IS video length in what i've provided.
3. : in post #81 (http://forum.doom9.org/showpost.php?p=1478068&postcount=81) you have the result size of the mux. It's the result of the AC3 and THD (THD with AC3 core).
4. The 2 files have different lenght.

From my point of view, there is all the data.

I will nevertheless, out of curiosity, try to extract with tsmuxer to see what size is the .ac3 result file containing both AC3 and THD.
It may not be a great help, because, for exemple for video5, either file in size is (audio5.0+audio5.1), data we already have, either it's different, in that case it means that it's partialy muxed.
Note : Maybe there is a 2 stage mux. First, muxing of THD+AC3, second muxing this result in the m2ts. I don't know.

[Selur]

merely for amusement:

looking at:
video5 : 63803 frames @23.976fps encoded at 23703kb : 7847751856 bytes.
video6 : 57925 frames @23.976fps encoded at 23703kb : 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.
[video 5 + audio5.1 + (audio5.0+audio5.1)] - [video 5 + audio 5.1] resulted in 7672704 packet of 192 byte (so size 7672704*192) for (audio5.0+audio5.1).
[video 6 + audio6.1 + (audio6.0+audio6.1)] - [video 6 + audio 6.1] resulted in 7066432 packet of 192 byte (so size 7066432*192) for (audio6.0+audio6.1). I end up with:

audio5.0+audio5.1:
length = 63803/23.976 = 2661.12 (s)
raw size = 776107718 + 212894720 = 989002438 (byte)
muxed size = 7672704*192 = 1473159168 (byte)
-> overhead = 1473159168 - 989002438 = 484156730 (O1)

audio6.0+audio6.1:
length = 57925/23.976 = 2415.958 (s)
raw size = 759722044 + 193280000 = 953002044 (byte)
muxed size = 7066432*192 = 1356754944 (byte)
-> overhead = 1356754944 - 953002044 = 403752900; (O2)

side note: woooha! 40%+ overhead,.. disc manufacturer must really love this container!
Don't want to know what would happen to the overhead if the length would increase and the average bitrate would shrink,...
+ hope there's no typo somewhere

1st trying the old formula (ment for .ac3 only) to get a perspective how bad the THD stuff is,...
double length = frameCount/frameRate;
int packageSize = 192;
qint64 audioOverhead = 0;
double packageFill = 184.0;
int averageBitrate = int(rawSize/length+1)*8;
int audioPackageSizePerSecond = averageBitrate/250+1;
int pesOverhead = 17;
int effectiveAudioPackagePerSecond = audioPackageSizePerSecond+pesOverhead; //+17 due to PES overhead
int containerPackagesCountPerAudioPackagePerSecond = effectiveAudioPackagePerSecond/packageFill+1;
int containerPackageSizePerAudioPackagePerSecond = packageSize * containerPackagesCountPerAudioPackagePerSecond;
audioOverhead = rawSize * containerPackageSizePerAudioPackagePerSecond / audioPackageSizePerSecond - rawSize;


looking at audio5.0+audio5.1
int averageBitrate = int(989002438/2661.12+1)*8 = 371649 *8 = 2973192 (bit/s)
int audioPackageSizePerSecond = 2973192/250+1 = 11893 (packages/s)
int pesOverhead = 17;
int effectiveAudioPackagePerSecond = 11893+17 = 11910 (packages/s)
int containerPackagesCountPerAudioPackagePerSecond = 11910/184+1 = 65
int containerPackageSizePerAudioPackagePerSecond = 192 * 65 = 12480
audioOverhead = 989002438 * (12480 / 11893) - 989002438 = 48813961 byte (C1)
compared to O1 (484156730) C1 (48813961) is a bit small (being 1/10 of the actual overhead -> THD really is evil overhead wise)

stupid approach: :D
484156730/48813961 = 9.9184069491922607960456230954091;
averageBitrate / 640 000 = 2973192/640000 = 4.6456125
magicMult = 9.9184069491922607960456230954091/4.6456125 = 2,14
audioOverhead = (989002438 * (12480 / 11893) - 989002438)*2,14*4,6456125 = 485289394 (C1s)
C1s (485289394) compared to O1 (484156730) is now okay (meaning: < 1MB derivation and calculated overhead > actualoverhead)


looking at audio6.0+audio6.1:
int averageBitrate = int(953002044/2415.958+1)*8 = 394462 *8 = 3155696 (bit/s)
int audioPackageSizePerSecond = 3155696/250+1 = 12632 (packages/s)
int pesOverhead = 17;
int effectiveAudioPackagePerSecond = 12632+17 = 12649 (packages/s)
int containerPackagesCountPerAudioPackagePerSecond = 12649/184+1 = 69
int containerPackageSizePerAudioPackagePerSecond = 192 * 69 = 13248
audioOverhead = (953002044 * (13248 / 12632) - 953002044 ) * 2,14 * (3155696 / 640 000) = 490378461(C2s)
-> C2s (490378461) is larger than O2 (403752900)

-> no surprise, stupid idea bad result :)


another stupid approach:
looking at audio5.0+audio5.1
code]double length = frameCount/frameRate;
int packageSize = 192;
qint64 audioOverhead = 0;
double packageFill = 184.0;
int averageBitrate = int(rawSize/length+1)*8;
int additionalBitrate = 0;
int additionalRawSize = 0;
if (averageBitrate > 650 000) {
int newSize = 640000/8*length;
averageBitrate = 640000;
additionalRawSize = rawSize - newSize;
additionalBitrate = int(additionalRawSize/length+1)*8;
rawSize = newSize;
}
int audioPackageSizePerSecond = averageBitrate/250+1;
int pesOverhead = 17;
int effectiveAudioPackagePerSecond = audioPackageSizePerSecond+pesOverhead; //+17 due to PES overhead
int containerPackagesCountPerAudioPackagePerSecond = effectiveAudioPackagePerSecond/packageFill+1;
int containerPackageSizePerAudioPackagePerSecond = packageSize * containerPackagesCountPerAudioPackagePerSecond;
audioOverhead = rawSize * containerPackageSizePerAudioPackagePerSecond / audioPackageSizePerSecond - rawSize;
audioOverhead += additionalRawSize/1.69; //1.69 being a magic number
[/code]
int averageBitrate = int(989002438/2661.12+1)*8 = 371649 *8 = 2973192 (bit/s)
newSize = 640000/8*2661.12 = 212889600
averageBitrate = 640000;
additionalRawSize = 989002438-212889600 = 776112838
additionalBitrate = 776112838/8*2661.12 = 258166174432
int audioPackageSizePerSecond = 640000/250+1 = 2561 (packages/s)
int pesOverhead = 17;
int effectiveAudioPackagePerSecond = 2561+17 = 2578 (packages/s)
int containerPackagesCountPerAudioPackagePerSecond = 2578/184+1 = 15
int containerPackageSizePerAudioPackagePerSecond = 192 * 15 = 2880
audioOverhead = 212889600 * (2880 / 2561) - 212889600 = 26517682 byte
audioOverhead = 776112838/1,69 + 26517682 = 459238365 + 26517682 = 485756047 (C1s2)

looking at audio6.0+audio6.1:
int averageBitrate = int(953002044/2415,958+1)*8 = 394462 *8 = 3155696 (bit/s)
newSize = 640000/8*2415,958 = 193276640
averageBitrate = 640000;
additionalRawSize = 953002044-193276640 = 759725404
additionalBitrate = 759725404/8*2415.958 = 229433083450
int audioPackageSizePerSecond = 640000/250+1 = 2561 (packages/s)
int pesOverhead = 17;
int effectiveAudioPackagePerSecond = 2561+17 = 2578 (packages/s)
int containerPackagesCountPerAudioPackagePerSecond = 2578/184+1 = 15
int containerPackageSizePerAudioPackagePerSecond = 192 * 15 = 2880
audioOverhead = 193276640 * (2880 / 2578) - 193276640 = 22641406 byte (C1)
audiOverhead += 759725404/1,69 + 22641406 = 472183065 (C2s2)

-> as suspected just another stupid approach :)


For a better approaches we need:
a. more data sets
b. additional infos about THD (Header&Co)

Cu Selur

[jpsdr]

I've tried several approches.
- Considering a whole file (note : When i import in Scenarist AC3+THD, in the Software, it appears like one file of the total size in Dolby Lossless format, but maybe it's just a way of displaying things, and there is nothing more).
- Considering two files, ac3 part encoded like we already know, and the rest in unknow format..., but not being able to find anything relevant...
The only thing i've found for now, it's that the biggest commun dividor within 7672704 and 7066432 is 64. Is it an hazard or is it the begining of something ?
I've not been able to figure out yet.

[Selur]

The only thing i've found for now, it's that the biggest commun dividor within 7672704 and 7066432 is 64.
-> http://britton.disted.camosun.bc.ca/gcdlcm/jbgcdlcm.htm :D

Is it an hazard or is it the begining of something ?
looks like a fluke, don't think it's a indicator for anything,..

Cu Selur

[jpsdr]

I'll try to see this WE if i can make others datas. I'll have to use the same method : working by differences to get the audio track size.
If 64 appears again, it will mean something. But with only 2, it may be a fluke. It there was 3, it would have been another story...

[Selur]

Even if all the files are dividable by 64 it will probably not mean anything that can help with the formula.
More data sets would be nice may be we got lucky and someone knowing a bit about thd stumbles over this thread. :)

[jpsdr]

I've extracted with TSmuxer the audio6.0/6.1, and the result was a big .ac3 file of 953002044 bytes...

[jpsdr]

Is it normal in post #76 (http://forum.doom9.org/showpost.php?p=1477606&postcount=76) that test is made with 192000, and mult calculated with 194000 ?

[Selur]

Nope, they are ment to be switched,...

if (averageBitrate > 194000) { //194000 for tolerance
mult = averageBitrate/192000.0; //192000*8 = 1536k
}