[MPlayer-dev-eng] Re: [PATCH] dvr-ms fixes for pts, key frame detection and seeking
Uoti Urpala
uoti.urpala at pp1.inet.fi
Fri Feb 9 02:01:19 CET 2007
On Thu, 2007-02-08 at 18:24 -0500, Rich Felker wrote:
> On Fri, Feb 09, 2007 at 01:02:43AM +0200, Uoti Urpala wrote:
> > What is there to "fix" for laced mkv? Lacing audio packets with a
> > timestamp only for the first one does not cause any problems for
> > playback.
>
> By this same argument, omitting all timestamps for audio doesn't cause
> any problem because you can just start from the beginning and count
> samples... Obviously this is nonsense though.
Lumping all audio together in a way that doesn't allow you to seek to
the middle would be nonsense. If you lace silly amounts of packets
together that will interfere with seeking (like rare keyframes for
video), but it's not really the lack of timestamps that is the problem
in this case.
> Having correct
> timestamps is requisite for frame-precise seeking and in general it
> will simplify the "correct pts" overhaul of the playback loop if all
> frames have timestamps, rather than just some random subset having
> timestamps. Also...
There isn't anything really important missing from the audio timing in
the playback loop IMO, though some individual decoders and AOs could be
improved. The playback code needs to know a timestamp for an arbitrary
position in the audio output stream; the only simplication you could get
from having a timestamp for every packet would be dropping the "has a
timestamp" test from "bytes since the last position corresponding to the
start of an encoded packet that had a timestamp". If packets without
timestamps would occur as the first packet after seeking it would cause
problems, but that doesn't happen with lacing.
> > It could complicate things if you try to remux into a
> > container which is unable to handle such streams, but given MEncoder's
> > current state that's not too relevant.
>
> ...MEncoder will never work if we keep the attitude of not fixing
> problems because MEncoder is broken anyway.
I don't think the reason for not fixing it is "because it's broken
anyway", rather it just seems that none of the developers is currently
interested in working on it. I'm not sure whether the current MEncoder
code base is even all that useful if the goal is to develop a
"well-behaved" encoder. For that it might be better to
cleanup/reorganize MPlayer so that the encoder can use more of the same
code; trying to keep the current MEncoder code working during that just
makes it harder.
> Originally you were the
> one working to fix the broken system and use pts correctly
I haven't worked to fix it in MEncoder so far.
More information about the MPlayer-dev-eng
mailing list