3

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).

4
  • 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
    Dec 17, 2015 at 10:35
  • oh good idea, I should have thought of that. Need more coffee.
    – jiggunjer
    Dec 17, 2015 at 10:36
  • 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
    Dec 18, 2015 at 0:41
  • #1 is obviously true if you want to measure source bitrate. See answer for #2.
    – Gyan
    Dec 18, 2015 at 5:14

1 Answer 1

2

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.

2
  • 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
    Dec 18, 2015 at 7:21
  • 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
    Dec 18, 2015 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.