[FFmpeg-devel] [RFC] DVB teletext and PTS

[Michael Niedermayer]

On Sun, Sep 23, 2012 at 10:58:22AM +0200, Reimar Döffinger wrote:
> On 23 Sep 2012, at 04:16, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sat, Sep 15, 2012 at 04:29:02PM +0200, Reimar Döffinger wrote:
> >> Hello,
> >> when specifying PTS handling for DVB teletext they made quite a mess it
> >> seems (see Annex A of ETSI EN 300 472), which resulted in some stations
> >> not using sensible PTS values (for example for ORF the teletext PTS
> >> values seem to indicate a time multiple hours after the video time,
> >> I have a ORF1HD.ts sample here but I don't remember where exactly it
> >> is from).
> >> For ordinary teletext, processing them straight away works fine, but
> >> will completely mess up teletext based subtitles.
> >> This will work for hardware decoders, because at the same time a
> >> "maximum retention time" of 40 ms was specified.
> >> Now the question is: how should we handle this? Would a patch/hack that
> >> limits DVB teletext time stamps to last stream ts + 40 ms be acceptable for
> >> example? It's not really accurate since it should be next ts + 40 ms
> >> though, and quite hacky. But I can't really think of anything better.
> > 
> > sounds reasonable, but i dont understand the prev/next ts issue
> > what ts is this ? pcr ? dts ? something more complex ?
> 
> Well what I guessed from the specification is that they mean real time received + 40 ms.
> But we can't specify such a time stamp.
> Since this is just a "make sure things do not break too badly" mechanism and also since I believe the VBI info usually is stored before the frame it belonged to, making it relative to the following frame dts seemed most reasonable to me.
> In practice, I guess just using the last and maybe increasing the margin to a few more frames, like 80 ms, would probably work perfectly fine as well, and more along the lines of "avoid breaking good files for the benefit of broken files".
> But I don't really know, which is why I am asking for comments :-)

The way i interpret at ATM:

Audio/Video/Text is received at the PCR it then enters various buffers
and the teletext has a maximum retention time of 40ms in the last
buffer, that may be before, at or after the video pts as video
itself has buffers too
if we simplify the small and apparently quickly emptied buffer a bit
that leaves a approximate DTS=PTS && DTS > PCR && DTS < PCR+40.6ms
which would allow filling in PTS/DTS based on PCRs associated with the
first byte of each teletext packet i think

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- 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/20120923/c23971d8/attachment.asc>