[Matroska-devel] Mappings for HEVC/H.265 in Matroska

Jan Ekstrom jeebjp at gmail.com
Thu Jun 6 15:06:49 CEST 2013

On Mon, Apr 29, 2013 at 4:15 PM, Denis Charmet <typx at dinauz.org> wrote:
> One other problematic point for me would be: how to deal with frames
> split around multiple tiles/slices, it isn't a problem per se for normal
> playback but in case of seek it could be difficult if we just catch one
> tile/slice. Should only the first one tagged as keyframe to avoid
> skipping to a bad one?

Yes, I would guess in cases where a picture consists of multiple
units, only the first unit in the coding order should be marked as a
keyframe so that a parser would not try to start pushing samples to
the decoder from the possibly not first part of the picture.

Also, I just quickly looked through DivX's short RFC for
HEVC-in-Matroska ( http://labs.divx.com/node/127907 ) , and in general
it looks good. Regarding the CodecPrivate, the number of possible VPS
at a given time seems to match (IDs 0-15 -> maximum of 16 different
ones), but I've not yet checked the maximum of amount of PPS/SPS at a
given time (their documented variable is a ue(v), which IIRC not
specified in output length). My random guess before checking would be
that 31 for SPS, and 255 for PPS should be enough, though.

This then takes us to parameter set updates: Should these be handled
in the stream, or should a CodecState element be used? Also, should
FD_NUT be an acceptable NAL unit to be muxed in? Furthermore,
something should be noted regarding pictures where pic_output_flag
equals zero, as those pictures would only need a DTS and no PTS. The
actual not showing would be done by the decoder, and no other extra
information would be needed on the container's side of course. I think
VP9 had something similar, how is this signaled or planned to be
signaled there?

Regarding the code released on the related github repository (
https://github.com/jaya-divx/mkvtoolnix ), I haven't yet had the
chance to look too much into it, but I had to change two cases of
src/output/p_hevc.cpp and p_hevc_es.cpp to enable it to build. Also,
looking at an mkvinfo -v dump of a sample I muxed, quite a few
B-frames in it are flagged as discardable. The Matroska specification
only notes "The frames of the Block can be discarded during playing if
needed", so I am interested in what sense it is used with HEVC.
Additionally it seems that one has to set --default-duration to half
of the wanted value in order to get correct timestamps when muxing in
HEVC Annex B streams with a value like 24000/1001p or fps. There seems
to be some overriding of the timecode factory, so I would guess that
something is going a bit awry around there.

And... that seems to be it, no further questions or ideas so far.

Jan Ekström

I'm human - no debug

More information about the Matroska-devel mailing list