Opened 13 months ago
Last modified 13 months ago
#10574 new defect
ffplay / ffmpeg bad retry behaviour upon encountering a 404 on a live DASH stream
Reported by: | ahutson-bbc | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | ahutson-bbc | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
ffmpeg, when used via eg ffplay, upon encountering a 404 in a live DASH stream using a segment template manifest, will begin requesting incrementing segment numbers, seemingly indefinitely as fast as it's able. This results in a potentially very large number of requests for URIs which will not exist at the time they're requested according to the manifest, which puts undue load on the origin receiving those requests.
How to reproduce:
I'm attaching a sample manifest as well as sample init segments to go with it. Put these files on a web server somewhere and load the manifest URL with ffplay, eg:
% ffplay https://example.com/test.mpd
You will see errors such as the following:
[https @ 0x7fd268010000] HTTP error 404 Not Found sq= 0B f=0/0 [dash @ 0x7fd268000c80] Failed to open fragment of playlist
And you will see a significant number of requests for "future" segments on the origin. You can try this with some segments present as well; once it runs out of segments, the same thing happens.
The expected behaviour would be to perhaps retry the missing segment *once*, or potentially even attempt to skip over the segment, but it should not result in an infinite number of requests and it should not result in requests for segments that are outside of the availability window defined by the manifest.
Attachments (3)
Change History (4)
by , 13 months ago
comment:1 by , 13 months ago
FWIW it's not just 404s that cause this, I can also see it happens with 403s, and presumably other error statuses.
Sample manifest