Posting a video URL to the API now downloads the file

If a script or integration of yours adds videos to Anthias through the API by URL, those videos now download to the player and play from there, so the player needs disk space for each one. Videos added in the web interface aren't affected.

When you create an asset through the API with mimetype set to video and an http:// or https:// URL that points at a single video file, Anthias now downloads the file to the device and plays it from there. The asset shows as "Processing" until the download and the codec check finish. Before, Anthias stored the URL and played it from the origin server every time, so playback depended on that server being reachable.

This applies to API v1.2 and v2. v1 and v1.1 keep storing the URL as it is.

What counts as a downloadable video

• URLs that end in .mp4, .webm, .mov, .mkv, .avi, .m4v or .ogv.
• URLs with no file extension, when the server answers a HEAD request with a video/* content type. If the server doesn't answer that way, the URL is kept as a stream, as before.

Live streams stay as they were and play from the origin: rtsp://, rtmp://, srt://, udp:// and mms:// URLs, and HLS, DASH and Smooth Streaming manifests (.m3u8, .mpd, .m3u, .ism).

A download is capped at 5 GiB and 15 minutes. If it fails, because the server returns an error, the response isn't a video, or the file is too large, the asset shows "Failed" with the reason.

The "From URL" tab in the web interface is unchanged and still stores the URL without downloading it.

If this affects you: if you post video URLs to API v1.2 or v2, the device now needs enough free disk space for each file, and a video in a codec your board can't decode is refused. If you want a URL to keep playing from its origin, use a streaming URL or API v1 or v1.1.