[FFmpeg-user] Compression is a lot smaller
eclipse7 at gmx.net
Mon Aug 17 13:11:25 EEST 2020
On 2020-08-15 16:25 +0200, Cecil Westerhof wrote:
> Simon Roberts <simon at dancingcloudservices.com> writes:
> > On Sat, Aug 15, 2020 at 5:01 AM Cecil Westerhof <Cecil at decebal.nl> wrote:
> >> Through scripts I use ffmpeg for cutting and compressing videos and
> >> sometimes adding a watermark. Nothing fancy, but handy.
> >> In the past the original file was between 4 to 13 times bigger as the
> >> compressed file. Today I compressed a few files again. The compression
> >> was almost non existing to less as three.
> > [...]
> > What could be happening here?
> > The most immediate thought is that zoom improved their compression
> > algorithm and now there's not so much room left for a secondary
> > improvement.
> > You might want to take a look at the original, perhaps using ffprobe, to
> > determine what codec was used, and what bitrate it started out with.
> No, that is not the case. These where videos I shot with my Sony
> handycam. So uncompressed files.
> But maybe I should have described it a bit clearer.
Did I misread your logs?
| Input #0, mpegts, from '00039.MTS':
| Duration: 00:02:49.02, start: 1.040000, bitrate: 22533 kb/s
| Program 1
| Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9],
|+25 fps, 50 tbr, 90k tbn, 50 tbc
| Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 256 kb/s
| Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle ( / 0x0090), 1920x1080
| Stream mapping:
| Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
The input doesn't look uncompressed to me.
More information about the ffmpeg-user