KtorMediaIo

Media bytes over http and https through Ktor (the Ktor half): the engine's FFmpeg profile deliberately vendors no TLS backend, so THIS is how https plays, with the OS supplying TLS through the platform engine (OkHttp on Android and the JVM, NSURLSession on Apple).

Seekability is the server's Range support, probed once at open with a bytes=0- request: a 206 answer means ranged reads work and the total size comes from Content-Range; a 200 answer means a forward-only stream sized by Content-Length when present. A seek reopens the stream at the target with one ranged request; the engine's byte cache above this reader is what makes small seek-backs free.

Threading is MediaIo's own contract: demux worker only, one call at a time. The streaming body rides its own coroutine writing into a bounded pipe, so memory stays flat however far the server runs ahead.

Every wait has a limit from HttpReaderPolicy: the connection and the response headers of each request, a seek's included, and the next bytes of a response that has started. A wait that passes its limit fails with KtorMediaIoException.

A read that fails, times out or meets a response that ended early reconnects, with a Range request at the byte it reached, after a backoff. The answer must start at that byte and belong to the same file: the request carries If-Range with the entity tag of the first response, and a changed tag or total size fails the read. Each reconnect is reported through setWarningSink as PlaybackWarning.SourceReconnecting. A reader whose server has no ranges can start again only before its first byte.

A live stream is the exception (#508): an internet radio station's answer, with no length and no ranges, from a Shoutcast or Icecast server, which says so with its icy- and ice- headers. Such a server closes a listener's connection as a matter of course, when a paused player has stopped reading, when its encoder restarts or when a load balancer moves the listener, so the end of the body is a drop rather than the end of the media. The reader then connects again with a plain request, under the same limit and backoff, and the new answer continues from the live edge: an MP3 or AAC decoder finds its next frame by itself. Icecast answers 404 while a station's encoder connects again, so 404 and 410 are tried again too, and a station that still answers them once the reconnects are spent has ended: the stream ends there. A response with no length and no ranges but none of those headers ends where its body ends, because a media server that encodes a song as it sends it answers the same way, and asking it again would play the song again.

openRelated opens the other addresses that the media names, such as the segments of an HLS playlist, as readers of their own on the same client. Only http and https addresses open. The item's own headers go only to the scheme, host and port of the item's address, because the addresses come from the media. Headers that a KtorMediaIoResolver adds by default go to every address. An open that times out, fails to connect or meets a server error tries again after a backoff, as a read does.