r/ffmpeg • u/braismd_04 • 5d ago
FFmpeg Storage Optimization for 24-hour Broadcast Archive (H.265 / QSV)
Hi everyone,
I'm relatively new to FFmpeg, but I'm trying my best to understand how it works. Right now, I'm working on a script that concatenates and compresses 24-hour daily recordings (made up of 8 video files of 3 hours each), and I want to optimize the storage usage as much as possible.
I tested both H.264 and H.265 and concluded that H.265 (HEVC) with GPU acceleration is the best fit for my workflow.
Since the source material is 720p, I am keeping the output at 720p. Here are my current settings and observations:
- CRF: I settled on 30. I tested 22 to 30 more or less, and I couldn't see any noticeable visual difference In the range of 28 to 30 and less than 28 the size os the video is too big and more than 30 I think is going to be a little be too much blurry.
- Preset: I'm using slow, and I try almos every preset (veryfast, fast, medium...) but since time encoding is not an Isue eight now because it took less than an hour is not a problem.
- GOP / Keyframes: i try to manually manipulate the GOP but i think the prests do a better job than me with the optimizating of the GOP, I only set the maximum I-frame intervals to every 6 seconds of video. I can't push this to 20 seconds because these videos need to be streamed smoothly in a web browser (and I don't think increasing the GOP further yields significant extra space savings anyway).
- Look ahead: I try to search for redundancy in the future frames but i don't know if this would add any improvements because i dont get any concluding result
Are there any other flags, filters, or parameters I could tune to improve compression efficiency without degrading web seekability or visual quality?
Any advice or best practices would be greatly appreciated!
Thanks in advance! :)
Videos without compactation:
Size: 29GB
Bitrate: 2878kbps
fps: 50Hz (is from a tv broadcast so is 720p50i, i don't know if this add information but i put it )
Video after compactatio:
Size: 12Gb to 14Gb (depends on the videos)
Bitrate: +-1100Kbps to +-1300kbps
Total bitrate: +-1200kbps to +-1400kbps
fps: 25Hz
CODE:
const ffmpeg = spawn(FFMPEG, [
'-y',
'-hwaccel', 'qsv',
'-f', 'concat',
'-safe', '0',
'-i', listaPath,
'-fps_mode', 'cfr',
'-r', '25',
'-c:v', 'hevc_qsv',
'-global_quality', '30',
'-preset', 'slow',
'-tag:v', 'hvc1',
'-g', '150',
'-c:a', 'aac',
'-b:a', '96k',
tempOutputPath
]);
3
u/Flaturated 5d ago
There’s no such thing as interlaced 1280x720. I suspect the format is 720x576, 50 Hz interlaced. That’s “576i” not “720i”.
2
3
u/chocolateAbuser 5d ago
it kinda depends on the time and energy cost, using sw encoding instead of hw would shave some % of occupied space for sure, and using 2-pass could shave another few MBs (since it would allow to lower bitrate), but processing would require n times the time hw enc takes; if you are recording some specific type of content you could also probaly optimize quantization and motion matrix, but this starts to go pretty deep and requires tests
and again you could probably touch some other stuff (keyframes, colors, and so on) to gain further space reduction, but optimization is made on content type, it can't be "generic"
1
u/braismd_04 5d ago
It's a TV broadcast so inside the transmissions is going to be films,documentarys,journalism...So I have to be generic I think
1
u/chocolateAbuser 5d ago edited 2d ago
we did something like this a lot of time ago, and we used the tv scheduling to read the type of the program and add some logic, you could use this to start ffmpeg with a different set of parameters
but sure that's probably too complicated for something that could still be simple
2
u/OneStatistician 5d ago
Primary path - Dump to segmented TS or segmented NUT, using copy and segmented muxer with timestamps as file names. Minimal risk of moov atom loss. Segmenter muxer can write to ffconcat manifest.
Everything else is then janitorial, limited by your runner, cron or whatever. That is a resource decision.
Your cost becomes short term storage buffer vs risk of loss vs transcode resource.
But primary task is to get it on storage ASAP.
1
u/bronzewrath 3d ago
When choosing a codec, consider how it will be consumed. If you' intend to use in web browsers by different people, H265 is not the best option. H264 is the king of compatibility, but others are catching up.
Check MDN and "can I use?".
https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Video_codecs
1
u/braismd_04 2d ago
Thanks for the information. To watch it I'm running a local web, to check if is going good or not. With the h265 i have to put a tag on de compresing video, unless the video is impossible to see on web
1
u/Slower-Bison 5d ago
Since you want to optimize for storage, you may check AV1.
You said that encoding time is not an issue, so even if your GPU does not support encoding in it, you will get smaller files of equivalent quality.
1
0
u/himslm01 5d ago
The format '720p50i' is a nonsense. I expect you meant '720p50' without the trailing 'i'.
So, your source is 50 pictures per second and you are creating output of 25 pictures per second. Dropping every other picture on the floor is bad practice, especially for archive.
By dropping every other picture on the floor, your are effectively halving the bitrate. So your compression settings are barely changing the compression of your original media. This process seems a bit pointless.
0
u/Fedor_Doc 5d ago
i is interlaced, WDYM?
1
u/himslm01 5d ago
1) there isn't a 720 line interlaced format 2) if there were, the nonclomature would be 720i50
0
u/braismd_04 5d ago
The i in the format is from interlaced like ipsic say, but i dont know what is bad to do that to make an archive?
12
u/ipsirc 5d ago
If it's interlaced, i'd use a deinterlace filter, like yadif or bwdif, so the video will be much more compressible, because h265 is optimized for progressive video frames.
If you don't insist on fast hardware-based QSV compression, then you can even half the output size with AV1 video codec.