-
Notifications
You must be signed in to change notification settings - Fork 516
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EBU Teletext in MPEG-TS (#1344) is not working correctly now #1428
Comments
2ba67bc It seems we need to specify text zero bias to more than default zero (for example 10 minutes) to get teletext working
|
@acris5 I'm working on improving the segment generation for live teletext in MPEG-2 TS. One of the issues I found is that the In any case, it is not correct in the sense that it does not check the timescale that is 90000 for the teletext subtitles, but is considered to be 1000. Since the incoming timestamps can be arbitrary, I think that all type of start time determination algorithm should be turned off for live TS input. In any case, it would be good to have a solution that makes things work for live TS subtitles. For live text segmentation from MPEG-2 TS, there are two other major problems that I'm working with.
To fix the first problem, I first try to extract heart beats (stuffing data with PTS) from the teletext PID, and then I've added a configuration to send heartbeats from other elementary stream in the same demuxer. In the latter case, they have a configurable timestamp shift in order to wait for subtitle cues to be included. To fix the second issue, I'm looking into sending the cue content as the cue start, but with duration 0, and then later send the end time. Then the text chunker can produce a segment without waiting for the end of the cue, and just let it go on to the end of the segment. This is a bit trickier, so it will take some time before I have it working. If you have any ideas about other ways to go, please let me know. |
Hi Many thanks for posting your messages; I am integrating shaka-packager as a library and was facing similar issues with live TS stream. Just a few comments on @tobbee 's post:
Definitely true.
'max_end_time_ms_' is supposed to be milliseconds and 'sample.start_time()' is @90khz clock. This is a minor bug, just needs a timescale normalization. @acris5 For the cases I am working with -that is, live streaming MPEG2-TS starting with any random initial time-stamp- setting 'default_text_zero_bias_ms'=1 seems to work (be careful of using a high value, see the code snippet above).
Shaka expects each live input stream contribution to be "conformant" (more or less :-) ).
mmm... I am not facing this issue... perhaps is due to conformance issues with the input teletext you are using (if you have a sample, I can try it). |
System info
Operating System: docker
Shaka Packager Version: b5c2cb8 (main)
Issue and steps to reproduce the problem
I use live mpegts source to create HLS and Dash videos with teletext.
Packager Command:
What is the expected result?
Live playing in HLS.js and dash.js players. This feature worked correctly with this version Shaka Packager Version: e21519b
What happens instead?
Shaka produces wrong teletext segments time. Starts from 0, then increases but when it reaches current time of video and audio then packager stops working and writes to log that packaging is finished.
Players can't play manifest with different time inside so they freeze video at start.
The text was updated successfully, but these errors were encountered: