Phencys
commented
4 months ago This issue is caused by an invalid assumption that all servers support HTTP/1.1 - and in specific byte-range requests.
The code tries to be smart in what it needs to download from the server so it can skip the 'mdat' contents, but if a server does not support byte-range requests, it re-downloads considerable parts of the file which would almost always result in a corrupted system.
When we are a little bit further along with the live support feature, this is going to be replaced by a limit on the segment count rather than partial downloads of segments.
Seen with dev branch cf6871f80dbbbba974b84f4fa21ad8fd0ba95b32 when running the tool in a Docker container.
The init segment is requested 3 times: once via HTTP 1.0, twice via HTTP 1.1. This double HTTP 1.1 request only happens for init.mp4 and in some cases, results in a corrupt assembled.mp4 file. The range of bytes requested is different for each. It seems like this second request should be removed.
While this incorrect double request always occurs, it seems to depend on the server as to whether it causes a corrupt assembled.mp4 file or not. Perhaps due to the range of bytes requested?
Unfortunately this breaks segment validation when serving the segments locally via a simple Python http server (e.g.
py -m http.server 9090 -d F:\CTA\vectors\development\), which did work previously.