MPD manifest error causes playback delay

[dagwieers]

We discovered that an incorrect MPEG-DASH manifest, including a subtitle that gives HTTP 415 (Unsupported Media Type) cause IA to retry downloading 10 times causing playback delays from 10 to 20 seconds.

Maybe if a subtitle track causes HTTP 415, it should not be retried, but skipped.

See add-ons/plugin.video.vrt.nu#735 for the details.

[mediaminister]

Maybe if a subtitle track causes HTTP 415, it should not be retried, but skipped.

If audio and video are okay, these streams should play immediately independent from the errors with subtitles.

[dagwieers]

@mediaminister Is HTTP 415 ever a recoverable error? To me it does not seem likely.

~Update: In fact, if I am not mistaken, in our case the problem seems to be that the subtitle track has content-type "application/mp4".~

[basilgello]

Same applies not only to subtitle but for HLS streams where server throws 404 Not Found on segment. Result is video looping the same 10 second segment again and again, making playback unwatchable.

@dagwieers @peak3d @mediaminister I guess all HTTP 4xx return codes must skip retry downloading the borked segment and move to the next segment. After, say, five consecutive segments can not be downloaded, the player should gracefully exit.

P.S: I sent the log file with a reproduced error to Markus by email two or three weeks ago, but seems moving into new apartment (if Markus's Github presence note is correct) did prevent him from reacting on the bug report.

[glennguy]

I guess all HTTP 4xx return codes must skip retry downloading the borked segment and move to the next segment

The retry downloading is quite useful for streaming at the live edge, where sometimes server load issues will cause a segment (and even the playlist) to not yet be available/404. For this case skipping this segment and 'fast forwarding' to the next would be bad.

[dagwieers]

We got feedback from the stream provider (https://github.com/add-ons/plugin.video.vrt.nu/issues/735#issuecomment-625741342) with a technical explanation why this happens and why this is expected.

The problem as I understand it is indeed what you already figured out above: Radio 1 (unlike our other radio channels) sometimes includes (closed, i.e. non-burned-in) subtitles. To support this case, the manifest includes a subtitle track. But theses subtitles are not used all the time: most of the time, there are no subtitles present. We can't leave these out of the manifest, because the player would need a full reload if we do need subtitles.

Since the subtitle track is not (always) present, the origin can't provide the requested data, and returns the 415 status that you observed. From the point of view of our origin partner, this is expected behaviour.

The player (TheoPlayer) we use on our official sites/apps ("touchpoints") handles this 415 as meaning "no subtitles present", and starts to play anyway. The players you tested (ffmpeg, jwplayer) behave differently. (Note that I'm trying to avoid pointing fingers at who's right or wrong)

I think we need to reconsider how to handle certain 4xx errors, potentially taking into account the content-type.

The VOD provider is using Unified Streaming Platform (Unified Origin -- LIVE) and THEOplayer as an embedded web-player.

[mediaminister]

This causes the delay: https://github.com/peak3d/inputstream.adaptive/commit/cb3c12b97b07628d06d55cc4de07b782afec03a4

[dagwieers]

Reading the DASH-IF Guidelines for Implementation: DASH-IF Interoperability Points V4.3,

Page 86, chapter 4.3.6. Considerations on live edge

A DASH client should avoid being too aggressive in requesting segments exactly at the computed segment availability start time, especially if it is uncertain to be fully synchronized with the server. If the DASH client observes issues, such as 404 responses, it should back up slightly in the re9 quests.

In addition, for a content authoring to avoid too aggressive requests and possible 404 responses, the content author may schedule the segment availability start time in the MPD with a small safety delay compared to the actual publish time. This also provides the content author a certain amount of flexibility in the publishing of Segments. However, note that such safety margins may lead to slightly increased end-to-end latencies, so it is a balance to be taken into account.

Page 105, chapter 4.8. Robust Operation:

• If the DASH access client receives an HTTP client error (i.e. messages with 4xx error code) for the request of an Initialization Segment, the Period containing the Initialization Segment may not be available anymore or may not be available yet.
• Similarly, if the DASH access client receives an HTTP client error (i.e. messages with 4xx error code) for the request of a Media Segment, the requested Media Segment may not be available anymore or may not be available yet. In both these case the client should check if the precision of the time synchronization to a globally accurate time standard or to the time offered in the MPD is sufficiently accurate. If the clock is believed accurate, or the error re-occurs after any correction, the client should check for an update of the MPD. . If multiple BaseURL elements are available, the client may also check for alternative instances of the same content that are hosted on a different server

Page 106, chapter 4.8.5. Segment Unavailability

To address signaling of segment unavailability between the client and server and to indicate the reason for this, it is recommended to use regular 404s. In addition, unless a UTC Timing has been defined prior in the MPD, the Date-Header specifying the time of the server should be used. In this case, the DASH client, when receiving a 404, knows that if its time is matching the Date Header, then the loss is due to a segment loss.

Annex B, Page 5, chapter B.4.5 Segment Unavailability

When a server cannot serve a requested segment it gives an HTTP 404 response. If the segment URL is calculated according to the information given in the MPD, the client can often interpret the 404 response as a possible synchronization issue, i.e. its time is not synchronized to the time of39 fered in the MPD.

In the MBMS case, a 404 response is also likely to be caused by non-reparable transport errors. This is even more likely if it has been possible to fetch segments according to the MPD information earlier. Although the client M/W, which is normally located in the same device as the DASH player, knows what segments have been delivered via broadcast and which ones are missing in a sequence, it cannot indicate this to the DASH client using standard HTTP responses to requests for media segments.

It references the HTTP/1.1 specification (RFC 7231) for the appropriate action on errors, whereas RFC 7231 does not specify actions per HTTP 4xx error. It does mention:

Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous.

[mediaminister]

I made a draft PR which disables retrying for http error 415: https://github.com/peak3d/inputstream.adaptive/pull/441 (which fixes https://github.com/add-ons/plugin.video.vrt.nu/issues/735)

But before disabling retrying for other http errors, I hope @peak3d can explain why the commit that introduces the retrying mechanism for segment downloads https://github.com/peak3d/inputstream.adaptive/commit/cb3c12b97b07628d06d55cc4de07b782afec03a4 is needed.

[glennguy]

@mediaminister I know of at least 1 add-on that relies on the robustness of having 404 retries for livestreaming, there are possibly others. In my case I've seen that segments close to the live edge (and the playlist refreshing itself btw) will intermittently 404 during peak usage times. The official app/player doesn't have issue with it so they would likely have allowed for 404s to occur without the stream failing/exiting.

Maybe we could go for a more flexible solution where you could specify the amount of retries using a listitem property, and change the current 10 retries default to a more reasonable 3? Individual content providers can customize their player to suit their workflow and needs but I don't think with the vast array of content used in this add-on we can be so rigid.

[dagwieers]

@glennguy @matthuisman The proposed PR only skips retrying for subtitle tracks that give a HTTP 415 error.

Making retries configurable for HTTP errors seems the wrong thing to do. Some things are recoverable, others are not. It makes no sense to retry stuff that is not ever recoverable.

For that we obviously need to test and document the behaviour we see in the field, not base our judgement on past encounters. or hearsay. We should establish what is correct behaviour and compare this to other players (and reference implementations) as well.

Now Kodi/AI acts poorly, both for starting streams (it takes 4 to 5 seconds for every stream, which makes channel hopping impossible) as well as handling unexpected behaviour (like stalling for 10 to 20 seconds on a subtitle track that will never be there (415) before starting playback).

[matthuisman]

why am I tagged?

Pretty sure @glennguy was replying to the other comment (not this issue / PR specifically) about a possible reason retry logic was added. But I guess only Mr peak can confirm.

Remember that the issue here is the "bad mpd" listing subtitles that don't exist. Seems a lot of IA code is related to services not doing things correctly.

We have a workaround for slow services (retry logic) Now we want to remove that logic to fix services that have bad mpds.

Which is correct? Well, neither. So lets try to find a happy medium where as many work as possible without hacking too much.

We could all agree 415 should not retry? But if we have edge case for 415, what about 500, 403, 405 etc

I think maybe better is just not to retry on subtitles fullstop? If response not ok and is subtitles - don't retry. Then don't need to specifically look for 415. Subtitles not working isn't breaking playback so aren't "crucial"

So, if (type_ == AdaptiveTree::SUBTITLE && returnCode == 415) becomes if (type_ == AdaptiveTree::SUBTITLE && returnCode != 200)

Oh, and I agree with Glenn on at least reducing the retries to 3 instead of 10.

[dagwieers]

why am I tagged?

You and @glennguy seem to be pretty ~one-minded~ like-minded about things. The response underlines this once more :-)

We have a workaround for slow services (retry logic) Now we want to remove that logic to fix services that have bad mpds.

Nobody is proposing to remove it altogether. The PR is pretty strict, and the proposal was to understand the rationale of the current implementation.

Remember that the issue here is the "bad mpd" listing subtitles that don't exist. Seems a lot of IA code is related to services not doing things correctly.

If you read the follow-up, it is not necessarily considered a bad mpd, and the streaming back-end (and player) supports this purposely. So again, I would prefer we list known cases and document the rationale for future behaviour so we do not get into a ping-pong where person A fixes his issue, and 6 months later person B fixes her issue, breaking someone else's use-case.

Preferably we list the streams/back-ends, test them against other players and document behaviour and outcome.

[matthuisman]

whats with the personal attacks? Have I done something to you??

You tagged me for some reason - I'm not the developer of IA... I do PRS just like you do... I hadn't commented on this PR at all until you tagged me. So was simply asking why I was tagged / brought into this conversation.

i think there is some language barrier. It seems you think I'm arguing. I'm just explaining how I see things and having a discussion.

I'm not even against this PR. We are having a general conversation about retry logic at this point

[dagwieers]

From DASH-IF Live Media Ingest Protocol related to 4xx errors:

4. General Ingest Protocol Behavior

8. In case of an authentication error confirmed by an HTTP 403 response, the ingest source SHALL retry establishing the Connection within a fixed time period with updated authentication credentials, when that also results in error the ingest source can retry N times, after this the ingest source SHOULD stop and log an error. The number of retries N MAY be configurable in the Ingest Source.

9. The Ingest source SHOULD resend Objects for which a connection was terminated early, or when an error response was received such as HTTP 400 or 403 if the connection was down for less than 3 average segments durations. For connections that were down longer, ingest source can resume sending Objects at the live edge of the live media presentation instead.

10. In case the Receiving entity cannot process the POST request due to authentication or permission problems, or incorrect path, then it SHALL return a permission denied HTTP 403 with error reason

11. In case the Receiving entity can process the fragment in the POST request body but finds the media type cannot be supported it MAY return an HTTP 415 unsupported media type, otherwise 400 bad request MUST be returned.

12. In case an unknown error happened during the processing of the HTTP POST request a HTTP 400 Bad request SHALL be returned by the Receiving entity

13. In case the receiving entity cannot process a fragment posted due to missing or incorrect init fragment, an HTTP 412 unfulfilled condition MAY be returned, otherwise, in case this is not supported by the system, a HTTP 400 bad request response MUST be returned.

14. In case the receiving entity or publishing point receiving the HTTP POST body is not setup or available an HTTP 404 not found SHOULD be returned to the ingest source.

6.1.6. Additional Failure behaviors

2. Upon receipt of an HTTP 403 or 400 error, the ingest source MAY be configured to NOT retry sending the fragments, hence N will be 0, as described in general

Note: This is not the communication between player and CDN, but rather the Live encoder and i.e. the CDN.

[dagwieers]

What personal attack? I am not arguing, neither do I think you are.

[matthuisman]

You and @glennguy seem to be pretty one-minded about things. The response underlines this once more :-)

This is saying I'm one-minded and my response was also. What else have I been one-minded about?

[dagwieers]

Ok, I meant you both are like-minded. (Mind you English is not my native language)

[dagwieers]

The reason I added you was you liked @glennguy's comment minutes after he made it, so I figured you both had discussed this, like with many other conversations. I am not sure what I did wrong with tagging you. I also don't see why that would be offensive.

[matthuisman]

Ok ok, that makes more sense.

Language barriers can seem quite bad. Like how you quote this

We have a workaround for slow services (retry logic)
Now we want to remove that logic to fix services that have bad mpds.

To you, that seems like I'm proposing that. But I'm not - I'm just "thinking out loud" about how silly thing can become. A big round-about of fixing / unfixing to suit each service.

And I quote "bad mpd" as I'm not meaning bad. But just a way to describe a mpd that contains a link to something that isn't actually present.

if all services were 100% "good" we wouldn't need any of these workarounds.

[basilgello]

Would love to hear from @peak3d & @phunkyfish here as well :)

[dagwieers]

if all services were 100% "good" we wouldn't need any of these workarounds.

The problem is that the specification is not 100% clear about behaviour, but we do know that existing infrastructure works with existing video players, where Kodi/IA does not.

This is why we need to document known/existing behaviour of infrastructure (preferably with as much details as possible) so that in the future we can easily retest corner cases and how Kodi/IA behaves. That is the only way we can improve Kodi/IA without introducing regressions.

(And we need to test preferably each release to give everybody a chance to do real life testing before it hits the mirrors and impacts users...)

[matthuisman]

sounds good :)

I have actually started a repo today adding different files that I can test IA with. As I found Matrix has a regression of IA HLS with AES128 playback if it uses multiple keys.

https://github.com/matthuisman/ia_tests

tests.json could be pulled by a Testing add-on to allow for quick testing inside Kodi It just lists a name for the test (list item label), then the properties to set and the url.

Anyway, back to topic on this Issue...

What does the spec say? Do you think subtitles should be retried if the code isn't 415 eg. 404?

[dagwieers]

We are documenting tools for troubleshooting and specifications here: https://github.com/add-ons/best-practices/wiki/Streaming-issues (it also includes known streams for testing specific behaviour/support)

I was also considering writing an add-on with the sole purpose of (automatically) testing behaviour in Kodi. Where we can test seeking, pausing, etc. And where test-files can be selected from a list, or fed directly into the add-on.

This would greatly help in having people troubleshoot their issues, and report back.

[matthuisman]

awesome

I usually refer to Shaka-player codebase to see how they do things as that is used a huge amount Which means lots of stackoverflow questions / answers. Documentation etc. https://github.com/google/shaka-player

Example of how they do their retry logic https://github.com/google/shaka-player/blob/master/docs/tutorials/network-and-buffering-config.md

OK, I tried your file with all those other players - and none seem to work correctly. Some retry a few time and give up completely. Some keep re-downloading the mpd after they fail and start cancelling requests etc. Some just ignore subs so work ok.

IA seems to be doing ok - at least it works after initial slow start.

If we want to keep the same behaviour as other players - then this stream is still not going to play correctly.

Need to decide if we want to keep to the spec and copy what other players do, or have custom behaviour to improve the user experience / support more of our addons?

If we remove retry logic on 415 subs - that's custom behaviour to IA only. It solves the issue but is it right?

Can't have 100% to spec and have 100% compatibility.

I think a good start is reduce the retries from 10 to 2 (or 3) Maybe also remove / reduce the sleep between retries.

My personal opinion is - screw the red-tape. Lets do what is best for the end-user.

I think subs are an enhancement not a requirement. I don't think we should slow down playback waiting for them. give them the initial request - and if they are not OK - then just return. ie. Don't retry on subs.

[glennguy]

Hey @dagwieers sorry for changing the topic from the core of this issue - I was just responding to mediaminister's comment about whether to remove the retry mechanism as suggested by @basilgello

I can imagine a very simplified process for content providers in choosing a CDN for their content, a player for each platform, then configuring both to work together well. Some of the players out there are open source and the content provider developers have scope to customise things further to their needs.

In our situation however (well particularly when DRM is involved) within the Kodi ecosystem we only have a choice of one player - inputstream.adaptive . Even though it's open source, because we don't/can't have a binary addons repository that works across all platforms (looking at you Android in particular), so running our own forks of IA is not practical either.

Also to keep in mind that not only should we look to the DASH IF recommendations but also keep in mind that these could differ to smoothstreaming and HLS. For example in the current HLS draft it says:

The absence of media data (due to, for example, the temporary unavailability of an encoder) SHOULD be signaled....

the key word being 'SHOULD' (their emphasis). There are not recommendations as to what the client should/must do in this case though. The code that handles downloading is generalised for all 3 supported playlist types so any change will affect all 3.

@dagwieers I agree that we shoudn't blanket retry all 4xx errors - 404 we should and 403 we have the trigger to renew token/auth, but yes unrecoverable errors like 400 should not be retried, and probably many more 4xx errors where this is the case.

@mediaminister 's PR looks like a great way to solve the issue in the OP, and provide for further extensibility with other media/error combinations. My opinion moving forward is that since the current code is a very lenient approach to error handling we should be careful in 'winding' it back to something more rigid i.e 'if it isn't broke...'

[basilgello]

Thanks for clarificatiin and mention @glennguy! On my side I try to investigate is it useful at all to move to next segment on 404. I agree totally removing one edge case code to support another edge case is not wise. However, I'd like to make retry count configurable. Like, for user watching an IPTV provider with HLS streams mostly, the sane setting will be 3 retries or even one. If my memory serves me well, after retry fails the next segment is queried anyway so in this case reducing retry count would be sufficient. If not, the setting whether to try load next segment on 404 or bail out can be configurable too.

I can prepare a PR making these things configurable. And it is very good that we try to define a single table of actions needed to handle different non-2xx codes.

[dagwieers]

@matthuisman Yes, other players don't handle those cases very well either. But some do, and the ones supported by the VOD provider handle this without issue. IA is competing with the stuff that VOD providers offer in their browser experience. And VOD providers do not support Kodi/IA, so we will have to handle these cases as well (or find compromises to support as many cases where needed).

@glennguy We need to document ASAP all the cases that do require retries, and start listing everything we want to test in this regard. Because even change the retries from 10 to 3 is not something we know for sure does not break anything, if we don't know why this was added in the first place. (Why always retry? Why 10 times? We have no clue...)

[dagwieers]

BTW when we support different quality in streams a 404 error could retry the same segment on a lower quality stream, on success return to the next segment in the original stream. This could offer recoverability in cases where it would be unrecoverable. This is how some other players do this, not just for 404 errors, but also on connection issues or corruption. Rather than retry, always try the alternative(s) first before retrying the original.

[matthuisman]

The GSOC for adaptive streaming in IA should hopefully take care of that. Wouldn't help your case though as there is only a single represention for the subs

We know why retry logic was added. Because nearly every other player does it.

And I'm a little confused.

You seem to have changed your thoughts.

You originally wanted IA to follow the spec, follow what other big players do. And now you seem to want custom logic to suit a single vod player? Their developer even said it was a workaround.

You seemed angry IA added something that is in every other player that made your one stream delay by 10 seconds when it doesn't even play in majority of other cases. You should be congratulating it as its doing a better job than most.

You can't expect IA to test every single stream before implementing a feature that is actually widely used.

Again, I'm happy for custom logic if we can agree on what has the most wide uses. I agree not to always follow spec or copy other major players. I agree that sub's shouldn't retry. They have a chance to fix themselves in future requests. Let's just play the video.

I just don't agree with how you've handled this discussion.

You came in like your fixing a bug / regression in IA. But really its a feature request to support your stream, so try be nicer.

[dagwieers]

We know why retry logic was added. Because nearly every other player does it.

That is clearly not the case, and not 10 retries causing delays up to 20 seconds before starting.

You seemed angry

I am not.

You came in like its an issue / bug in IA.

I did not. Read the original report.

But really its a feature request to support your stream, so try be nicer.

Not sure what you are insinuating now. This is about improving IA, I don't care if handling unexpected cases better is a bug-report or a feature request. That should not matter. The goal is to have a better working product, and I assume you are here for the same reasons.

[matthuisman]

I am. But we can't have a better product if we follow the major players or spec.

You said to look at what other players do. If we follow them, your stream won't play at all.

I think of IA as kodis web player. We can add custom logic to support kodi streams like how your provider does for theirs.

But the issue is that kodi has many streams from many providers all doing their own stuff as they only need to support their own players.

And we only know what our addons need. Could be a bunch of people using .strm files to play their providers mpds.

Again, I'm for skipping subtitle retries on error. But not specific errors. I'm also for reducing the amount of retries to be more inline with other players. And for making that a property that can be adjusted if needed.

[dagwieers]

You said to look at what other players do. If we follow them, your stream won't play at all.

Depends on which players you select. If you select the ones that cannot handle the same unexpected cases, yes. Should we follow them? I would hope not. The specification allows for stopping playback on unexpected issues, but that would get us a lousy and brittle player.

I don't think we are in disagreement. I simply want all edge cases to be documented, and retries to be performed where the actions are recoverable. Both are clearly not the case today. I don't know why retries is set to 10 and why they are performed for all error cases.

[dagwieers]

But the issue is that kodi has many streams from many providers all doing their own stuff as they only need to support their own players.

I don't think this is the case, these are often the same commercial backends and players on the market. They may have issues, but we are not even talking about those, we are talking about undocumented behaviour and handling it sanely. That is what the PR is about IMO.

[matthuisman]

I tried the players you link to in your readme for testing streams.

415 error is just random. The provider probably picked it so they could tell difference vs a 404 in their player. Its not a known error to skip retry.

Nothing about a 415 error tells me not to retry. If we didn't have this vod service, would we know not to retry on 415?

If anything, 404 shouldn't retry as that means it doesn't exist. However we know with live edges (and other players), that we need to retry on this error.

Its the internet after all. Errors happen.

So I think we should just treat subtitles different. As if we had a 415 on video we still want to retry?

I like the "if sub's fails, just skip them for now" vs "if we get this specific error code from one provider, skip"

Or could have a subs_retry property as well.

As I think subs should be treated different as they arnt 'essential' for playback. Better to have a video without sub's than no video or delayed video.

And sub's can always fix themselves on next go

[matthuisman]

But the issue is that kodi has many streams from many providers all doing their own stuff as they only need to support their own players.

we are talking about undocumented behaviour and handling it sanely. That is what the PR is about IMO.

Its undocumented because only your provider does it.

But the issue is that kodi has many streams from many providers all doing their own stuff as they only need to support their own players.

I don't think this is the case, these are often the same commercial backends and players on the market. They may have issues, but we are not even talking about those, we are talking about undocumented behaviour and handling it sanely. That is what the PR is about IMO.

And yet your one providers streams don't work on any of those major platforms.

Its undocumented as the one provider who does it hasn't documented it.

[dagwieers]

• HTTP 404 Not Found means the file is not available, but the specification clearly stipulates that it may not be available yet and suggests the client should check if the precision of the time synchronization to a globally accurate time standard. So yes, this may be recoverable for the exact case @glennguy coined.
• HTTP 415 Unsupported Media Type is an unrecoverable error, nothing suggests doing the exact same request again would make it suddenly a supported media type. In that regard it looks like HTTP 400 Bad Request, not sure why they needed to differentiate from a 400 in this case. But then again, HTTP responses are lacking mostly in the specification.

[matthuisman]

The developer said the files arnt there. So why use 415? What happens when they change it to 404 instead?

Can you link one other player that handles it correctly?

[dagwieers]

@matthuisman I am getting tired of this discussion. We seem to be going in circles.

Its undocumented because only your provider does it.

It is not my provider, it is hard to proof that only this provider does it, and it is really not documented how the behaviour should be, as such undocumented. Apparently this provider considers this the intended behaviour.

And yet your one providers streams don't work on any of those major platforms.

~The ones I listed are the ones that have a web interface, I wouldn't say these are the major platforms used in the field by large corporations.~ Updated: I added THEOplayer, and apparently your statement is incorrect, this faulty streams works on 5 out of 7 listed players. But indeed, the specification allows to stop handling a stream on unexpected errors (even on HTTP 400 and HTTP 404 for that matter).

(Provider is the wrong entity here, because this broadcaster makes use of well-known commercial software for encoding/transcoding and web-player, it's not in-house developed stuff)

Can you link one other player that handles it correctly?

The player the provider is using is THEOplayer, which I would consider one of the major players.

Shaka Player plays it without issues as well.

The DASH references player also plays it without issues, but reports the subtitle track is missing. As well as Akamai's player

And the Bitmovin player also plays without issues.

So from my list, only FlowPlayer and JW Player have issues playing this stream with the HTTP 415 error on subtitles. Are these the major platforms you were talking about, Matt?

Mind you, IA handles it reasonably well since it eventually plays, but that behaviour could be improved as HTTP 415 clearly is intended to be unrecoverable.

[dagwieers]

BTW the reason why this problem is so well documented here is exactly because the provider and the vendor have been quite open on this. The technical reason to why this subtitle is not available and why this is intended. (This information was not available to me when I opened the ticket).

The developer said the files arnt there. So why use 415? What happens when they change it to 404 instead?

(My guess) Because 404 is recoverable (according to MPEG-DASH specifications) whereas 415 is not (unspecified in MPD but clearly intended from the HTTP specs).

[matthuisman]

Did you even check the webtools when trying to play the streams?

Some don't even try to get subtitles (like theoplayer) The others keep redownloading the mpd after every error on the subs and then sometimes cancel requests to video segments if half way through downloading the new mpd

So - no - they aren't working

The issue I have is with 415. They are saying the format isn't supported - what format do they want? If the file isn't there - they should return a status that tells you that. They have done a "work-around" to stop them having to do the below.

If they don't have subs - remove the subs from mpd. If they have subs that come and go - then return files with no subs in them. This would allow subs to start half way through a segment as well.

So, can we stop relying on a 415 and work on a broader feature.

I think not retrying on subtitles on any error sounds good? Subs shouldn't affect our playback or slow it down. If they fail - then just skip them for now.

[dagwieers]

@matthuisman I am not going over this in circles, 5 out of 7 play the stream. THEOplayer supports subtitles just fine, but not in this case because they aren't available. Playback is smooth despite the HTTP 415.

[matthuisman]

No, your not looking at what the players are requesting! They are ignoring the subs so of course they work.

Its not circles - your just not making any valid arguments. They return 415 - incorrect format. What format do they want?

Can you admit thats the wrong error to return? It makes 0 sense.

Can you point my to a player that actually tries to request the subs but then keeps playing reliably?

For anyone else who wants to join in, this is the mpd: https://live-radio-cf.lwc.vrtcdn.be/groupa/live/d6fdec5d-5d67-4cc3-9f8c-e3e8993c8ee4/live.isml/.mpd

The subs will have live-text_track_0_dut in them

[matthuisman]

Theo player (no requests for subs) Bitmovin (no requests for subs) Shakka (no requests for subs) Akamia (does request subs) But then redownloads the mpd, cancels a request and retrys the same text track over and over

[dagwieers]

@matthuisman Indeed THEOplayer doesn't appear to get the subtitles on the demo player, but it does support them on the VOD provider's website: https://www.vrt.be/vrtnu/livestream/

But Shaka player does fine, let me test the others. (You need to enable subtitles in the player for some players)

[matthuisman]

See my comment above with shakka - doesn't try subs either

Could you play the stream on their webplayer and paste in the requests it makes like I did above? Maybe theoplayer test player is different to production? Or maybe they have added in custom code on top of it (override / callback)

[dagwieers]

~So the only player that supports subtitles and works is the DASH reference player :smile: Four don't support subtitles in the demo version, and 2 fail to work when they do get the subtitles.~

~That means we only have 3 players to verify the behaviour of, and two are not very resilient to the issue we reported. Flowplayer and JW Player have code on GitHub so let me report this to them as well.~

So 4 out of 7 players play without issue when you enable subtitles (of which 2 report the issue without impacting playback). One stutters at the beginning but continues fine. 2 fail immediately.

[matthuisman]

Reference player still retrying the same subs (same as Akamia) Its just happening via AJAX so doesn't affect playback. IA is in the same thread Actually, it retries 3 or 4 times then gives up (with the error)

[dagwieers]

Okay, so here is the THEOplayer from the VOD provider for this specific stream: https://radio1.be/kijk-live

You have to press the square box on the lower-right to enable subtitles (it starts with subtitles off).

It is in fact continuously trying to get new subtitle segments, which is what you would expect if the subtitles could become available at some point in the future. Which is the intended use-case for this.

But it doesn't affect playback.

[matthuisman]

because webplayers can use ajax (in different threads)

Is it trying the same subtitle file or the next one in line? Why doesn't the provider just return a file with no subs in it?

[dagwieers]

@matthuisman Because it isn't necessary I guess, it works for them like this. (They were nice and told us they look into this). The intention here is to make IA work better despite unexpected behaviour. I don't think we can make Netflix, Disney+ or HBO GO to change their ways because we cannot handle their return codes.

So even if your content provider fixes this issue, I would still have reported it here because it is about resilience/reliability.

In that regard, I would be interested of how FlowPlayer and JW Player will tackle this issue. I guess they can retry asynchronously as well.