overhead of vobsub subs inside mp4/mkv

[Doom9]

Does anybody have any reliable data / formulas on the mux overhead of this scenario?

[GodofaGap]

You would need to know the amount of subpictures to make any meaningful estimation of that. On the scale of video and audio it is probably negligible. Also remember that by default Matroska (mkvmerge) uses zlib compression for vobsubs which complicates the estimation even more.

IOW - I don't think such a thing is possible. The only thing you could do is create a .mks with the subtitle you have and measure the size of that.

[Doom9]

well.. I'd depart from knowing how large the .idx and .sub file is.. I could even throw the size of a zipped .sub file into the mix.. and I'm not friend of empirical measures in this case.. there are usually formulas that those who came up with the container know about.

[emmel]

Correct me if I'm wrong, but when muxed in mp4, the overhead is actually "negative".

To be more precise, the vobsub-files (*.sub) are first demuxed to get rid of the mpeg2 ps/pes headers and padding, after which the resulting spu's (plus some headers, of course) are placed into the mp4 stream. Practical example:

$ls -la
a.mp4 713322899 bytes
b.idx 56638 bytes
b.sub 4001792 bytes

$ MP4Box -add b.idx a.mp4
$ ls -la a.mp4
a.mp4 715960055 bytes

There is a saving of 1,4M in this case. I'm unable to say whats the size of mp4-header data in general. But it must be small compared to the number of mpeg2 header and padding bytes thrown away.

[edit] Simple formula for average "compression" when importing vobsubs in mp4:

- 53 header bytes / sub are discarded (the average number of pes-packets / sub picture is two. There are 29 header bytes in the first packet, and 24 bytes in the second)

- 1012 padding bytes / sub are discarded (if the length of the sub picture units (modulo pes packet size) is random, approximately half of the 2048-24=2024 data bytes of the last packet carries payload - the rest is subject to padding).

The total compression is thereby about 1k / sub. In the previous example, there were 1250 subs, which gives a total of 1,35M discarded bytes. Close enough to practice, imho.

Maybe it would be more accurate to talk about overhead, if it were possible to mux sup-files into mp4.

[GodofaGap]

well.. I'd depart from knowing how large the .idx and .sub file is.. I could even throw the size of a zipped .sub file into the mix..
If you are willing to do that, I don't see what the problem is with creating a subtitle only mkv first. It will probably give you more accurare result than any formula can.

[Haali]

It's rather hard to predict overhead because the subs themselves are compressed with zlib when stored in matroska. To get accurate sizes you'd need to mux a subs-only file and run mkvverify on it.

[Doom9]

well... I can always use sharpziplib to compress the sub file, and that will give a rather reliable estimate. I'm not so concerned about the compression though, as I know this isn't perfectly reliable.. but I'd like to get an idea of the overhead so that I can at least take proper care of that. Running yet another commandline program is out of the question here.

[Haali]

Overhead should be pretty much the same as for other video codecs, frames are stored in the same way after all.

[Prettz]

well... I can always use sharpziplib to compress the sub file, and that will give a rather reliable estimate. I'm not so concerned about the compression though, as I know this isn't perfectly reliable.. but I'd like to get an idea of the overhead so that I can at least take proper care of that. Running yet another commandline program is out of the question here.
Reliable bitrate calculators are kinda important, though! And since .sub subtitles are pretty big (several MB), that makes a pretty big difference when I'm trying to get my encode exactly 700MB on the first try. After being duped several times now by the bitrate calculator in MeGUI, I'd be willing to wait any amount of time to get a totally accurate bitrate calculation.

[Doom9]

After being duped several times now by the bitrate calculator in MeGUI,Did I miss your several detailed reports ?

[Prettz]

Did I miss your several detailed reports ?
No this just happened a couple days ago. I only just started using MeGUI. But my final .mkv file kept coming out about 2 MB or a little more short of what I expected after muxing my audio.

It might have something to do with how the video hr/min/sec controls and # of frames control change their values a little unexpectedly. And when I entered my actual # of frames, it changed the number of seconds from the correct value to a really wrong one. I could not get both values to be correct at the same time. I don't remember which I left correct, the # of frames or the # of seconds, however. The calculator must have used the value that became incorrect to calculate the video overhead.