[SOLVED] Shrinking crazy sized video file

business_kid · 08-20-2022, 11:45 AM

I have basically the same 1 hour videos in 2 files. One is ~4G each, the other is ~400M. Now there's issues with some of the ~400M, (10 of them), but I don't want to store 40G to replace ~4G, as you might imagine. I ran ffprobe on them and have the data.

Code:

bash-5.1$ cat file-big.txt |grep -A50 Metadata
  Metadata:
    encoder         : libebml v1.3.10 + libmatroska v1.5.2
    creation_time   : 2022-02-27T16:28:02.000000Z
  Duration: 00:59:20.99, start: 0.000000, bitrate: 9988 kb/s
  Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn, 50 tbc (default)
    Metadata:
      BPS-eng         : 9761970
      DURATION-eng    : 00:59:20.960000000
      NUMBER_OF_FRAMES-eng: 89024
      NUMBER_OF_BYTES-eng: 4345248503
      _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2022-02-27 16:28:02
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  Stream #0:1(eng): Audio: eac3, 48000 Hz, stereo, fltp, 224 kb/s (default)
    Metadata:
      BPS-eng         : 224000
      DURATION-eng    : 00:59:20.992000000
      NUMBER_OF_FRAMES-eng: 111281
      NUMBER_OF_BYTES-eng: 99707776
      _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2022-02-27 16:28:02
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  Stream #0:2(eng): Subtitle: subrip
    Metadata:
      BPS-eng         : 104
      DURATION-eng    : 00:59:10.880000000
      NUMBER_OF_FRAMES-eng: 1391
      NUMBER_OF_BYTES-eng: 46235
      _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2022-02-27 16:28:02
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
bash-5.1$ 
bash-5.1$ 
bash-5.1$ cat file-small.txt |grep -A50 Metadata
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Peter Bishop
  Duration: 00:58:14.68, start: 0.000000, bitrate: 720 kb/s
  Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/unknown/unknown), 720x402, 608 kb/s, 25 fps, 25 tbr, 20k tbn, 50 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 105 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]

The bitrate leaped out at me as wildly different. What's an acceptable bitrate? Is there anything else I can change without junking quality?

EDIT: The 'grep' bit just drops the compile-time options & libraries.

TenTenths · 08-20-2022, 12:08 PM

First off, the resolutions are different. The top one is full HD - 1920x1080, the other is 720x402 which is roughly 9 times smaller, so that'll explain why the files are nearly 10 times smaller. Remember that bitrate is the rate that the data needs to be transferred to create the image, so, again, I'd expect the bitrate of the full HD stream to be roughly 10x

Quote:

Originally Posted by business_kid

The bitrate leaped out at me as wildly different. What's an acceptable bitrate? Is there anything else I can change without junking quality?

Define "quality", it's all personally subjective. If you're looking at a 60" 8K display then you might want the full HD version, and even then it's going to be upscaled 16x so might appear "blocky", if you're looking on a laptop or non ego-boosting TV then you might find the other resolution is acceptable.

For what it's worth, 720x402 is pretty close to 720x480 wich was the standard resolution for NTSC DVD (PAL, as used in Ireland/UK was 720x576)

Any of these encodings is "lossy", if you can't tell the difference on your normal use case then keep the smaller ones. If you can see the difference then try re-encoding with different settings until you find a balance you're happy with.

business_kid · 08-20-2022, 02:41 PM

Thanks for the reply. I'm funny with quality. Having grown up in the days when tvs had a "405/625" switch, you got used to what you had. Yes, the smaller one is grainier. I have a 1920×1080@60Hz setup. But once I'm 5 minutes into something, I forget about the quality, unless it's really bad. I never felt the need for 4K, never mind 8K.

With that information, I can probably resize the big one to 1280×720 which will give me a fairly decent size reduction. The standard for PAL was 625 vertical lines but if you exclude the invisible lines and flyback time, you could be left with 576 lines. I left all that behind in the 1970s and went into research. Secam had even more vertical lines (819?).

rado84 · 08-21-2022, 04:15 PM

Quote:

Originally Posted by business_kid

Is there anything else I can change without junking quality?

Yes, but it will work only if you have an nvidia video card and a stable driver version (XXX.YY version style): use NVENC. I have a custom preset for Handbrake for NVENC and it works like a charm: https://i.imgur.com/1sjDIWM.png With this setting a 50 GB UHD movie becomes ~ 7.5 GB FullHD with the same quality as its H264 original counterpart, all in 20 minutes of time.
I have downloaded and converted all the episodes of Supergirl which originally were ~4 GB each with an excessively high H264 video bitrate, often more than 12 Mbps. H264 is an ancient and incompetent codec, so I'm not surprised it needs such amounts of bitrate for quality image. I made them with H265 and bitrate ~4600 Kbps. The size dropped almost twice but the quality remained the same. https://i.imgur.com/cFdGlP6.png

computersavvy · 08-21-2022, 07:38 PM

One other suggestion is ffmpeg. It can easily convert codecs, handles h264 easily, and can export it as h265 with the proper codecs installed on your system. Just my

business_kid · 08-22-2022, 03:55 AM

I was already planning that

business_kid · 08-22-2022, 11:40 AM

Just to report back. Using

Code:

ffmpeg -i input.mkv -c:v libx265 -vtag hvc1 output.mp4

I converted my sample from 4.2GB to 371MB!

The conversion took 23 minutes using 850% - 1100% cpu. There is zero loss of quality, it seems in that conversion. Interestingly, ffmpeg only had one process using multiple threads, so it bespeaks some very elegant programming.

Any optimizations welcome.

SW64 · 08-23-2022, 04:29 PM

Try '-preset veryslow'. It'll give you improved and "smoother" visual quality. Default is medium. Expense is more CPU time.

If you want to push shrinking it little bit more, try '-crf x'. By default, x is 23. The working range is from 0 to 51. 0 is practically lossless at expense of incurring more hard drive space. I usually use 1 or 2 when I need lossless. 51 is maximum lossy at a huge expense of visual quality. I usually stop at around 28 to 32 on the lossy side. Most of the time, default 23 is good enough for me.

Maybe add in '-pix_fmt yuv420p' too for better media player compatibility.

Code:

ffmpeg -i input.mkv -c:v libx265 -crf 23 -preset veryslow -pix_fmt yuv420p -vtag hvc1 output.mp4

Please let me know if that doesn't work with QuickTime Player. I haven't used one in a long time.

To quickly test ffmpeg options, add in '-t 30 -ss 120' in between ffmpeg and -i. You'll get a 30 seconds sample two minutes into the video.

business_kid · 08-25-2022, 01:04 PM

Thanks, but that's quite small enough for me. In other news, I'm chopping other big videos (~2.1G per episode) back to ~500-600Megs with the same technique. Doing the job in less than 20 mins @ ≅900% cpu for a 1 hour video would be good. That would be flat out for 90 minutes on my old laptop, which would probably cook. For a laugh, I'll try one on a 1.5Ghz RazPi with 'time' running

.

EDIT: Mine's one of the early Pi 4Bs. Later ones did 1.8Ghz and had an adjustable (cpu) PSU so you could specify an 'overvolts' setting in /boot/config.txt. I just don't know if mine handles that, and I'm not really an overclocker anyhow.

business_kid · 08-26-2022, 12:24 PM

Well that timing test on the RazPi is put on hold.

I installed a disk image on the RazPi which is the way to go. But it left me light on the development stuff. So after a few false starts, I decided to mirror the slarm64 packages from slackware.uk, and do a mass 'upgradepkg --install-new.' I already have the backup - just in case.

This is to achieve timing tests, which are not in any way a priority. It's good to build have development stuff but far from essential on a RazPi. That libX265 is also a sizeable compiling job - 200 Megs of code!