Bug fix about start time #2194
Bug fix about start time #2194
Conversation
| if (commonEarliestTime[streamInfo.id][type]) { | ||
| seek(commonEarliestTime[streamInfo.id][type]); | ||
| earliestTime = commonEarliestTime[streamInfo.id][type] > initialStartTime ? commonEarliestTime[streamInfo.id][type] : initialStartTime; | ||
| seek(earliestTime); |
There was a problem hiding this comment.
@nicosang This bug still presents for me. I'm using 2.6.4 and my video has no audio track. Could it be because in the audo/video-only case it doesn't do the checkTimeInRanges check before seeking while in the audio and video case it does?
There was a problem hiding this comment.
Here's an example from my debug log where the video goes from 171.379s (intended time) to 168s (start of segment).
[223] Getting the request for video time : 171.379
[224] Index for video time 171.379 is 42
[225] SegmentList: 168 / 349.267
[226] ScheduleController video- getNextFragment - request is https://d11xfn549clyq.cloudfront.net/59efaac067282406f479dd24/video5400_dash.mp4
[698] Buffered Range for type: video : 168 - 171.999999
[699] Got enough buffer to start.
[699] Requesting seek to time: 168
[700] Seeking to: 168
There was a problem hiding this comment.
hi @dpieri ,
I tested with audio only sample streams. I'm not able to reproduce your issue. Could you, please, provide us your video only sample stream?
Thanks,
Nico
There was a problem hiding this comment.
I'm actually able to reproduce it on the Big Buck Bunny example, which is strange because it has audio and video.
Notice how the code sets the video element's currentTime to 21, but the video usually starts at 16. When I open in a new browser it actually starts at 0, so it must be a race condition that depends on how much of the video is cached.
You can change line 6 to try other start times and it seems to always jump to something before the time you choose.
There was a problem hiding this comment.
@dpieri , I see....I think there is a misunderstood. What this PR fixed, was the use of the "#t=startTime" parameter at the end of the manifest url. In this case, if you set url like 'https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps.mpd#t=21', you'll see that it works correctly.
Your use case could be an another issue to inspect....please, open a new one.
Thanks,
Nico
Hi,
a second PR in order to bug fix #2192, start time past in parameter was not used. Stream started always at the beginning of a segment (audio or video).
Nicolas