Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-18T07:21:55.947Z
Answers.Text: 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.
Answers.UserDisplayName: jiggunjer
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-18T07:42:52.427Z
Answers.Text: 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.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-18T05:13:03.097Z
Answers.LastActivityDate: 2015-12-18T05:13:03.097Z
Answers.UserDisplayName: Gyan
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-12-17T10:35:06.730Z
Comments.Text: 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.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-12-17T10:36:50.750Z
Comments.Text: oh good idea, I should have thought of that. Need more coffee.
Comments.UserDisplayName: jiggunjer
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-12-18T00:41:15.867Z
Comments.Text: 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
Comments.UserDisplayName: jiggunjer
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-12-18T05:14:34.640Z
Comments.Text: #1 is obviously true if you want to measure source bitrate. See answer for #2.
Comments.UserDisplayName: Gyan
Tags: <video><encoding><sampling-frequency><signal-processing><bitrate>
Title: how to measure bitrate of video over time
UserDisplayName: jiggunjer
ThreadText: # 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.  
  
  ---
  
  