Viblast
How can we help you today?
HTTP "410 Gone" not handled properly on live DASH stream
Hello,
Thank you for the report.
Can you share a screen shot of the "Timings" tab?
It would be great if you can share a test stream or at least the manifest mpd (Arte.mpd) content.
Here is the MPD and the screenshot of the network traffic.
What you can see is that:
* The AST is set to 2018-01-26T13:26:13.993Z, and startNumber=24225692
* The player gets the MPD at Fri, 26 Jan 2018 13:26:15 GMT
* It requests the segment 24225691 at 13:26:15.417
As the segment is not available, the server replies with a 410. The player gets stuck somewhere processing this HTTP410, and looses 10s before trying to catch-up with the next one.
Here is an MPD and screenshot.
* availabilityStartTime="2018-01-26T13:26:13.993Z" and startNumber="24225692"
* the player gets the MPD at 13:26:15 and gets the first fragment almost immediately.
However it starts by 24225692, which is not available so it receives an HTTP410
Thank you for sharing the resources.
Can you share the content of the "Timings" tab?
In the network tab if you click on the request with 410 response code , you can see its details separated in different tabs.
What we need is a snapshot of the "Timings" tab, which is the last one. By default the dev tool opens the "Headers" tab, which is the first one.
Here it is:
Thank you again for the additional information.
As we do not have access to your streaming server, can you share the response headers for the request with 410 response code?
We tried to extract some values from the attached pcap, but we have to know the exact values for the headers, especially the "Content-length" one.
You can see the content of the packet headers with Wireshark.
But you are right, I see we are sending "Content-length". I'm checking why.
What we see as a particular response is:
HTTP/1.1 410 Lost File
Server: Expway-HTTP-Server/1.0
Content-Type: text/plain
Content-Length: 47
Connection: keep-alive
Dash-Oldest-Segment: /live/disk40/Arte/dash_xpw/dash/Arte-video=800000.track_id=10001-24221303.m4s
Dash-Newest-Segment: /live/disk40/Arte/dash_xpw/dash/Arte-video=800000.track_id=10001-24221303.m4s
without a body. Thus, the player waits until the entire content is received. The body is not sent and that is the reason why the timeout is triggered after 10 seconds.
Can you confirm if this is the case?
If yes, you have to fix the server response.
I've requested a new build fixing that.
I'll send an update as soon as I have.
Gwenaël Durand
Hi,
It seems Viblast.js is not properly handling HTTP 410 responses on DASH segments.
We have a server with live content, that sends 410 instead of 404 to signal the players that a segment is definitely gone (eg. too far in the past), and prevent them to retry later.
Viblast tends to start one or two segment too late (which I saw in another port will be fixed later), as a result it tends to request segments that are no longer available.
In that case, the player receives an HTTP 410 but takes arround 10s to close the HTTP connection, before trying the next segment with 10s additional delay, wich increases the problem.
Some other js player don't have this issue and immediately move to the next segment when receiving the HTTP 410.
Attached: pcap for 1 segment