[Ffmpeg-cvslog] r8334 - trunk/libavformat/matroska.c

Michael Niedermayer michaelni
Thu Mar 15 23:56:33 CET 2007


On Thu, Mar 15, 2007 at 02:05:18PM -0600, Loren Merritt wrote:
> On Thu, 15 Mar 2007, Michael Niedermayer wrote:
> >On Thu, Mar 15, 2007 at 04:03:26PM +0100, Clemens Ladisch wrote:
> >>M?ns Rullg?rd wrote:
> >>>Rich Felker <dalias at aerifal.cx> writes:
> >>>>why can't you just use the max pyramid depth and the nut algorithm to
> >>>>get dts??
> >>>
> >>>How do you find the pyramid depth?
> >>
> >>num_reorder_frames in the SPS
> >
> >num_reorder_frames is optional, what do you do if its not there?
> When the num_reorder_frames syntax element is not present, the value of
> num_reorder_frames value shall be inferred to be equal to
> max_dec_frame_buffering.
> When the max_dec_frame_buffering syntax element is not present, the
> value of max_dec_frame_buffering shall be inferred to be equal to
> MaxDpbSize.
> MaxDpbSize is specified as a function of Level, which is not optional.
> Or, since using a larger than necessary buffer will only waste memory
> not change the result, you can ignore the chain of fallbacks and just
> use 16 which is the max allowed value.

well it will change the dts values the frames get, one case where this
would be fatal is avi, if the muxer-encoder assumtation differs from the
demxuer-decoder side you end up with AV-desync, current non compliant
"buffer as little as possible" behavior does AFAIK not lead to much
AV-sync issues, so changing it to 16 will have to cause AV-sync for
h.264 in avi to break

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20070315/8bd16583/attachment.pgp>

More information about the ffmpeg-cvslog mailing list