Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
27th August 2006, 18:53 | #1 | Link |
clueless n00b
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
|
overhead of vobsub subs inside mp4/mkv
Does anybody have any reliable data / formulas on the mux overhead of this scenario?
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org |
27th August 2006, 19:34 | #2 | Link |
Registered User
Join Date: Feb 2006
Posts: 823
|
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. |
27th August 2006, 19:55 | #3 | Link |
clueless n00b
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
|
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.
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org |
27th August 2006, 20:04 | #4 | Link |
Registered User
Join Date: Feb 2006
Posts: 133
|
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. Last edited by emmel; 27th August 2006 at 21:31. |
27th August 2006, 20:12 | #5 | Link | |
Registered User
Join Date: Feb 2006
Posts: 823
|
Quote:
|
|
29th August 2006, 17:16 | #7 | Link |
clueless n00b
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
|
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.
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org |
31st August 2006, 19:46 | #9 | Link | |
easily bamboozled user
Join Date: Sep 2002
Location: Atlanta
Posts: 373
|
Quote:
|
|
31st August 2006, 20:32 | #10 | Link | |
clueless n00b
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
|
Quote:
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org |
|
3rd September 2006, 03:14 | #11 | Link | |
easily bamboozled user
Join Date: Sep 2002
Location: Atlanta
Posts: 373
|
Quote:
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. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|