[FFmpeg-devel] [RFC] mpegts: Provide a monotonic timestamp to the outside world
Michael Niedermayer
michaelni at gmx.at
Mon Oct 22 15:49:59 CEST 2012
On Mon, Oct 22, 2012 at 08:04:11AM +0000, Joakim Plate wrote:
> Hendrik Leppkes <h.leppkes <at> gmail.com> writes:
>
> > Hi,
> >
> > I handle the wrapping in my application directly, and IMHO thats the
> > proper thing to do. The demuxer should expose the timestamps as they
> > are specified in the file, and anyone trying to consume a MPEG-TS file
> > needs to be able to deal with these kinds of timestamps (timestamps in
> > MPEG-TS are not really guaranteed to be fully continuous, i have
> > plenty samples where it just jumps around in the middle of the
> > stream).
> > If any such hacky mode is added to "invent" new timestamps, it should
> > be purely optional (controlled by a private option, for example), and
> > not be enabled by default.
> >
>
> While I technically agree, this implies that the seeking code in ffmpeg could
> handle wrapping timestamps, which it currently can't (real cause of this patch,
> since flat playback works fine).
>
> I do agree it probably have to be optional to get the original timestamps out.
yes and
Supporting seeking per time with timestamp discontinuous files would
be nice to have but its not so easy as this patch.
It should be outside any single demuxer as its not just mpegts, it
should be optional and it should handle more than 1 timestamp
discontinuity.
In practice this would require keeping track of all encountered
discontinuities and adjusting timestamps according to that list.
That is both what is output and for and during seeking.
The price one has to pay for such a feature would be that if its
enabled timestamp would not be guranteed to be stable, that is when
one seeks to the end one gets a timestamp E and if one now seeks back
to the begin and plays the whole file then any subsequent seeks to the
end could easily result in different value from E when more
discontinuities where encountered between
id also suggest to put this new code in a seperate file as utils.c
is a little big already.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121022/6929393c/attachment.asc>
More information about the ffmpeg-devel
mailing list