Roku Developer Program

[streamingguy]

Hello,

I am using HLS streaming for my VOD content, which is encoded with High profile. It has 3 streams with 700kbps, 1.1mbps and 1.6mbps.

As I have enough bandwidth, I am getting 1.6mbps stream and its duration is 2Hr 40 Mins.

I also have subtitles for this stream in .srt format.

When I try to play the stream without forward/reverse/trick play, the subtitles are in sync with the video. But, if I use trick play and skip for few minutes, there is a delay of few seconds with the subtitles.

If I use trick play few more times, the delay is increasing.

So, what could be the fix for this? Is it due to High profile video or is it a bug?

Thank you for your time!

[mkammes]

I know this is VERY old, but I have subtitle sync issues as well....HLS streams and sidecar SRT files. I'm hoping perhaps whatever remedy you found may lead to one for my situation.

Anything?

[streamingguy]

Sorry.. I couldn't figured out the issue and I also stopped working on Roku App long time back.

[RokuJoel]

Here is some engineering feedback for a different partner on what might be a similar problem, sanitized for public consumption:

The problem is in the content, the playlist does not match the real video, and the mismatch buildup as we progress in the movie for 24.97fps content. 25fps content should be fine.

proof :

capture from <redacted tv show>:

The playlist indicates

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="<redacted URL>"
#EXTINF:11,
"<redacted URL>"
#EXTINF:10,
"<redacted URL>"
#EXTINF:10,
"<redacted URL>"
etc...

Now looking at the timestamps at segments start

First segment, look correct, first pts is 0, pts increment of 3754.75 indicates 24000/1000fps
[mp.m2ts.parse.samp.pes.slice] New Slice ******>>>> st 0, et 11000,
[mp.m2ts.parse.samp.pes.orig] ts_sample video valid 3447 bytes, pts 0/90000
[mp.m2ts.parse.samp.pes.orig] ts_sample video valid 18 bytes, pts 3754/90000
[mp.m2ts.parse.samp.pes.orig] ts_sample video valid 18 bytes, pts 7508/90000

2nd segment, according to the playlist, this segment shoud start at 11s, but the first timestamp indicate a time of : 1081081/90000=12.012 sec. Ths is not too bad at this point, but we can foresee a buildup

New Slice ******>>>> st 11000, et 21000, br 2128000, spl 0 size : 320
ts_sample video valid 16354 bytes, pts 1081081/90000
ts_sample video valid 8320 bytes, pts 1084835/90000
ts_sample video valid 7818 bytes, pts 1088589/90000

3rd segment, expected 21se, get 1981982/90000=22.022, gap increasing

New Slice ******>>>> st 21000, et 31000, br 2128000, spl 0 size : 318
ts_sample video valid 16354 bytes, pts 1981982/90000

Now if we jump to a segment at 1h07 into the movie, expected 4021, get 362342342/90000=4026.026, so more than 5sec difference
New Slice ******>>>> st 4021000, et 4031000, br 2128000, spl 0 size : 330
ts_sample video valid 16354 bytes, pts 362342342/90000
ts_sample video valid 6204 bytes, pts 362346096/90000

In our parser, when we detect a difference of more than 5sec between the expected TS and the received TS, we assume there is a discontinuity in the stream and we correct the TS ( We have many streams with discontinuities an must deal with them) , in this case, we will bring it back to match 4021, but this will cause a mismatch between caption and video.

So when seeking to 1h07, we adjust the TS and we see a caption mismatch of ~5sec.However, if we keep playing the content continuously, we will not do the correction and caption will remain in sync

The playlist is used to compute the movie duration and perform accurate seeks, so should be fixed to match the real content

[mkammes]

Thanks for this. I presume your mention of 24.97 should be 23.98?

This raises many questions, mainly pertaining to the inner workings of the system, but the end goal is the same - how is this being rectified now? Or, will any file with a fractional frame rate (e.g. 23.98 and 29.97, not to mention DF vs NDF) always drift from CC?

I'm not sure this addresses my specific issue (viewtopic.php?f=34&t=95362 - any input?) but it certainly makes me wonder if I'll encounter the same issues if I start seeking through the video file...

Thanks!

~Michael