bbc / bigscreen-player Goto Github PK

For the live facades LIVE_AUDIO is passed through as LIVE_VIDEO due to the logic only checking for audio. (If live_audio is passed is needed then this may be a problem in the future)

Legacy Adaptor also only works in a video world. This will need to be handled if we want to support live audio.

Prerequisites:
Google Chrome 87.0.4280.66
BigScreen player: 4.4.3
Stream: https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps.mpd (default)

Steps to reproduce:
In devtools execute below commands on video tag:

1. $0.play()
2. $0.currentTime = 634.1
3. Wait for video to ends
4. $0.currentTime = 0
5. $0.play()
6. $0.currentTime = 634.1
7. The second seek should fail with FATAL_ERROR, if not repeat points 4-6

The bug is a some kind of a race in the JS. Bug reproduce more frequently after enabling Verbose log level. Error occures also in Vewd Tv browser.

Note:
Near-end seek is extensively used in BBC Iplayer. When user perform the seek to the end of a stream in the UI, the BBC Iplayer set the current time right before end of a stream to play last seconds of the video.
The issue does not reproduce on Dash Reference Client 3.1.3

Log from first succeeded seek:
first_seek.log

Log from second failed seek:
second_seek.log

Hi,
My name is Jaroslaw Trelak. I work for Vewd Software. Recently I did some tests of bigscreen-player.
I tested few streams from DASH industry forum, and I faced some playback issues with SegmentTimeline variant of DASH streams.

Example of not working DASH live stream (playback is stalled after few seconds): Basic 24/7 SegmentTimeline:
http://livesim.dashif.org/livesim/segtimeline_1/testpic_2s/Manifest.mpd

As for reference, here is an example of properly working DASH live stream: Basic 24/7 ($Number$-template):
http://livesim.dashif.org/livesim/testpic_2s/Manifest.mpd

Does it mean, that SegmentTimeline DASH manifests are not supported by bigscreenPlayer?

BR,
Jaroslaw Trelak

Environment

Browser: Google Chrome 87
Bigscreen Player: 4.6.0
Stream: default

Reproduction

Use stream with multiple representations. Continue seeking until seek takes noticeably long time ~5-10 seconds.

This is also observed in iPlayer and CATAL. The order of events that triggers this issue might be a little hard to achieve. It's much easier to reproduce with bandwidth throttling.

The issue

This is the order of events leading to the issue:

1. Seek to time t
2. Fragment with id i for time t is requested and download started
3. Before download is finished, there is drop in measured bandwidth and representation changes
4. The request for id i is abandoned (because of quality change)

After this, next download request is for fragment with id i+1. New segments are downloaded and this continues for some time. Seek is ongoing because the fragment with time t is missing. Please see buffer ranges in attached log. It might take 5-10 seconds until the right fragment is requested again and playback finally starts.

This is the bug in dash.js and does not reproduce on dash reference player in version 3.2.1. Bigscreen Player is using older version of dash.js. From what I was able to find, changes that seem to fix the issue are introduced in version 3.1.2. This one in particular: #3308. Could you look into this?

Logs

longseek.log

This should be fixed to tidy up the debug view.

Currently, when passing a safePosition into the renderExample function, you can pass it a left value.

A better API would allow all 4 percentage values (top, bottom, and right) to be set so that other clients can position the example subtitle wherever they want it.

var safePosititon = { top: 0, right: 0, left: 30, bottom: 20 };
bigscreenPlayer.renderSubtitleExample(exampleUrl, customStyleObj, safePosititon);

As of #90, msestrategy supports multiple callbacks, whereas other playback strategies do not.

I have done some tests of live streams on mse playback strategy successfully. Unfortunately I faced issues when I tried TAL strategy
When I try to set talstrategy (instead of mse), I have js error, and player doesn't work at all. I set it as follows:
window.bigscreenPlayer.playbackStrategy = 'talstrategy';

Error message:
TypeError: device.getLiveSupport is not a function
at Function.push../script/playbackstrategy/talstrategy.js.TALStrategy.getLiveSupport

Maybe there is any additional configuration needed to prevent such errors on TAL?

Does it make more sense to native strategy to use the Bigscreen Player debug tool, rather than an injected TAL logger?

bigscreen-player is considered self documented by understanding the code when reading through. More thorough docma styling could be used to improve the ease of contributors - as well as tidy up the code base.

GitHub have started to create all new repos using main as the default branch. The industry appears to be moving in that direction.

GH have now made it really easy to rename the branch: https://github.com/github/renaming

legacy player adapter always passes in video to initialiseMedia. See here

This causes the video tag to always be used within the html5 native strategy.

See html5 strategy init and here

We should be using the correct html tags for the content.

The README should point to a singular point of truth for getting started with bigscreen-player. At the minute a lot of information is contained within the README that could be migrated to the wiki, or directly refer to the example app for more details.

Currently, this requires updating the README and the wiki separately if a public facing aspect of bigscreen-player is changed.

TAL is reporting duration for live content as having a duration of infinity as MSE is reporting it as the end of the seekable range.

To keep our api honest, I would assume we would return infinity for MSE strategy.

Hello Sir. I'm a Graphics Designer. I'm happy to see an open source project, So, I want provide a logo for you. Would you mind if I propose a new logo design for your project as my Open Source Contribution?

Thanks for the attention.

This should perhaps be torn down or hidden on tear down of the debug tool.

This is a workaround based on the windowType being sliding. Sliding here refers to the DASH manifest having a timeShiftBufferDepth value.

Ultimately when seeking, dashjs will set the current time on the underlying video element. However, something else, either in dashjs, or our interaction with it, was causing problems when seeking and the manifest has a timeShiftBufferDepth.

Therefore this workaround bypasses the dash media player seek code and sets the time directly on the video element.

It would be good to investigate this and ideally use the mediaPlayer.seek in all cases.

If a callback is unregistered from within the loop running the callbacks, problems can arise.

An example of this was recently found when trying to listen only to the first PLAYING event, and therefore unregistering from within the callback.

This could be mitigated by running the state change callback in a backwards for loop rather than a foreach.

I'm not sure if this is an issue. But I observed differences between playback of BBC CATAL and bigscreen-player. Some operations on live stream (slidingWindow live) does not work exactly like in CATAL. Does it mean, that CATAL has some additional logic to cover certain playback scenarios?

Example: I clicked pause at the beginning of the seekable range

• on bigscreenPlayer playback is paused
• on CATAL: pause does not work at the beginning of the seekable range (playback is recovered immediately).