[Matroska-devel] Mappings for HEVC/H.265 in Matroska
moritz at bunkus.org
Thu Jun 6 17:02:43 CEST 2013
I'll be out of town until Sunday. Therefore just a random thought that
popped into my head when reading it:
mkvmerge already discards filler NALUs in AVC (and MPEG-1/2 video),
and I will definitely want to continue doing that with HEVC.
1:1 bitstream identity before muxing/after extraction is definitely
not my goal, never has been. Invalid byte sequences (e.g. if the
stream does not start with 0x0000001) will be discarded as well.
No invalid data in Matroska!
On 6/6/13, Jan Ekstrom <jeebjp at gmail.com> wrote:
> On Thu, Jun 6, 2013 at 5:20 PM, Hendrik Leppkes <h.leppkes at gmail.com>
>> Any decoder that wants to play HEVC Annex B elementary streams, or
>> muxed in transport streams, will need to support in-band
>> reconfiguration, so it would seem to be the logical choice to keep the
>> update NALs inside the bitstream for highest compatibility.
>> If a muxer wants, it could copy them into CodecState (even if i really
>> don't see the point of that), but it should definitely leave them in
>> the bitstream.
>> Also, in my opinion the format should not dictate any constraints if a
>> specific NAL is allowed to be muxed - even if its useless.
>> A smart muxer can always opt to skip them and reduce file size.
> Alrighty, I most definitely do not disagree on either point. Just that
> I noticed the CodecState structure some time ago with regards to
> MPEG-2 video, and decided to see how its usage with HEVC would be
> viewed. The latter point I mostly brought up because a certain other
> container decided to ban all kinds of padding when muxing AVC into it,
> so I was interested if anyone would prefer something like that with
> Matroska as well. My personal opinion is quite similar to madshi's.
> Jan Ekström
> I'm human - no debug
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane:
More information about the Matroska-devel