Play fails after seek (Chrome) #1422
Comments
|
Yes. View the docs at http://cdn.dashjs.org/latest/jsdoc/module-MediaPlayer.html and specifically http://cdn.dashjs.org/latest/jsdoc/module-MediaPlayer.html#setBufferTimeAtTopQuality__anchor Setting a lower target buffer may solve your problem. Cheers From: MetaG8 <notifications@gitpro.ttaallkk.topmailto:notifications@github.com> We are having an issue which is probably a bit unique with our architecture: we live-transcode videos to dash-mp4 and then use dash.js to play them back, so not all segments of the video are immediately available. When we start playback it works the same in Chrome and Firefox as the video starts playing after the dash-player grabs a couple (5-6) segments. the player starts to request a lot of segments and by the 25th or so segment our transcoding falls a little behind (assuming 5 sec segments) and we encounter some 404s and the player is not able to fulfill any further play requests. Is there a way to limit the amount of segments the player requests after a seek or to limit the caching behaviour of the video tag in chrome? Console output after seek [13588] Requesting seek to time: 498 — |
|
Firstly thanks for the response. |
|
There looks to be something funny going on with the interpretation of the time stamps : requests are being made for times ~500s but the times Chrome has appended to the source buffer appear to be in the range 100s so the playhead is never buffered.
|
|
Will have a look at the media.internals... about the stream sharing: would it be possible for me to contact you (dashindustry@live.com) or to exchange some details via disposable mail, as our architecture is not meant for public sharing yet? |
|
Media internals shows that the pipeline state stays kSeeking even after a followup play event. Other than thatI don't see anything interesting... the delay between pause, seeking and play is due to us waiting for server responses as well as some additional delay to guarantee server-side operation completion: Any word on the contact situation for the stream share? |
|
Is anyone still looking at this? Currently working on other aspects of our webclient, I would still be very grateful for any help regarding this issue. |
|
@MetaG8 -suggest you join the Slack channel via https://dashif-slack.azurewebsites.net/ and then you can private message @bbcrddave |
|
This appears to be related to at least one Chrome bug. The composition time offsets in these streams are huge (really huge) and Chrome has known issues around reporting DTS instead of PTS. See: https://bugs.chromium.org/p/chromium/issues/list?q=label:MSEptsdtsCleanup Firefox correctly replays the stream because it takes the offsets into account. This is not a dash.js issue - can we close? |
|
This is not a dash.js issue. Closing. |
We are having an issue which is probably a bit unique with our architecture: we live-transcode videos to dash-mp4 and then use dash.js to play them back, so not all segments of the video are immediately available. When we start playback it works the same in Chrome and Firefox as the video starts playing after the dash-player grabs a couple (5-6) segments.
When seeking in Firefox the player grabs a couple of segments in the location we seek to and starts playing no problem, but in Chrome the following happens:
the player starts to request a lot of segments and by the 25th or so segment our transcoding falls a little behind (assuming 5 sec segments) and we encounter some 404s and the player is not able to fulfill any further play requests. Is there a way to limit the amount of segments the player requests after a seek or to limit the caching behaviour of the video tag in chrome?
Console output after seek
The text was updated successfully, but these errors were encountered: