I've used ffmpeg for years for minor tweaks to sound & video but I know pretty much zero about containers and codecs and whatnot.

I've recently had a need to reduce the physical (disk) size of videos recorded on my phone to meet restrictions for uploads to social media.

Because it's disposable content for social media, best quality isn't that important.

What I really want is to understand what is happening in the following situation:

Source video is from OpenCamera on Android 12, using default settings.

The source video is about 80mb on disk, and the output from ffprobe looks like this:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'VID_20221101_101217Z.mp4':
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    creation_time   : 2022-11-01T10:13:05.000000Z
    com.android.version: 11
  Duration: 00:00:46.89, start: 0.000000, bitrate: 14227 kb/s
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1600x900, 14075 kb/s, SAR 1:1 DAR 16:9, 29.95 fps, 29.95 tbr, 90k tbn, 180k tbc (default)
      rotate          : 90
      creation_time   : 2022-11-01T10:13:05.000000Z
      handler_name    : VideoHandle
    Side data:
      displaymatrix: rotation of -90.00 degrees
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 96 kb/s (default)
      creation_time   : 2022-11-01T10:13:05.000000Z
      handler_name    : SoundHandle

If I do nothing else except this:

ffmpeg -i VID_20221101_101217Z.mp4 VID_20221101_101217Z_NO_CHANGE.mp4

The file size drops to 29mb and the output of ffprobe looks like this:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'VID_20221101_101217Z_NO_CHANGE.mp4':
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf57.83.100
  Duration: 00:00:46.88, start: 0.000000, bitrate: 5019 kb/s
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 900x1600 [SAR 1:1 DAR 9:16], 4888 kb/s, 29.95 fps, 29.95 tbr, 18k tbn, 59.90 tbc (default)
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 121 kb/s (default)
      handler_name    : SoundHandler

The subjective quality of the two are barely distinguishable & the second version is easily good enough for social media.

I can see that some numbers are different: kb/s, tbn, tbc are smaller, and I can see that 'yuv420p' no longer has '(tv,bt709)' appended. I also note that the kb/s for the audio stream in the second version is higher.

But I don't understand what these numbers mean and what has been "lost" so that the file size has been reduced by ~64%

It's a bt of a general question for SE I realise, but nevertheless I'd hope for some clarification.


1 Answer 1


When you run ffmpeg without specifying any options, its default behavior is to decode the audio and video and then reencode them. In the case of mp4, it chooses its aac encoder for the audio, and libx264 for the video. You can see this change when you run ffmpeg:

  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (opus (native) -> aac (native))

Here, my video that originally was encoded using an unknown h264 encoder, is now being encoded with libx264, and the opus audio was converted to aac. As in your case the video and audio were already h264 and aac respectively, so there was no change in codec, but the encoder used to encode each stream changed. As for why the size changed, ffmpeg's default parameters for x264 are evidently more aggressive compared to the defaults of OpenCamera, resulting in a smaller file size.

An analogy for this would be like opening a jpeg photo in photoshop or paint, and then saving it as a jpeg again. The resulting photo might be larger or smaller, depending on how the program compresses it.

If you find this behavior undesirable, you can also copy codecs like this:

ffmpeg -i VID_20221101_101217Z.mp4 -c:v copy -c:a copy VID_20221101_101217Z_NO_CHANGE.mp4

This will not reencode either codec, preserving the file size.

Your Answer

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

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