[FFmpeg-devel] Matroska shortcomings / DTS (was: GoC 2008 and H264 SVC decoder)
Mon Mar 31 14:56:42 CEST 2008
Le duodi 12 germinal, an CCXVI, Nico Sabbi a ?crit?:
> search Steve Lhomme's posts: he even went as far as
> denying that all the mess needed to disentangle different
> codecs in mkv is a serious problem
This man writes rather a lot on the mailing list, I was not able to find the
particular thread you are referring to yet. For the moment, I have found the
- CPU overhead and implementation complexity;
- muxing overhead, and more specifically muxing overhead compared to NUT for
very low bitrates;
- timestamps accuracy problems.
Richard Felker summarised it that way (2004-04-03 04:08:32 GMT):
# Anyway feel free to correct me if I'm wrong, but I think my complaint
# about Matroska from the beginning wasn't that it was _worse_ than
# existing formats, but rather that it was not sufficiently better, and
# that adopting it would discourage people from adopting a really good
# format (NUT) in the future.
(My opinion is that the main thing that discourage people from adopting NUT
is that the name is not globally unique on Google; and secondarily, that the
official homepage looks so much like vaporware.)
> for all codecs, not only for H264, but H264 also has B-pyramid
> that require a massive frame reordering.
In that case, would it be correct to say it that way: DTS could have been
implemented as a sequence number rather than a timestamp, but it was
convenient to make it somewhat similar to PTS?
Thus a definition: DTS is the latest instant a frame must be fed to the
decoder if it is to be decoded and ready at its PTS.
> There's a nice and long thread in nut-devel (search broadcast)
> that discusses the importance of DTS, PTS and PCR in a multiplex
I found this one:
which is quite instructive.
Thanks for your help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel