Increase efficiency of dash manifest parsing

[pawelgliwinski]

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
. 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?

[TheModMaker]

We are aware that the DASH parsing is not too efficient on embedded platforms. We thought it was largely due to the actual parsing of the XML, which we can't change; but it may be that we could do something to make processing it faster.

Does your content actually use xlinks? It would really help if you could provide some example content to test with. I doubt being encrypted will change anything, so you could post clear content.

[TheModMaker]

Also how did you get that dump? It looks similar to Chrome performance tab. Can you save a dump of it and send it to us? You can also privately send the dump and media URLs to shaka-player-issues@google.com and we'll keep it within the team.

[pawelgliwinski]

It would really help if you could provide some example content to test with.

Not sure if there is a clear content there, I'll try to get something in the meantime I'll send the manifest over the email for start.

Also how did you get that dump? It looks similar to Chrome performance tab.

the dump was taken with LG webinspector.

Does your content actually use xlinks?

I don't think we are using xlinks,.

[TheModMaker]

I pushed a change to make the xlink part better. You can test it on the nightly page: https://nightly-dot-shaka-player-demo.appspot.com

[joeyparrish]

Xlink optimizations have been cherry-picked to v2.4.5.

[chadacious]

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?

[avelad]

The config was added in 014e146 , is it enough?

[joeyparrish]

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!