<p>It does not make sense to speak of the size of an encoded frame in an inter-coded video stream, which is typical of MPEG-<em><code>X</code></em> videos. I-frames are self-contained but P- and B- frames are predicted frames and the final decoded result uses data from various inputs. On the other hand, the size of a single Group of Pictures (GOP) may be a meaningful measure.</p>

<p>The FFmpeg segmenter in combination with a compatible demuxer can break apart the video stream at GOP boundaries. By specifying an ultra-low time for segment size, you can ensure that each segment contains 1 GOP. Running a ffprobe on each segment will then provide the bitrate for that GOP.</p>

<p>I tested the command below on MP4s which had 1) a variable-sized GOP, 2) an intra-coded scheme and 3) fixed GOP of unusual length (11 frames), and each output had the expected result.</p>

<pre><code>ffmpeg -i input.mp4 -an -c:v copy -segment_time 0.00001 -f segment i%0d.mp4
</code></pre>

<p>Each segment contained exactly 1 I-frame (each segment of the intra input contained exactly 1 frame in all).</p>

<p>Running ffprobe on each segment gives a bitrate reading:</p>

<pre><code>Duration: 00:00:00.37, start: 4.466016, bitrate: 1539 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
1280x720 [SAR 1:1 DAR 16:9], 1520 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
</code></pre>

<p>The above one is from the 11-frame GOP, and has a bitrate of 1520 kbps.</p>

CC BY-SA 3.0
2015-12-18T07:21:55.947Z
so if you have 1 source with GOPs of 1-2 seconds and other GOPs of around 250 milliseconds, your resulting plot would have erratic datapoints on the timeline. What would be a good work-around for that case? I suppose I'd group the GOPs into larger bins, i.e. average over 3-5 GOPs.
jiggunjer
CC BY-SA 3.0
2015-12-18T07:42:52.427Z
Just plot data rate (Y) vs Start Time (X) instead of duration. The Y remains unchanged from its Start till the next segment's Start time. If you want to get rid of the step function look, there will be some smoothing/interpolation function in your plotting s/w.
Gyan
CC BY-SA 3.0
2015-12-18T05:13:03.097Z
2015-12-18T05:13:03.097Z
Gyan
<p>Given an encoded video file with non-constant bitrate, how would one analyze the bitrate over time? So far I found one old program that produces a bitrate plot, but none that can give the raw data of the encoded frames.</p>

<p>I think bitrate data should be generated by averaging the size of a set of frames spanning 1 second--i.e. frames with a DTS belonging in that interval. So a 10 second video would have 10 data points describing the encoder input bitrate. Though I am curious to hear alternative ways of calculating bitrate.</p>

<p>Is there a way to get the size of each (encoded) frame? preferably with windows software. I know it is trivially easy for an uncompressed source (resolution * bitdepth * time).</p>

CC BY-SA 3.0
2015-12-17T10:35:06.730Z
Size of an encoded frame won't make sense for predicted frames. I'll supply an answer later in the day but basic way is to segment the video and then run ffprobe on each of the segments and output that data to a file.
Gyan
CC BY-SA 3.0
2015-12-17T10:36:50.750Z
oh good idea, I should have thought of that. Need more coffee.
jiggunjer
CC BY-SA 3.0
2015-12-18T00:41:15.867Z
Ah @Mulvya but when you segment the video into segments by keyframe you: 1) should not re-encode 2) need a source with (reasonably) homogeneously spaced keyframes
jiggunjer
CC BY-SA 3.0
2015-12-18T05:14:34.640Z
#1 is obviously true if you want to measure source bitrate. See answer for #2.
Gyan
<video><encoding><sampling-frequency><signal-processing><bitrate>
how to measure bitrate of video over time
jiggunjer
# how to measure bitrate of video over time

(Asked by: username_0 on 2015-12-17)

Given an encoded video file with non-constant bitrate, how would one analyze the bitrate over time? So far I found one old program that produces a bitrate plot, but none that can give the raw data of the encoded frames.

I think bitrate data should be generated by averaging the size of a set of frames spanning 1 second--i.e. frames with a DTS belonging in that interval. So a 10 second video would have 10 data points describing the encoder input bitrate. Though I am curious to hear alternative ways of calculating bitrate.

Is there a way to get the size of each (encoded) frame? preferably with windows software. I know it is trivially easy for an uncompressed source (resolution \* bitdepth \* time).

**Tags:** video, encoding, sampling-frequency, signal-processing, bitrate

> **Comments:**
> **username_1**: Size of an encoded frame won't make sense for predicted frames. I'll supply an answer later in the day but basic way is to segment the video and then run ffprobe on each of the segments and output that data to a file.  
> **username_0**: oh good idea, I should have thought of that. Need more coffee.  
> **username_0**: Ah @Mulvya but when you segment the video into segments by keyframe you: 1) should not re-encode 2) need a source with (reasonably) homogeneously spaced keyframes  
> **username_1**: #1 is obviously true if you want to measure source bitrate. See answer for #2.  

---

## 1 answers

### Answer by username_1 on 2015-12-18. Score: 2 | Accepted answer

It does not make sense to speak of the size of an encoded frame in an inter-coded video stream, which is typical of MPEG-X videos. I-frames are self-contained but P- and B- frames are predicted frames and the final decoded result uses data from various inputs. On the other hand, the size of a single Group of Pictures (GOP) may be a meaningful measure.
The FFmpeg segmenter in combination with a compatible demuxer can break apart the video stream at GOP boundaries. By specifying an ultra-low time for segment size, you can ensure that each segment contains 1 GOP. Running a ffprobe on each segment will then provide the bitrate for that GOP.
I tested the command below on MP4s which had 1) a variable-sized GOP, 2) an intra-coded scheme and 3) fixed GOP of unusual length (11 frames), and each output had the expected result.
ffmpeg -i input.mp4 -an -c:v copy -segment_time 0.00001 -f segment i%0d.mp4

Each segment contained exactly 1 I-frame (each segment of the intra input contained exactly 1 frame in all).
Running ffprobe on each segment gives a bitrate reading:
Duration: 00:00:00.37, start: 4.466016, bitrate: 1539 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
1280x720 [SAR 1:1 DAR 16:9], 1520 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)

The above one is from the 11-frame GOP, and has a bitrate of 1520 kbps.

> **Comments:**
> **username_0**: so if you have 1 source with GOPs of 1-2 seconds and other GOPs of around 250 milliseconds, your resulting plot would have erratic datapoints on the timeline. What would be a good work-around for that case? I suppose I'd group the GOPs into larger bins, i.e. average over 3-5 GOPs.  
> **username_1**: Just plot data rate (Y) vs Start Time (X) instead of duration. The Y remains unchanged from its Start till the next segment's Start time. If you want to get rid of the step function look, there will be some smoothing/interpolation function in your plotting s/w.  

---

