 MKV-Overhead |
elestrodix
DER Anleitungsmann ;)
Dabei seit: 17.03.2002
Beiträge: 634
Herkunft: Bonner Raum
 |
|
Hi allerseits!
Habe vor dem Kontainer Ogm lebewohl zusagen und mich mit MKV auseinander zu setzen.
Meine Frage:
Wie berechnet ihr den Overhead?
__________________
OGM-Overhead-Formel?guckst du hier
|
|
24.10.2004 15:10 |
|
|
Videostation
Super Moderator
Dabei seit: 16.03.2002
Beiträge: 1.533
Herkunft: Dresdner Raum
|
|
Eigentlich überhaupt nicht. 
Meine MKV Files sind nach dem muxen stets etwas kleiner als die einzelnen Dateien zusammengenommen. Hab mich aber noch nicht näher damit beschäftigt warum das so ist. Bin einfach damit zufrieden das es so ist. 
CU Videostation
__________________
WWW.VIDEOSTATION-ONLINE.DE
|
|
|
24.10.2004 15:49 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
|
|
| Zitat: |
Overhead of MKV files
If you seriously thought that AVI overhead estimation was difficult, then I have to disappoint you. The obfuscated way Matroska stores element sizes can really cause some headache.
Variable size integer values
Matroska uses variable size integers to indicate the length of an element:
0x81 - 0xFE -> 1 - 127
0x4080 - 0x7FFE -> 128 - 16382
...
That means, the overhead an element, such as a video or audio frame, causes depends on its size!
This system is also used for the element headers, meaning that the ID code of an element can be between 1 and 4 bytes large (longer values, up to 8 bytes, are allowed for element size indicators).
Audio and Video data is stored in 'blocks', where each block contains a stream number (variable size integer!), a 16 bit timestamp (relative to the timestamp of the cluster it is in), and one byte for flags.
Video data
A block is contained in one 'blockgroup', which has again a header element (one byte) and a size indicator (variable size integer). If the block contains a nonkeyframe, there will be one or more reference blocks attached to the block, each of which takes 3 bytes (1 for P-frames, 2 for B-frames).
As a result, the normal overhead per video frame is:
10 bytes for a keyframe
13 bytes for a p-frame
16 bytes for a true b-frame.
If you have frames that are larger than 16382 bytes, you have to add 2 more bytes to that.
One video frame is contained in one block.
Audio data
One or more audio frames are contained in one block.
If you store several audio frames in one block, each audio frame, except for the last one in that block (!), causes 1+(frame size / 255) bytes of extra overhead when using Xiph lacing, but saves the space for another block header and blockgroup.
When using EBML lacing, each frame within a lace, exept for the last one, causes either one or 2 bytes (more would require rediculously high audio frame sizes). Fixed lacing uses a few bytes per lace, independent from the number of frames in lace.
When using fixed lacing (possible for e.g. AC3 and DTS), there is no overhead 'per frame', but only the usual overhead per block.
Subtitles
Subtitles cause 8 - 10 bytes of overhead for each subtitle element, depending on the size of each element.
Clusters
A few seconds of video and audio data are put in one cluster, where usually each cluster is indexed in the metaseek. Assuming that this is the case, each cluster causes 29 bytes of overhead in average. There are 4 more bytes for both PrevClusterSize and Position element, if they are stored (3 if a value is < 2^16 or 5 if it is >= 2^24, meaning that Position usually takes 5 bytes als PrevClusterSize usually takes 4),
However, if the cluster size is 2 MB or more, you need one more byte to store the cluster size.
Cue points
There can be one cue point for each frame, but normally, there is one cue point only for each keyframe, and no cue points for any non-video-tracks. Each cue point takes about 18 or 19 bytes (there are, again, some variable size integers involved), if those conditions are met.
As you can see, an estimation on how much overhead a MKV file will have is based on a lot of hopes and guesses, but will rarely ever be accurate if you don't know details about your source files (such as format, frame size) as well as the muxing settings that will be used. |
siehe: alexnoe's Overhead estimation
Cu Selur
__________________
Hybrid
|
|
|
24.10.2004 16:14 |
|
|
elestrodix
DER Anleitungsmann ;)
Dabei seit: 17.03.2002
Beiträge: 634
Herkunft: Bonner Raum
Themenstarter 
|
|
"Meine MKV Files sind nach dem muxen stets etwas kleiner als die einzelnen Dateien zusammengenommen."
gig
Das hatte ich auch vor einigen Monaten feststellen müssen.
"etwas plus etwas macht weniger als etwas 
"
Hmmm, da ist wohl was schief gelaufen, dachte ich, aber wenn du das auch hast, dann geht die Rechnerei jetzt richtig los.
Muss jetzt mal das von Selur auseinander pflücken....
Danke
__________________
OGM-Overhead-Formel?guckst du hier
|
|
|
25.10.2004 09:10 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
|
|
|
|
25.10.2004 09:16 |
|
|
alexnoe
Grünschnabel
Dabei seit: 23.11.2003
Beiträge: 4
|
|
Dann schaut mal in die mkv-docu. Da ist der Overhead für MKV etwa genauer analysiert....
__________________
AVI-Mux GUI
|
|
|
29.11.2004 23:18 |
|
|
scrat
e-divx Webmaster
Dabei seit: 22.09.2003
Beiträge: 1.657
Herkunft: Österreich
|
|
|
|
30.11.2004 14:50 |
|
|
|
