How compute m2ts result files size ?

[jpsdr]

@Selur : What the status of information/formulas of DTS-HD MA 2.0 ? If i remember properly, you had several sources and "lot" of information with DTS-HD MA 5.1, but few of 2.0. You made a google excel somewhere, no ?

[Selur]

Status hasn't changed since I gave up on it. I really don't have much samples or data to start with,..

https://docs.google.com/spreadsheet/...hl=en_US#gid=0
and
https://docs.google.com/spreadsheet/...hl=en_US#gid=0

were this I did 1/2 a year ago, but the formulas there are far from being usable,...

Cu Selur

[jpsdr]

If i remember correctly, you have relatively good working formula for DTS-HD MA 5.1 (because you have a lot of datas), but unfortunately, only one data of 2.0, and formula is not as good with it, but with only one data, it's normal. I can provide you at least another data of 2.0 stream, of about 1h30, wich will provide you 2 packs of data with different duration. So :
1 : Do you think this can help you to improve/tune formulas for DTS-HD MA 2.0 ?
2 : Are you still interested in trying to improve it ?

Your formula in post 141 gives good result with 5.1 and 7.1 according the Excel sheet, at this point, without the specific blu-ray spec, i don't think improvement can be made. But, maybe with a little more datas, improvement can be made on 2.0.

[QBhd]

Sorry for bringing up an old topic, but it's long over due for MeGUI's bitrate calculator to be fixed. I just recently did an encode after a very long time and decided to try the BC in MeGUI one more time since it's been many updates since the last time I used it... After muxing to Blu-Ray structure (ie. m2ts) it came up 102% in Imgburn... argh! Still not fixed... so I pulled up my calculations (I used to do BD5's and BD9's) and attempted it for my first BD25 encode. Result was 99.25%. So I searched for this topic and thought I would share my results in the hopes this can be fixed.

I break things down into 3 overheads (o/h) in kbps: Video, Audio and Blu-Ray structure. I didn't take the approach of an o/h as a size, but instead looked at it as a rate. We know what the capacity of a disc is, and as such the maximum bitrate it can hold for a given movie; and we know the bitrate of the audio... calculating the video bitrate should follow pretty easily. Since we are trying to calculate a bitrate to encode at, it made sense to do it this way.

First step is easy.... Blu-Ray folders always have the same size when using tsMuxer: 655,360 B so that o/h is simple.

To find the Video o/h, I would just mux the encoded video in an m2ts from RAW and compare the RAW vs m2ts file size and when plotted as bitrates this is what we get:



As you can see, Video o/h is a perfect line.

Next up is Audio o/h... I would go back to tsMuxer add the Audio and then mux again. By taking the resulting m2ts and subtracting the audio, video and video o/h, we get the audio o/h. Again, I looked at this as a bitrate and a few things became very clear. DTS is easy:



That's an average value of 220.58 kbps... a fixed o/h for a fixed bitrate.

For DTS-HDMA it's a little different since the bitrate of the audio file is not fixed like DTS and as such the o/h is not fixed either. And here are those results:



Again we see a very clear equation emerge. Armed with these 3 equations for o/h (Video, DTS and DTS-HDMA) it is not very difficult to come up with a calculated video bitrate.

After I started this posted I realized a few things. One, I was using the "Size on Disk" values for most (if not all) of the size (B) values... and that is not correct.

Secondly, I have a large collection of video files I can pull apart and remux to get an even better set of data points for all kinds of differing audio formats and configurations. I had just been collecting data as I encoded things, but I may do a few daily and re-do my spread sheet with more data and proper sizes recorded.

And finally, I realized that subs too must have an o/h, and even though they take up a small % of the file size, it may be a good idea to investigate this further too.

I hope this helps to get the MeGUI bitrate calculator fixed

QB

[Emulgator]

Before tsMuxeR 2.0.8b rhythm of insertion of PAT/PMT packs was as follows: (PAT/PMT/SIT: every 285ms).

From tsMuxeR 2.0.8b on the rhythm of insertion of PAT/PMT packs happened more often (PAT/PMT/SIT: every 94ms)

I fixed several errors and warnings in version 2.x.x due to BDROM standart (I checked it using bdrom validation software).
One of recomendation - repeat PAT/PMT data every 100ms or faster. So, I increased PAT/PMT rate.

http://forum.doom9.org/showthread.php?t=168539&page=29

From tsMuxeR 2.1.6b on mux overhead has been reduced again.

I think it would be great if you could adjust PAT/PMT/SIT rates to these numbers (94ms for PAT/PMT and 900 ms for SIT).
Advantages:
- more matching with original Blu-Ray transport stream.
- less overhead.

http://forum.doom9.org/showthread.php?t=168539&page=31

So overhead results will differ with muxer versions.

[QBhd]

Indeed... but MeGUI still uses 1.10.6 and as such it's the calculator that is broken and should be fixed and I thought this was the thread that was going to be used to help fix it... if I am wrong I apologize.

QB

[hello_hello]

MeGUI is using tsmuxer version 2.6.11 here. I've no idea how that version effects the accuracy of the bitrate calculator (I never use it myself) but maybe try switching to the development update server and updating whatever needs it. I've been running the latest MeGUI version (2460) since it hit the development update server without any problems.

Then again, the bitrate calculator wiki page has this to say:
http://mewiki.project357.com/wiki/Me...ate_Calculator
Note: The M2TS calculation is a WIP. Also, the quality estimate may require further refinement.

[Selur]

Since the current m2ts calculation code is based on the code I came up with for Hybrid back when this thread was active before, I could share my current m2ts methods (which I use in Hybrid nowadys) with the MeGui devs if they are interested.
I adjusted my old code after the new tsMuxeR version appeared.
Difference between this code and the old code isn't really much, so adjusting the m2ts size calculation in MeGui shouldn't be hard.


Problems of my code:
a. 2.0 DTS-MA overhead estimation could be better (didn't have much data to adjust it)
b. true-hd overhead calculation is a WILD GUESS and as much off as before
c. formulas are mainly data driven and their main goal is to make sure the calculated overhead is always larger than the actual occurring one so that the resulting file size will not exceed the target size -> they don't try be too accurate since accurate calculations would require to know the actual frame sized of the audio&video frames
d. subtitle and structure sizes are simply used as fixed sizes since I never did any testing in how much overhead they really create
e. no clue if the video overhead is still correct for 3D content, since I don't have any data about 3d content
f. formula is ment for 2pass encoding (since only then does file size estimation make any sense; at least for me)
g. code isn't really documented, but since I use decent variable names the code should be easy to read an follow and quite similar to MeGuis current code

Cu Selur

[jpsdr]

Originally Posted by Selur

Problems of my code:
a. 2.0 DTS-MA overhead estimation could be better (didn't have much data to adjust it)

You never answer to my post #203, where i offered datas. Of course, i didn't have them anymore...

Originally Posted by Selur

d. subtitle and structure sizes are simply used as fixed sizes since I never did any testing in how much overhead they really create

For .pes file in Scenarist my results show around 15%.

[Selur]

@jpsdr: that was due to a problem with the board where I didn't get any email notifications (also I would need the data of multiple sources)

For .pes file in Scenarist my results show around 15%.

That doesn't really help with tsMuxeR

[Sharc]

Has anyone tried / compared with this calculator?
It claims to be fairly accurate. Not sure if it's still maintained for new tsMuxeR....

[Selur]

Nope, never heard of it till now.
-> if someone tests it would be nice if he would report