[MPlayer-dev-eng] mp4, vfr and timestamps

[Michael Niedermayer]

Hi

On Fri, Jun 16, 2006 at 01:19:48PM +0200, Tomas Carnecky wrote:
> Uoti Urpala wrote:
> > What kind of logic is that? How do you get from MPlayer not reading some
> > parts of the file to the belief that the file isn't invalid?
> > 
> 
> Quote (from the pdf):
> The composition time to sample table is optional and must only be
> present if DT and CT differ for any samples.
> 
> I didn't came up with the idea that my file is invalid, it was Michael.
> I think my file is perfectly valid, it's just mplayer isn't reading all
> the required informations that are needed to replay the video correctly.
> But I haven't read enough of the standard to be able to tell whether
> this behavior is allowed or not.

the DTS specifies when a frame is decoded, CTS specifies when it is presented
to the user, your file says decode 100 frames in 10ms and then show them in
8 seconds, this alone should show to any remotely sane person that something
is wrong, todays hardware cant decode this in 10ms ...

for the case of mpeg1, mpeg2 and mpeg4 video there is a very
simle rule how PTS/CTS must be set (no frame reordering CTS=DTS, frame reordering
CTS=DTS for B frames, CTS of non B frames = DTS of next non B frame)
for H.264 the rules are more complex, you can look at the h.264 spec if you
like, but i dont think that in any case can CTS & DTS be shifted by 100 frames
the buffering constraints on h.264 should prevent it

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is