[MPlayer-dev-eng] Re: [PATCH] dvr-ms fixes for pts, key frame detection and seeking

[John Donaghy]

>
> > > Starting the pts from that of the first audio frame would at least be
> a
> > > better guess. Are the sync issues caused by starting from 0 any worse
> > > than with the video.c change? I think they should be the same...
> >
> >
> > Do you mean start at zero and then adjust all pts values in the file
> > downwards by the amount found in the first large one (roughly speaking)?
> If
>
> I'm not sure what you're replying to, since it doesn't seem to match
> either sentence you quoted... By the first sentence I meant starting
> from the pts of adjacent audio packets. In the second sentence I meant
> to ask about the start-from-zero version you already implemented vs
> video.c change.
>

I guess I was trying to get clarification about what you meant in the second
sentence. If I start from 0 then I get very noticeable sync errors
immediately on some files but on many others it is fine. Maybe there's a way
to fix it for all files and I'll probably I'll look into it further. So, it
is better when I change video.c for some samples, but as you said, maybe
that change will cause sync problems on longer files. Most of the clips I
have are pretty short.

 Regarding starting from the first audio frame, I cant see a way to do this
unless I throw away all video frames encountered before the first audio.


> Yes, if the stream starts with non-key frames those cannot be properly
> decoded anyway. If all key frames always have a correct pts value and
> known fps from the frame onwards that should allow generating sane
> timestamps.


So, if I have to discard any frames I might as well discard everything up to
the first I-frame and just use the timestamps directly from the
file.Thisnow seems like the most straight forward approach to me.

Thanks for all the feedback. I'm learning a bit more each time.

John