<p>Advanced Authoring Format (AAF) and some MXF operational patterns (OP-2a, 2b, 3a, and 3b) <em>should</em> 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.</p>

CC BY-SA 3.0
2016-05-05T22:08:28.150Z
2016-05-05T22:08:28.150Z
Michael Liebman
<p>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. </p>

<p>I own a RED Epic. It shoots at up to 5K 100 FPS. </p>

<p>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. </p>

<p>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. </p>

<p>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. </p>

<p>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. </p>

<p>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. </p>

<p>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. </p>

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

CC BY-SA 3.0
2016-05-02T20:40:17.360Z
This "answer" does not actually the question that was asked.  It does not address how to handle the problem generally (one cannot transcode from any random video format into RED RAW).  And to my knowledge, one cannot change RED debayer/compression parameters on the fly as a dynamic property of RED media.
Michael Tiemann
CC BY-SA 3.0
2016-05-03T00:06:50.347Z
More an ex-course into file-formats, but anyway thank you for the effort.
isync
CC BY-SA 3.0
2016-05-15T07:53:06.063Z
I believe I said clearly that it was not changing the "debayer/compression" parameters; meerly the playback of such. I also specified that the answer does not directly relate to the question, moreso the "concept".
McFlySoHigh
CC BY-SA 3.0
2016-05-02T19:22:22.413Z
2016-05-02T19:22:22.413Z
McFlySoHigh
<p>If the <strong>only</strong> difference is bitrate, then any container which accepts variable bitrate streams, will fulfill your requirement e.g. MP4, MKV..etc</p>

<p>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 <a href="https://ffmpeg.org/download.html" rel="nofollow noreferrer">ffmpeg</a>,</p>

<pre><code>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
</code></pre>

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

<p>Prepare a text file</p>

<pre><code>file 'seg1.mp4'
file 'seg2.mp4'
file 'seg3.mp4'
</code></pre>

<p>and then</p>

<pre><code>ffmpeg -f concat -i list.txt -c copy joined.mp4
</code></pre>

<hr>

<p>Clips with different properties, like resolution, can be joined together as well into one MP4, but compatibility across media players is <a href="https://video.stackexchange.com/q/17071/1871">iffy</a>, and ffmpeg won't do it reliably at present, anyway.</p>

CC BY-SA 3.0
2016-05-02T12:21:24.593Z
Interesting! I've always had another conception of what VBR is and does, in terms of "granularity". Will try that.   Also, I'll wait a little more until I'll probably mark your answer the as the accepted one
isync
CC BY-SA 3.0
2016-05-02T13:07:12.493Z
After trying it, and finding it works (both, vbr and even variable size), I've found a minor problem: When I edit-out one segment "as-is" with "-vcodec copy", the concat will report 1. "Auto-inserting h264_mp4toannexb bitstream filter" (seems fine), 2. "Non-monotonous DTS in output stream" (arg!!) for that segment. Is there a way to do a stream copy (no re-encoding), but stripping time-stamps. As I understand it, filtering the output/this segment in such a way would fix this DTS error (although the video plays anyway).
isync
CC BY-SA 3.0
2016-05-02T14:23:48.837Z
ffmpeg, by default, generates new timestamps, unless you use the segment muxers or supply a flag like `copyts`. What command are you getting the error with?
Gyan
CC BY-SA 3.0
2016-05-02T16:34:39.160Z
Command is what you suggested: `ffmpeg -f concat -i list.txt -c copy joined.mp4`, and the example segment commands, only the middle one altered to be `... -i input.mp4 -vcodec copy seg2.mp4`. Tested with ffmpeg 2.8.1, my Ubuntu avconv doesn't know about concat yet.
isync
CC BY-SA 3.0
2016-05-02T16:44:11.023Z
Ah. With stream copy, cutting isn't exact. You'll have to insert `-avoid_negative_ts make_zero` but you'll likely get some repeat with the prior segment.
Gyan
CC BY-SA 3.0
2016-05-02T17:02:37.923Z
On the segmenting or the concat step? Tried both. One variant even gave me an added "Packet with invalid duration" error. Sorry for this here becoming a thread... Also, `make_zero` is the value for the `-avoid_negative_ts` switch, right. Where're the docs for it?
isync
CC BY-SA 3.0
2016-05-02T17:08:53.027Z
I had limited success with adding `-copyts -start_at_zero` on each segmenting, no more DTS warning on concat but video didn't play right.
isync
CC BY-SA 3.0
2016-05-02T17:15:37.970Z
If you're re-encoding, you don't need those flags. If you aren't those two won't help. Do you intend to segment the entire file?
Gyan
CC BY-SA 3.0
2016-05-02T17:26:19.617Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/39189/discussion-between-isync-and-mulvya).
isync
CC BY-SA 3.0
2016-05-02T17:36:34.723Z
I'm right now pasting commands to reproduce, in chat
isync
CC BY-SA 3.0
2016-05-02T06:33:54.907Z
2016-05-02T06:33:54.907Z
2017-04-13T12:46:08.110Z
Gyan
<p>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.</p>

<p><a href="https://i.sstatic.net/RtHvn.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/RtHvn.jpg" alt="enter image description here"></a></p>

<p>Now, is there a video container format out there which is able to "glue" these different parts together into <em>one file</em>? 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?</p>

<p>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.</p>

<p>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?</p>

<p>What I'm looking for is <a href="https://en.wikipedia.org/wiki/Region_of_interest" rel="nofollow noreferrer">region-of-interest</a> adapted quality, something image formats like <a href="https://en.wikipedia.org/wiki/JPEG_2000" rel="nofollow noreferrer">JPEG2000</a> offer for spatial areas, only here applied to video over time.</p>

<p>Any suggestions or ideas?</p>

<blockquote>
  <p>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.</p>
</blockquote>

<video><editing><file-formats><transcoding><matroska>
Is there a video container which is able to handle segments of different video quality (or even size)?
isync
# Is there a video container which is able to handle segments of different video quality (or even size)?

(Asked by: username_0 on 2016-05-01)

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.

[![enter image description here](https://i.sstatic.net/RtHvn.jpg)](https://i.sstatic.net/RtHvn.jpg)

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](https://en.wikipedia.org/wiki/Region_of_interest) adapted quality, something image formats like [JPEG2000](https://en.wikipedia.org/wiki/JPEG_2000) 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.

**Tags:** video, editing, file-formats, transcoding, matroska


---

## 3 answers

### Answer by username_4 on 2016-05-02. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_0**: Interesting! I've always had another conception of what VBR is and does, in terms of "granularity". Will try that.   Also, I'll wait a little more until I'll probably mark your answer the as the accepted one  
> **username_0**: After trying it, and finding it works (both, vbr and even variable size), I've found a minor problem: When I edit-out one segment "as-is" with "-vcodec copy", the concat will report 1. "Auto-inserting h264_mp4toannexb bitstream filter" (seems fine), 2. "Non-monotonous DTS in output stream" (arg!!) for that segment. Is there a way to do a stream copy (no re-encoding), but stripping time-stamps. As I understand it, filtering the output/this segment in such a way would fix this DTS error (although the video plays anyway).  
> **username_4**: ffmpeg, by default, generates new timestamps, unless you use the segment muxers or supply a flag like `copyts`. What command are you getting the error with?  
> **username_0**: Command is what you suggested: `ffmpeg -f concat -i list.txt -c copy joined.mp4`, and the example segment commands, only the middle one altered to be `... -i input.mp4 -vcodec copy seg2.mp4`. Tested with ffmpeg 2.8.1, my Ubuntu avconv doesn't know about concat yet.  
> **username_4**: Ah. With stream copy, cutting isn't exact. You'll have to insert `-avoid_negative_ts make_zero` but you'll likely get some repeat with the prior segment.  
> **username_0**: On the segmenting or the concat step? Tried both. One variant even gave me an added "Packet with invalid duration" error. Sorry for this here becoming a thread... Also, `make_zero` is the value for the `-avoid_negative_ts` switch, right. Where're the docs for it?  
> **username_0**: I had limited success with adding `-copyts -start_at_zero` on each segmenting, no more DTS warning on concat but video didn't play right.  
> **username_4**: If you're re-encoding, you don't need those flags. If you aren't those two won't help. Do you intend to segment the entire file?  
> **username_0**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/39189/discussion-between-username_0-and-mulvya).  
> **username_0**: I'm right now pasting commands to reproduce, in chat  

---

### Answer by username_1 on 2016-05-05. Score: 1

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 by username_2 on 2016-05-02. Score: -1

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.

> **Comments:**
> **username_3**: This "answer" does not actually the question that was asked.  It does not address how to handle the problem generally (one cannot transcode from any random video format into RED RAW).  And to my knowledge, one cannot change RED debayer/compression parameters on the fly as a dynamic property of RED media.  
> **username_0**: More an ex-course into file-formats, but anyway thank you for the effort.  
> **username_2**: I believe I said clearly that it was not changing the "debayer/compression" parameters; meerly the playback of such. I also specified that the answer does not directly relate to the question, moreso the "concept".  

---

