question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Increase efficiency of dash manifest parsing

See original GitHub issue

Have you read the FAQ and checked for duplicate open issues?: Yes What version of Shaka Player are you using?: 2.4.4 Can you reproduce the issue with our latest release version?: yes Can you reproduce the issue with the latest code from master?: didn’t check Are you using the demo app or your own custom app?: custom app If custom app, can you reproduce the issue using our demo app?: yes What browser and OS are you using?: I’m using LG WebOS 3.0 (LG lh615v) What are the manifest and license server URIs?: I can’t post it publicly

What did you do?

I’m starting the Dash/Widevine content on LG tv.

What did you expect to happen? I was expecting the title to start at around 6 to 7 seconds

What actually happened?

The startup time of title took +35 seconds When starting the title it takes +35 seconds to parse DASH manifest that is of size 1,5 MB. It is seen that most of the time is consumed on recursive call to shaka.dash.DashParser.processXlinks title startup. The title that has 90kb manifest size starts at around 10 seconds which is still quite slow. Other tvs like WebOS 4 based LG suffer from that issue as well.

What is the cause of such poor performance when it comes to parsing the dash manifest? Are there any config params that could speed up the process?

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:3
  • Comments:8 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
chadaciouscommented, Jan 27, 2021

Seems that the processing of xlinks can still be a long operation even with this change in shaka-player 3. Attempting to process a very large mpd (3mb) of the form <SegmentList ...><SegmentUrl mediaRange="..-.." /> will actually crash after several minutes stuck in the processXlinks function of mpd_utils.js.

Should there be a config option to disable xlink processing if we know that our mpd doesn’t use xlink?

0reactions
joeyparrishcommented, Oct 13, 2021

Yes, but there was no “closes” in PR #3240, so the issue didn’t get closed automatically.

@chadacious, you can now use manifest.dash.disableXlinkProcessing to disable xlink. Thanks!

Read more comments on GitHub >

github_iconTop Results From Across the Web

Increase efficiency of dash manifest parsing #1640 - GitHub
We are aware that the DASH parsing is not too efficient on embedded platforms. We thought it was largely due to the actual...
Read more >
DASH-IF Interoperability: Guidelines for Implementations
For such a service, the DASH client operates on information in the MPD and is expected to parse segments to extract relevant information...
Read more >
Guidelines for Implementation: DASH-IF Interoperability Points
In a static MPD a representation SHALL contain enough segment references to cover the entire time span of the period. In a static...
Read more >
Adaptive Bitrate and MPEG-DASH - CableLabs
The client can parse the manifest once and expect to have all the information it needs to present the content in its entirety....
Read more >
Session Overhead Reduction in Adaptive Streaming
After parsing the MPD, the client selects the representations it sees fit, ... While DASH has several tools for avoiding unnecessary MPD.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found