Incorrect teletext to vtt subtitle timing

[geutzu]

System info

Rocky Linux release 9.3 (Blue Onyx) v2.6.1-74-g9be7c2b1ac

Issue and steps to reproduce the problem

map from encoder to multicast: udp://239.99.99.40:10010 the following streams:

Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn Stream #0:10x101: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 96 kb/s Stream #0:20x102: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 95 kb/s Stream #0:30x103: Subtitle: dvb_teletext ([6][0][0][0] / 0x0006), 492x250

Packager Command: packager -v 1 --dump_stream_info \ 'in=udp://239.99.99.40:10010?buffer_size=100000&reuse=1,stream=1,segment_template=stream/aac_1spa$Number$.aac,playlist_name=stream/audio_es.m3u8,language=es,hls_group_id=audio,hls_only=1' \ 'in=udp://239.99.99.40:10010?buffer_size=100000&reuse=1,stream=2,segment_template=stream/aac_2eng$Number$.aac,playlist_name=stream/audio_en.m3u8,language=en,hls_group_id=audio,hls_only=1' \ 'in=udp://239.99.99.40:10010?buffer_size=100000&reuse=1,stream=0,segment_template=stream/h264720p$Number$.ts,playlist_name=stream/video_hd.m3u8,hls_group_id=video,hls_only=1' \ 'in=udp://239.99.99.40:10010?buffer_size=100000&reuse=1,stream=3,cc_index=801,segment_template=stream/subtitlespa$Number$.vtt,playlist_name=stream/capitons_spa.m3u8,language=spa,hls_group_id=text,hls_only=1,hls_name=SPANISH' \ 'in=udp://239.99.99.40:10010?buffer_size=100000&reuse=1,stream=3,cc_index=802,segment_template=stream/subtitleeng$Number$.vtt,playlist_name=stream/capitons_eng.m3u8,language=eng,hls_group_id=text,hls_only=1,hls_name=ENGLISH' \ --preserved_segments_outside_live_window='15' --time_shift_buffer_depth='30' --segment_duration='6' --default_language='spa' --hls_playlist_type='LIVE' --hls_master_playlist_output 'stream/index.m3u8'

Extra steps to reproduce the problem? (1) - start encoder ( record/monitor the PTS values ) (2) a) if i start the packager in a few seconds when the PTS form the transcoder starts at 0 i get the right number at the segments 1,2,3 .. for each stream

• in this case the problem is that the CUE timings in the .vtt files is wrong :

Example: WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:9000

09:16:44.400 --> 09:21:00.000 align:center No one has claimed responsibility for the explosion

09:21:14.400 --> 09:25:55.200 align:center at this isolated farmhouse

09:26:09.600 --> 09:31:26.400 align:center But with early reports indicating the house previously belonged

It is impossible to be 09:16:44.400 to 09:31:26.400 in a 6 second segment and also the Timings should start at 00:00:xx:yyy and be within 6 second interval, i can confirm that the input PTS is on all streams in sync, and other tools generate the correct timings.

b) if i restart the packager after a few minutes i get the same problems but with a twist, the packager creates 1000's of vtt files and deletes them in an instant to keep the number of segments to the specified value 15 ; this happens until an arbitrary high number ( i think is PTS in seconds / 6 ( the segment length specified ); also the CUE in the vtt files is too big to >1500 hours

What is the expected result?

The packager should keep the vtt CUE timings correct. I verified that the source content is correct with other tools and all seems OK on many of the channels that i have access to.

Input is from multicast TV channels from multiple country transcoded with ffmpeg and the teletext stream is map "as is" with no modifications.

[jakubvojacek]

Hello

I can confirm this is happening (not only for DVB subs but also for standard subs provided by VTT file)

Tested with the latest release (6bff14f) and thousands and thousands of VTT files appear. I think its because the stream/subtitles are not starting from time zero. So if I start packager with stream that has already time 1000seconds and my segment length is 1000, it will create 1000 files.

Because you cannot always start packager at the same time as encoder, I think packager should be able to ignore the subtitles cues that are before audio/video time.

Thank you

[tobbee]

@geutzu and others looking into solving this issue.

Regarding the WebVTT subtitle output you refer to, it is not obvious that the timestamps of 9hours and 21 minutes are wrong. This is because they are relative to MPEG-2 TS X-TIMESTAMP-MAP value of 0. If the PTS timestamps in the video and audio segments are around 2948400000, corresponding to 9hours and 21 minutes in the 90kHz PTS clock, the timing relative to the X-TIMESTAMP-MAP may be correct.

That is not very useful though, especially since the PTS timestamps wrap around after approximately 26.5hours. It would therefore be better that the X-TIME-STAMP-MAP has a value that corresponds to the PTS value of the start of the segment, and that the WebVTT timestamps are relative to that reference. That would essentially mean that the timestamps in a segment are relative to the segment start. I think this is the most viable way to make it possible to serve a live HLS streams with WebVTT segments for a longer period where PTS wrap around is bound to happen.

To solve this issue, I think it would be good to look into how the X-TIMESTAMP-MAP value is generated and how the MPEG-TS timestamps reference is propagated with the subtitle data. From a quick scan of the source code it seems that X-TIMESTAMP-MAP always has a zero value X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:9000. The timescale at the end is also lacking one zero in order to be useful for non-zero cases.

[Nixon197]

I can confirm that this issue makes live HLS subtitling with teletext input on release 3.1 not working.