[FFmpeg-devel] [RFC] DVB teletext and PTS
kierank at ob-encoder.com
Sun Sep 23 16:10:10 CEST 2012
On Sun, Sep 23, 2012 at 3:58 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> 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:
>>> 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.
That's not correct, the following frame DTS is almost certainly not
the corresponding video frame because of the VBV.
You probably have to give it the timestamp: interpolated PCR+offset
such that buffers do not overflow.
More information about the ffmpeg-devel