<p>The short answer: <strong>container overhead</strong>.</p>
<p>MKV (and to a lesser extent, MP4/ISOBMFF) are very &quot;flexible&quot; containers, and basically adapt to whatever you're trying to shove into them, provided the muxer knows how to handle it and the demuxer at the other end is expecting it.</p>
<p>MPEG-TS is a rigid dinosaur meant to behave exactly the same way, every single time; on discrete hardware, in software, over the air, in cables under the ground, over cellular networks, etc. It <em>can be</em> more resilient as a result, but that comes at a cost - usually padding bytes and wasted packets.</p>
<hr />
<p>While it's from an &quot;Internet video infrastructure&quot; company's blog, this article from a Mux engineer gave the nicest explanation I could find for you. <a href="https://www.mux.com/blog/quantifying-packaging-overhead-2" rel="nofollow noreferrer">Mux - Quantifying packaging overhead</a></p>
<blockquote>
<p>TS has some strange properties. It was built for a pre-ethernet world and includes features such as lost and out of order packet detection and remote time synchronization. These features are required for digital over-the-air broadcasts...TS also <strong>uses a fixed packet size of 188 bytes with each packet starting with a sync byte to identify the start of a packet</strong>...<strong>The downside of not using these features is that they still take up space in the file.</strong></p>
<p>Each 188 byte TS packet has a 4 byte header. This header contains the sync byte, some flag bits, a packet id (or PID, which identifies a unique audio or video stream), and a continuity counter (used to identify missing or out of order packets). Every frame then has a prepended Packetised Elementary Stream (PES) header. The PES header is a minimum of 14 bytes, (or 19 bytes if the frame decode time does not match the presentation time, i.e. B frames) and encodes the frame timestamps among other things. Therefore, the first packet has at most 170 bytes available while subsequent packets have 184 bytes available. If a frame is less than 170 bytes, it must be padded to consume the full packet. If a frame is 171 bytes, a second packet is required and thus 376 bytes (188x2) is needed to transmit the 171 bytes of payload, more than doubling the required bandwidth. In reality, frames under 170 bytes are not very common. However at bitrates under 1Mbps, a 10% or more overhead is not uncommon.</p>
</blockquote>
<p><a href="https://www.mux.com/blog/quantifying-packaging-overhead-2" rel="nofollow noreferrer">Mux</a></p>
<hr />
<p>You'd likely see a similar size reduction remuxing to .mp4. Since this is a satellite TS, there could be more than one video, audio, or subtitle track, but I'll assume you preserved them all when remuxing. There might also be other satellite specific &quot;program data&quot; that is discarded when you remux to MKV. e.g. MPEG-TS packet IDs 16–31/0x0010-0x001F are used for DVB metadata. MKV muxers toss that out if they don't know what to do with it, but it's likely of little use to you, especially if it is repeated with every single packet.</p>
<blockquote>
<p>Some transmission schemes, such as those in ATSC and DVB, impose strict constant bitrate requirements on the transport stream. In order to ensure that the stream maintains a constant bitrate, a multiplexer may need to insert some additional packets. The PID 0x1FFF is reserved for this purpose. The payload of null packets is all zeroes, and the receiver is expected to ignore its contents. <a href="http://www.img.lx.it.pt/%7Efp/cav/Additional_material/MPEG2_overview.pdf" rel="nofollow noreferrer" title="A Guide to MPEG Fundamentals and Protocol Analysis (PDF), Tektronix, p. 37, retrieved 23 April 2020"><sup>15</sup></a></p>
</blockquote>
<p>They could also be null/padding packets - like I mentioned above for ATSC/DVB, or you might sometimes see with a .ts/series of .ts files used for MPEG-DASH or HLS internet streaming at a <strong>strict</strong> constant bitrate. TS overhead for internet use usually comes down to how many &quot;extra&quot; nearly empty frames are required depending on your bitrate, not strict CBR padding.</p>
<p><a href="https://en.wikipedia.org/wiki/MPEG_transport_stream#Null_packets" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/MPEG_transport_stream#Null_packets</a></p>
<p>Use MediaInfo to look at your source .ts and you might be able to get a better idea if there's any extra program data or not.</p>

CC BY-SA 4.0
2024-03-29T18:45:27.037Z
*"a 10% or more overhead is not uncommon."* In my tests a typical DVB-S recording of, say, 4GB remuxes to a 3GB .mkv file with mkvmerge (keeping all streams). I understand why there is overhead. I could even imagine 10%. But 25% ?? That doesn't seem explainable to me by overhead alone. What I would be interested in is a source explaining this big overhead. I'm not sure your answer (which I otherwise like) really provides that ?
summerrain
CC BY-SA 4.0
2024-03-31T02:16:50.183Z
for legacy DVB-S, CBR (constant bitrate) is a requirement. If the actual bitrate drops below that value, the muxer at their end literally adds zeros to fill space up lol. How many individual streams are contained within the TS container? That might have something to do with it.
Haachamachama
CC BY-SA 4.0
2024-03-29T16:05:57.933Z
2024-03-29T16:05:57.933Z
Haachamachama
<p>When I remux the transport stream (.ts file) of a satellite recording to mkv, file size shrinks considerably.</p>
<p>Why is that ?<br />
What is inside the .ts container that gets &quot;lost&quot; during remuxing ?</p>
<p>For testing purposes, I recorded a few seconds of a TV satellite broadcast, resulting in a 4 MB .ts file. I then remuxed this file to .mkv, keeping all streams (1 video stream + 2 audio streams) and got a 3 MB .mkv file.<br />
What accounts for the -25% difference in file size ?</p>
<p>I can attach the files if needed.
No reencoding takes place.</p>

CC BY-SA 4.0
2023-04-10T05:59:15.757Z
Is the video stream re-encoded during remux ?
audionuma
CC BY-SA 4.0
2023-04-11T03:19:42.447Z
@ audionuma: no. I updated the question. Thank you.
summerrain
<video><mkv>
Why has transport stream (TS) a much bigger file size than mkv?
summerrain
# Why has transport stream (TS) a much bigger file size than mkv?

(Asked by: username_0 on 2023-04-08)

When I remux the transport stream (.ts file) of a satellite recording to mkv, file size shrinks considerably.

Why is that ?  
What is inside the .ts container that gets "lost" during remuxing ?

For testing purposes, I recorded a few seconds of a TV satellite broadcast, resulting in a 4 MB .ts file. I then remuxed this file to .mkv, keeping all streams (1 video stream + 2 audio streams) and got a 3 MB .mkv file.  
What accounts for the -25% difference in file size ?

I can attach the files if needed.
No reencoding takes place.

**Tags:** video, mkv

> **Comments:**
> **username_1**: Is the video stream re-encoded during remux ?  
> **username_0**: @ username_1: no. I updated the question. Thank you.  

---

## 1 answers

### Answer by username_2 on 2024-03-29. Score: 2

The short answer: **container overhead**.

MKV (and to a lesser extent, MP4/ISOBMFF) are very "flexible" containers, and basically adapt to whatever you're trying to shove into them, provided the muxer knows how to handle it and the demuxer at the other end is expecting it.

MPEG-TS is a rigid dinosaur meant to behave exactly the same way, every single time; on discrete hardware, in software, over the air, in cables under the ground, over cellular networks, etc. It *can be* more resilient as a result, but that comes at a cost - usually padding bytes and wasted packets.

---

While it's from an "Internet video infrastructure" company's blog, this article from a Mux engineer gave the nicest explanation I could find for you. [Mux - Quantifying packaging overhead](https://www.mux.com/blog/quantifying-packaging-overhead-2)

> TS has some strange properties. It was built for a pre-ethernet world and includes features such as lost and out of order packet detection and remote time synchronization. These features are required for digital over-the-air broadcasts...TS also **uses a fixed packet size of 188 bytes with each packet starting with a sync byte to identify the start of a packet**...**The downside of not using these features is that they still take up space in the file.**
>
> Each 188 byte TS packet has a 4 byte header. This header contains the sync byte, some flag bits, a packet id (or PID, which identifies a unique audio or video stream), and a continuity counter (used to identify missing or out of order packets). Every frame then has a prepended Packetised Elementary Stream (PES) header. The PES header is a minimum of 14 bytes, (or 19 bytes if the frame decode time does not match the presentation time, i.e. B frames) and encodes the frame timestamps among other things. Therefore, the first packet has at most 170 bytes available while subsequent packets have 184 bytes available. If a frame is less than 170 bytes, it must be padded to consume the full packet. If a frame is 171 bytes, a second packet is required and thus 376 bytes (188x2) is needed to transmit the 171 bytes of payload, more than doubling the required bandwidth. In reality, frames under 170 bytes are not very common. However at bitrates under 1Mbps, a 10% or more overhead is not uncommon.

[Mux](https://www.mux.com/blog/quantifying-packaging-overhead-2)

---

You'd likely see a similar size reduction remuxing to .mp4. Since this is a satellite TS, there could be more than one video, audio, or subtitle track, but I'll assume you preserved them all when remuxing. There might also be other satellite specific "program data" that is discarded when you remux to MKV. e.g. MPEG-TS packet IDs 16–31/0x0010-0x001F are used for DVB metadata. MKV muxers toss that out if they don't know what to do with it, but it's likely of little use to you, especially if it is repeated with every single packet.

> Some transmission schemes, such as those in ATSC and DVB, impose strict constant bitrate requirements on the transport stream. In order to ensure that the stream maintains a constant bitrate, a multiplexer may need to insert some additional packets. The PID 0x1FFF is reserved for this purpose. The payload of null packets is all zeroes, and the receiver is expected to ignore its contents. [15](http://www.img.lx.it.pt/%7Efp/cav/Additional_material/MPEG2_overview.pdf "A Guide to MPEG Fundamentals and Protocol Analysis (PDF), Tektronix, p. 37, retrieved 23 April 2020")

They could also be null/padding packets - like I mentioned above for ATSC/DVB, or you might sometimes see with a .ts/series of .ts files used for MPEG-DASH or HLS internet streaming at a **strict** constant bitrate. TS overhead for internet use usually comes down to how many "extra" nearly empty frames are required depending on your bitrate, not strict CBR padding.

<https://en.wikipedia.org/wiki/MPEG_transport_stream#Null_packets>

Use MediaInfo to look at your source .ts and you might be able to get a better idea if there's any extra program data or not.

> **Comments:**
> **username_0**: *"a 10% or more overhead is not uncommon."* In my tests a typical DVB-S recording of, say, 4GB remuxes to a 3GB .mkv file with mkvmerge (keeping all streams). I understand why there is overhead. I could even imagine 10%. But 25% ?? That doesn't seem explainable to me by overhead alone. What I would be interested in is a source explaining this big overhead. I'm not sure your answer (which I otherwise like) really provides that ?  
> **username_2**: for legacy DVB-S, CBR (constant bitrate) is a requirement. If the actual bitrate drops below that value, the muxer at their end literally adds zeros to fill space up lol. How many individual streams are contained within the TS container? That might have something to do with it.  

---

