[FFmpeg-devel] [RFC] mpegts: Provide a monotonic timestamp to the outside world
michaelni at gmx.at
Fri Oct 26 02:00:07 CEST 2012
On Wed, Oct 24, 2012 at 09:20:07PM +0200, Harald Axmann wrote:
> On 23.10.2012 03:59, Michael Niedermayer wrote:
> >On Mon, Oct 22, 2012 at 11:39:34PM +0200, Harald Axmann wrote:
> >>But just as a fundamental question: Is there any reason to keep the
> >>original time stamp, as Hendrik Leppkes requested. [...]
> >assume you have external references to timestamps, or you want to
> >cut and then merge pieces of TS without timestamps changing
> >or you have a audio and a video TS file and want them syncronized
> >against each other (assuming their timestamps allow this)
> >i guess there are many other cases ...
> Okay, I understand.
> On Mon, Oct 22, 2012 at 11:39:34PM +0200, Harald Axmann wrote:
> >What I could do is have a look if it is possible to change XBMC's
> >seeking algorithm to a byte-based version for file formats
> >allowing discontinuities. Perhaps this would be the cleanest
> >solution for XBMC.
> I had a look at the seeking algorithm in FFmpeg. XBMC calls
> av_seek_frame, which then decides to use time based search, not byte
> based (AVSEEK_FLAG_BYTE not set for mpegts). So I conclude that for
> a proper TS file time based search is yet adequate.
> So we could try to find a basic solution, which does not break
> anything and fixes seeking for proper TS files (with PCR wrap) at
> least. Before I prepared the code to patch the mpegts time stamp, I
> proposed a fix of ff_gen_search, which adds time stamp wrapping
> there (see the attached patch). It was dropped, because it breaks
> the index.
> On Sun Aug 19 17:09:31 CEST 2012, Michael Niedermayer wrote:
> >the first problem is the index (see av_index* and ff_seek_frame_binary)
> >it is required to be ordered and it wont be for such files.
> In fact XBMC uses an older version of FFmpeg, which never builds an
> index for mpegts, as I read the code. So the problem never showed
> up. Anyway I think that it is reasonable to add wrapping to
> ff_gen_search. After all it does not make sense to search for time
> stamp, that cannot even exist in the file.
> Of course for the current state of FFmpeg we would have to find a
> solution for the index. I will have a look at it.
> What do think of this proposal in general?
I think the easiest way to support a single wrap is to fix the
output from ->read_timestamp() and ->read_packet() so it doesnt wrap.
This fixup should also not change the lower bits that are known, just
fill in the higher ones so as to avoid wraping.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel