Answers.Body: <p>The name for this feature is <a href="https://en.wikipedia.org/wiki/Multiview_Video_Coding" rel="nofollow noreferrer">Multiview Video Coding</a> (MVC):</p>
  
  <blockquote>
    <p>an stereoscopic video coding standard for video compression that
    allows for the efficient encoding of video sequences captured
    simultaneously from multiple camera angles in a single video stream</p>
  </blockquote>
  
  <p>Can't be done, at present. Not using open source tools. There may be academic or commercial encoders that can do this.</p>
  
  <p>In any case, the primary design motivation of MVC is to efficiently compress the two views of a stereoscopic 3D stream, which are very similar to each other. I have my doubts it would be efficient if the camera angles are sufficiently different.</p>
  
  <hr>
  
  <p>In your case, each angle is an independent video stream and is encoded accordingly. The container (Matroska) is simply just that, it packages the data - it has no ability or business to consolidate the data within or among video streams.</p>
  
  <p>It would be the job of the encoder - in this case, x265 - to work with all 3 streams, and produce a single output stream that can store all views efficiently. And the job of a compliant decoder to reproduce those 3 angles if given such an encoded stream. But Handbrake or FFmpeg ..etc don't sport MVC encoders (or decoders).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-31T00:59:44.907Z
Answers.Text: Most of the R&D seems to be going towards compression systems for [light field displays](https://en.wikipedia.org/wiki/Light_field), so there doesn't seem to be any commercial implementation available right now. MVC may come along with that, but it is unclear just how much texture/shading data will be required for those formats to function.
Answers.UserDisplayName: Michael Liebman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-30T05:18:01.530Z
Answers.LastActivityDate: 2017-05-30T05:18:01.530Z
Answers.UserDisplayName: Gyan
Body: <p>I have a DVD (a concert recording) which uses the multi angle feature for 3 different angles. I just encoded it with Handbrake on 3 separate but identical machines (all of the same model and maker, same version of Handbrake and same encoding settings), each encoding a different angle.</p>
  
  <p>My problem: my thought was that mkvmerge would be able to do some deduplication for me where possible, so that where the same group of pictures appears in the streams it would only store it once in the output file, but the sum of all input files is equal to the output file, thus resulting in a file that is as big as the raw data of the DVD.</p>
  
  <p>More background info: Of course the DVD has chapters, if you skip through these, they show identical scenes on all 3 streams, however if you seek a bit further inside the chapter you can see different camera angles. So by just looking at it there is the same and also different content, using Matroska's editions would be very labor intensive and I think I would have to encode the entire thing again once I figured out where all the different scenes are.</p>
  
  <p>How can I achieve a smaller file size in this case? I thought since Matroska incorporates advanced features like VFR that there would also be some way to handle this. Would it help to enable compression in mkvmerge/mkvtoolnix-gui (it has been disabled by default after some releases) or some other Matroska writing library or application, if so where and how?</p>
  
  <p>I just played the output file with VLC, selecting a different video stream opens up a new window for each stream on Ubuntu 16.04, so I can view all 3 angles at the same time (indeed they all show different camera perspectives from time to time), not what I expected or had in mind, but interesting.</p>
  
  <p>Here are the details of the streams:</p>
  
  <pre><code>Video
  Format                                   : HEVC
  Codec                                    : V_MPEGH/ISO/HEVC
  Codec profile                            : Main@L3@Main
  Duration                                 : 01:16:26:00
  Bit rate                                 : 1 983 Kbps
  Width                                    : 694 pixels
  Height                                   : 576 pixels
  Frame rate mode                          : CFR
  Frame rate                               : 25.000 fps
  Frame count                              : 114650
  Colorimetry                              : 4:2:0
  Bit depth                                : 8 bits
  Stream size                              : 1.06 GiB (74%)
  Writing library                          : x265 2.1:[Windows][GCC 5.3.1][64 bit] 8bit
  Encoding settings                        : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=30 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  Color primaries                          : BT.601 PAL
  Transfer characteristics                 : BT.709
  Matrix coefficients                      : BT.601
  
  Video
  Format                                   : HEVC
  Codec                                    : V_MPEGH/ISO/HEVC
  Codec profile                            : Main@L3@Main
  Duration                                 : 01:16:26:00
  Bit rate                                 : 2 095 Kbps
  Width                                    : 694 pixels
  Height                                   : 576 pixels
  Frame rate mode                          : CFR
  Frame rate                               : 25.000 fps
  Frame count                              : 114650
  Colorimetry                              : 4:2:0
  Bit depth                                : 8 bits
  Stream size                              : 1.12 GiB (98%)
  Writing library                          : x265 2.1:[Windows][GCC 5.3.1][64 bit] 8bit
  Encoding settings                        : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=30 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  Color primaries                          : BT.601 PAL
  Transfer characteristics                 : BT.709
  Matrix coefficients                      : BT.601
  
  Video
  Format                                   : HEVC
  Codec                                    : V_MPEGH/ISO/HEVC
  Codec profile                            : Main@L3@Main
  Duration                                 : 01:16:26:00
  Bit rate                                 : 3 143 Kbps
  Width                                    : 694 pixels
  Height                                   : 576 pixels
  Frame rate mode                          : CFR
  Frame rate                               : 25.000 fps
  Frame count                              : 114650
  Colorimetry                              : 4:2:0
  Bit depth                                : 8 bits
  Stream size                              : 1.68 GiB (98%)
  Writing library                          : x265 2.1:[Windows][GCC 5.3.1][64 bit] 8bit
  Encoding settings                        : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=30 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  Color primaries                          : BT.601 PAL
  Transfer characteristics                 : BT.709
  Matrix coefficients                      : BT.601
  </code></pre>
  
  <p>Edit: a good explanation why this cannot work will also be appreciated.</p>
  
Tags: <mkv><h265>
Title: Is there any way to efficently compress multiangle recordings?
UserDisplayName: LiveWireBT
ThreadText: # Is there any way to efficently compress multiangle recordings?
  
  (Asked by: username_0 on 2017-05-29)
  
  I have a DVD (a concert recording) which uses the multi angle feature for 3 different angles. I just encoded it with Handbrake on 3 separate but identical machines (all of the same model and maker, same version of Handbrake and same encoding settings), each encoding a different angle.
  
  My problem: my thought was that mkvmerge would be able to do some deduplication for me where possible, so that where the same group of pictures appears in the streams it would only store it once in the output file, but the sum of all input files is equal to the output file, thus resulting in a file that is as big as the raw data of the DVD.
  
  More background info: Of course the DVD has chapters, if you skip through these, they show identical scenes on all 3 streams, however if you seek a bit further inside the chapter you can see different camera angles. So by just looking at it there is the same and also different content, using Matroska's editions would be very labor intensive and I think I would have to encode the entire thing again once I figured out where all the different scenes are.
  
  How can I achieve a smaller file size in this case? I thought since Matroska incorporates advanced features like VFR that there would also be some way to handle this. Would it help to enable compression in mkvmerge/mkvtoolnix-gui (it has been disabled by default after some releases) or some other Matroska writing library or application, if so where and how?
  
  I just played the output file with VLC, selecting a different video stream opens up a new window for each stream on Ubuntu 16.04, so I can view all 3 angles at the same time (indeed they all show different camera perspectives from time to time), not what I expected or had in mind, but interesting.
  
  Here are the details of the streams:
  
  ```
  Video
  Format                                   : HEVC
  Codec                                    : V_MPEGH/ISO/HEVC
  Codec profile                            : Main@L3@Main
  Duration                                 : 01:16:26:00
  Bit rate                                 : 1 983 Kbps
  Width                                    : 694 pixels
  Height                                   : 576 pixels
  Frame rate mode                          : CFR
  Frame rate                               : 25.000 fps
  Frame count                              : 114650
  Colorimetry                              : 4:2:0
  Bit depth                                : 8 bits
  Stream size                              : 1.06 GiB (74%)
  Writing library                          : x265 2.1:[Windows][GCC 5.3.1][64 bit] 8bit
  Encoding settings                        : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=30 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  Color primaries                          : BT.601 PAL
  Transfer characteristics                 : BT.709
  Matrix coefficients                      : BT.601
  
  Video
  Format                                   : HEVC
  Codec                                    : V_MPEGH/ISO/HEVC
  Codec profile                            : Main@L3@Main
  Duration                                 : 01:16:26:00
  Bit rate                                 : 2 095 Kbps
  Width                                    : 694 pixels
  Height                                   : 576 pixels
  Frame rate mode                          : CFR
  Frame rate                               : 25.000 fps
  Frame count                              : 114650
  Colorimetry                              : 4:2:0
  Bit depth                                : 8 bits
  Stream size                              : 1.12 GiB (98%)
  Writing library                          : x265 2.1:[Windows][GCC 5.3.1][64 bit] 8bit
  Encoding settings                        : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=30 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  Color primaries                          : BT.601 PAL
  Transfer characteristics                 : BT.709
  Matrix coefficients                      : BT.601
  
  Video
  Format                                   : HEVC
  Codec                                    : V_MPEGH/ISO/HEVC
  Codec profile                            : Main@L3@Main
  Duration                                 : 01:16:26:00
  Bit rate                                 : 3 143 Kbps
  Width                                    : 694 pixels
  Height                                   : 576 pixels
  Frame rate mode                          : CFR
  Frame rate                               : 25.000 fps
  Frame count                              : 114650
  Colorimetry                              : 4:2:0
  Bit depth                                : 8 bits
  Stream size                              : 1.68 GiB (98%)
  Writing library                          : x265 2.1:[Windows][GCC 5.3.1][64 bit] 8bit
  Encoding settings                        : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=30 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  Color primaries                          : BT.601 PAL
  Transfer characteristics                 : BT.709
  Matrix coefficients                      : BT.601
  
  ```
  
  Edit: a good explanation why this cannot work will also be appreciated.
  
  **Tags:** mkv, h265
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-05-30. Score: 2
  
  The name for this feature is [Multiview Video Coding](https://en.wikipedia.org/wiki/Multiview_Video_Coding) (MVC):
  
  > an stereoscopic video coding standard for video compression that
  > allows for the efficient encoding of video sequences captured
  > simultaneously from multiple camera angles in a single video stream
  
  Can't be done, at present. Not using open source tools. There may be academic or commercial encoders that can do this.
  
  In any case, the primary design motivation of MVC is to efficiently compress the two views of a stereoscopic 3D stream, which are very similar to each other. I have my doubts it would be efficient if the camera angles are sufficiently different.
  
  ---
  
  In your case, each angle is an independent video stream and is encoded accordingly. The container (Matroska) is simply just that, it packages the data - it has no ability or business to consolidate the data within or among video streams.
  
  It would be the job of the encoder - in this case, x265 - to work with all 3 streams, and produce a single output stream that can store all views efficiently. And the job of a compliant decoder to reproduce those 3 angles if given such an encoded stream. But Handbrake or FFmpeg ..etc don't sport MVC encoders (or decoders).
  
  > **Comments:**
  > **username_2**: Most of the R&D seems to be going towards compression systems for [light field displays](https://en.wikipedia.org/wiki/Light_field), so there doesn't seem to be any commercial implementation available right now. MVC may come along with that, but it is unclear just how much texture/shading data will be required for those formats to function.  
  
  ---
  
  