<p>No, since different containers have a different overhead over actual data. But you can predict size, if you calculate average difference of source and destination files on actual files.</p>

<p>Other way - calculate size, using actual data, but it may be very slow, as you must walk throw all your data and calculate every chunk size. For this, you can use tool <code>ffprobe</code> to get size of every frame or chunk.</p>

CC BY-SA 3.0
2017-08-30T17:30:07.897Z
2017-08-30T17:30:07.897Z
bukkojot
<p>The only exact approach is to simulate the muxing. On a *nix system this would be</p>

<pre><code>ffmpeg -i i.mkv -i i.flac -c copy -map 0:0 -map 1:0 -f matroska /dev/null
</code></pre>

<p>At the bottom of console readout, there's this line:</p>

<pre><code>frame=152217 fps=71723 q=-1.0 Lsize=  551301kB time=01:41:28.66 ...
</code></pre>

<p>The <code>Lsize</code> is what you want. This operation is pretty quick as there's nothing written to disk.</p>

CC BY-SA 3.0
2017-08-30T17:29:57.013Z
2017-08-30T17:29:57.013Z
Gyan
<p>I run a web service which muxes multiple elementary streams (e.g., H.264 + FLAC) into a single matroska container/wrapper/file. There is no transcoding as I only copy the streams, using a process like <code>ffmpeg  -i i.mkv -i i.flac   -map 0:0 -c:0 copy -map 1:0 -c:1 copy out.mkv</code>.</p>

<p>The problem is that the service must provide the total file size (in bytes) of the file (<code>out.mkv</code>) resulting from the mux up front (i.e., before the actual muxing completes).  Is it possible to calculate it?</p>

<ffmpeg>
How to calculate the overhead of wrapping multiple elementary streams?
mike
# How to calculate the overhead of wrapping multiple elementary streams?

(Asked by: username_0 on 2017-08-30)

I run a web service which muxes multiple elementary streams (e.g., H.264 + FLAC) into a single matroska container/wrapper/file. There is no transcoding as I only copy the streams, using a process like `ffmpeg -i i.mkv -i i.flac -map 0:0 -c:0 copy -map 1:0 -c:1 copy out.mkv`.

The problem is that the service must provide the total file size (in bytes) of the file (`out.mkv`) resulting from the mux up front (i.e., before the actual muxing completes). Is it possible to calculate it?

**Tags:** ffmpeg


---

## 2 answers

### Answer by username_1 on 2017-08-30. Score: 0 | Accepted answer

No, since different containers have a different overhead over actual data. But you can predict size, if you calculate average difference of source and destination files on actual files.

Other way - calculate size, using actual data, but it may be very slow, as you must walk throw all your data and calculate every chunk size. For this, you can use tool `ffprobe` to get size of every frame or chunk.


---

### Answer by username_2 on 2017-08-30. Score: 2

The only exact approach is to simulate the muxing. On a *nix system this would be
ffmpeg -i i.mkv -i i.flac -c copy -map 0:0 -map 1:0 -f matroska /dev/null

At the bottom of console readout, there's this line:
frame=152217 fps=71723 q=-1.0 Lsize=  551301kB time=01:41:28.66 ...

The Lsize is what you want. This operation is pretty quick as there's nothing written to disk.


---

