mlprs
commented
6 years ago I see a similar issue, do you have any updates?
Closed NyuuuuOrz closed 3 years ago
mlprs
commented
6 years ago I see a similar issue, do you have any updates?
epiclabsDASH
commented
6 years ago Not yet, sorry. I will keep you updated.
uafgin
commented
5 years ago i'm having the same issue, i solved it in aweird way but it does work. everytime i seek instead of changing currentTime i am loading the same source with dvr offset from live, by doing it i understood the main issue. the difference between seeking and loading manifest with offset is the clock sync event when manifest loaded for the first time Dash.js load event to sync clock (to iso clock), i dont know if the problem is cpu usage or something that lg customized in their OS but when you seek you just lose clock sync. if you noticed, the video is freezing but if you keep it in this situation you will see that the picture is changing from time to time because the clock delayed but sometime the player do manage to load segment. i'll try to fix it by overriding the clock sync event or somehow force it to sync and let you know if it solved the issue.
ChrisMash
commented
5 years ago @uafgin any update on a fix or more details on the workaround you were trying?
uafgin
commented
5 years ago @ChrisMash yeah i think i'm almost fully understand the issue. the problem is not the clock sync, the clock sync is used to update the segment time line by the manifest so its not the problem, the main problem is in the dynamic manifests(live streams), the stream uses BLOB of MediaStream object that gets duration and sourcebuffer, once you flush it and remove all the buffer(seeking does that) the video element fails to play new buffer in the same MediaStream, it does play the first frame but cannot go further. the difference between this and static stream is the duration and the timing, in live stream we use the actual date so i guess something goes wrong there because of the big numbers or the infinity duration maybe, i am not sure and the video element does not provide me any error so i guess only LG engineers knows the answer. i've solve it by changing the seek method to create new blob of media stream and push it into the src instead of flushing the current mediastream, the result is not that nice because you see black screen for like 1 min but it does work. i made also changes in Dash so i can play content with offset from live stream so i can rewind on dvr.
ChrisMash
commented
5 years ago @uafgin thanks for the quick response! Very helpful information. Are you able to share any of your code changes you've made? A 1 minute black screen doesn't sound particularly useable.. but maybe your work will help me find a suitable workaround.
zgzong
commented
5 years ago @mlprs: Does your live stream contain UTCTiming tag in mpd? If there is no UTCTiming tag in mpd, dash.js is rely on the system (LG smart tv) to have an accurate wall-clock. But LG smartTv doesn't show the tv time in second level, and the stream only has 10 seconds DVR windows. The device time may fail in both edge of the DVR window.
el-gringo
commented
4 years ago @zgzong We have tested the UTCTiming tag with no luck
Here is what we added to our manifest:
<UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-iso:2014" value="https://time.akamai.com/?iso" />
stale[bot]
commented
3 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
stale[bot]
commented
3 years ago This issue has been automatically closed because no further activity occurred. If you think this issue is still relevant please reopen it. Thank you for your contributions.
Hello, Recently I am using the dash.js player to test some dash-format sources on LG Smart TV platform. Our LG Smart TV runs webOS 3.6 operation system and it has its own browser. According to the introduction of webOS SDK, its browser support the ‘Media Source Extensions Editor's Draft 10 December 2013’ so I integrate dash.js into an webOS APP to test some dash-format sources. After several tests, the dash.js player works well with VOD playback. However, for live streams, the playback will freeze after a seek operation (the live stream has a 10 seconds DVRWindow). The same live stream source works well on Chrome and IE11 on PC after several seek operation. I suppose the problem may caused by the nonsupport of the timeshift live stream on webOS TV but I am not sure. The following is the detail of this problem:
Steps to reproduce
Console output
After the log at [6790] is where I executive the mediaPlayer.seek() function.
I check the timestamp value for seek and make sure it is within the DVRWindow range(metric.range in the function getDVRSeekOffset()). I also log the currentTime attribute of the video element during each timeupdate event. I notice that after the seek operation, the currentTime attribute update for a while and the log "Native video element event: seeked and Native video element event: playing" indicate that the seek operation is done. However, after that, the currentTime never update anymore and the timeupdate event does not trigger anymore. So the playback freeze until another seek operation caused by the updateCurrentTime() function in the PlaybackController model. And the same phenomenon repeats. For another playback test, I try to play the same live stream with a 2 hours DVRWindow. It does not work at the beginning and the log shows the error: _MEDIA_ERRDECODED.
I focus on the code of segment request process and the seek operation process, and I does not find any difference compare with the log of Chrome and IE11 on PC. So I think that the browser on webOS 3.6 operation system may not fully support the live stream playback.
Could you give me some suggestions that if there are some settings of the player or some part of the code may cause the problem so that I can make a further prove?
Thanks a lot for your help!