Is there a video container which is able to handle segments of different video quality (or even size)?

Question

Let's assume I have a video of 10 minutes length. And I want to reduce its size by having some parts in high bitrate, while other less important parts can be low bitrate. For this I'd cut the original into segments. Leaving the important ones as they are, while transcoding the unimportant parts to a lower quality.

Now, is there a video container format out there which is able to "glue" these different parts together into one file? With good support in players so trusty mplayer will play the video as if it's an ordinary file? And in a standardized/annotated/undo-able way so a simple cli command would untangle the segments into separate parts/files again?

I was under the impression Matroska would be able to do this, via chapters, where each of my segments would be one chapter. (I've read it somewhere where merging videos without transcoding was dicussed). But when I read the actual mkv docs, it seems mkv chapters are more like a textual index pointing into another (video) stream of an .mkv file - and not some low level kind of data block index which would help me with my idea. So mkv looks like a dead end.

Simple editing, or merging (which is possible losslessly, with some remuxing) wouldn't offer me having different qualities in different sections of the video - right?

What I'm looking for is region-of-interest adapted quality, something image formats like JPEG2000 offer for spatial areas, only here applied to video over time.

Any suggestions or ideas?

The accepted answer suggests using the VBR capabilities of a format like mp4. While this works, please leave an answer if you know of a different way of achieving the desired result.

Answer 1

If the only difference is bitrate, then any container which accepts variable bitrate streams, will fulfill your requirement e.g. MP4, MKV..etc

Step 1 is to encode your segments, ideally using the same encoder, to different bitrates with all other parameters being the same e.g. via ffmpeg,

ffmpeg -ss 0 -t 5 -i input.mp4 -b:v 1000k seg1.mp4

ffmpeg -ss 5 -t 7 -i input.mp4 -b:v 3000k seg2.mp4

ffmpeg -ss 12 -i input.mp4 -b:v 500k seg3.mp4

Step 2 is to use ffmpeg to concat the encoded segments in copy mode, using the concat demuxer.

Prepare a text file

file 'seg1.mp4'
file 'seg2.mp4'
file 'seg3.mp4'

and then

ffmpeg -f concat -i list.txt -c copy joined.mp4

---

Clips with different properties, like resolution, can be joined together as well into one MP4, but compatibility across media players is iffy, and ffmpeg won't do it reliably at present, anyway.

Answer 2

Advanced Authoring Format (AAF) and some MXF operational patterns (OP-2a, 2b, 3a, and 3b) should be able mix bit rates. I say "should" because I don't have any good way of testing right now and I don't know of any commercial systems that are making heavy use of those MXF OP's.

Answer 3

Well I can't say I know how it would be done; but RED (www.red.com), their R3D video format uses a debayer process.

I own a RED Epic. It shoots at up to 5K 100 FPS.

When out in the field, and wanting to view the video on say a laptop, the throughput of uncompressed (or near) say 3:1 5K is huge.

So RED uses a debayer process; where the pixels are basically assigned into a grid pattern in terms of how they are both encoded and decoded.

So this eliminates the need for "proxy" files, files which are downres'd for editing because your system simply can't play the file in realtime.

The Debayer is 8 levels. And the RED player (as well as software that supports it such as PPro/After Effects, allow you to playback at 100%, 50% 25% 12.5% and so on.

The unique aspect with RED is when your computer does this, it actually isnt lowering the quality, it's just only displaying the x/100 quality you want.

So perhaps my answer is a bit backwards in thinking: But essentially with RED files you have a 1K, 2K, 3K, 4K, 5K, version- all wrapped into 1 file.

Hope this perhaps helps somewhat, even though it's not an answer to the actual question.