Closed dsparacio closed 8 years ago
Are there any updates on this subject? We've chosen shaka for now because it started to correctly support multiperiods. But that's would be great to switch back to dash.js.
@alex11230 – dynamic multi-period support is assigned to the next sprint 2.2 - https://github.com/Dash-Industry-Forum/dash.js/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.2.0 . We’d like to have you back too ;) You can help this effort by posting some public test vectors which exercise this functionality. That way your content gets referenced during development.
-Will
From: alex11230 notifications@github.com<mailto:notifications@github.com> Reply-To: "Dash-Industry-Forum/dash.js" reply@reply.github.com<mailto:reply@reply.github.com> Date: Monday, May 16, 2016 at 6:52 AM To: "Dash-Industry-Forum/dash.js" dash.js@noreply.github.com<mailto:dash.js@noreply.github.com> Subject: Re: [Dash-Industry-Forum/dash.js] Dynamic Multiperiod Stream Support (#1360)
Are there any updates on this subject? We've chosen shaka for now. But that's would be great to switch back to dash.js.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Dash-2DIndustry-2DForum_dash.js_issues_1360-23issuecomment-2D219348550&d=DQMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=lrVwTvAYaL-kLQtyOyzq5e_kXPdKRE1gZ8HZKdkSexM&s=VhBYJBYS4aFQ81-mnGVQ8OBDGZ5essAzWAQKGbg3ZB0&e=
for our current video playback solution we use multiperiods with static manifests. in current development version (2.2.0) implementatation of multiperiods has visible transition artifacts: black screen in transition point, reset of timeline and delay before next period starts to play.
transition artifacts can be seen at 10 second in this video. https://drive.google.com/file/d/0B76D-92hJlOCQm9tMUJGVTIxWXM/view?usp=sharing
This was discussed in detail at the Face 2 Face last week and we have some work to do. General idea is try to reuse same source buffer first, catch error, and only then teardown/open a new source buffer
With the current dev version and the RC 2.2, player download only the 'current' period files and stop playing. But I can't determine if it's related to my MPD or from dash.js. If I call play when player is 'stuck', it loads next period files and play it.
Btw, great job with the player :)
Maybe try playing the MPD in Bitmovin or Shaka test players? Not sure if they have Live multiple period support but if the MPD plays we have an answer. we will figure out support for this soon.
BitDash seems not supporting multiple period in live Stream, or at least there is a bug because it try to download files only from first period with $number$ outside of range.
Shaka player works only on periods available when the stream start. It reads 2 or 3 periods and stop playing just before the start of the first period added after the stream start.
Is there any player that plays it? I do not see anything obvious wrong with the MPD, at least, although I do not have my live hat on today.
@sandersaares Sadly not. I will try to find work-around with only one period.
Thanks for checking that and reporting back. We had this feature working then we regressed so I think we can focus on this in 2.3 and get it working properly.
@panofr I am interested to see if items in PR #1631 have solved any of you issues? It is part of Dev branch now and easy to test.
PR #1631 should solve the high level Dynamic Multiperiod concept. Dynamic Multiperiod was never implemented prior this PR. It was only tested / developed with two test url.
http://vm2.dashif.org/livesim-dev/periods_60/continuous_1/testpic_2s/Manifest.mpd
http://vm2.dashif.org/livesim/periods_60/testpic_2s/Manifest.mpd
We are working on acquiring more assets. I am going to close this Ticket for record keeping. We can open a new one when we find failures based on User Agent/ URL
We need to be able to support dynamic mp content. Currently our timeToEnd logic is not accurate causing it to fail to single end of stream, resulting in stalling player.
We need to:
There is a lot of history in #1033.