Support for HLS? about stream-m HOT 7 OPEN

Hi, live streaming HLS would involve muxing into TS (a container format which is completely missing from the codebase), also it would be necessary to dynamically generate and refresh .m3u8 file by the server (as the fragment-files will be generated on the fly).

So this would be a pretty large effort. On the bright side, really low latencies are achievable with HLS.

from stream-m.

isn't HLS high latency only(>a few seconds)? and RTMP is low latency

from stream-m.

Hi, my requirements for low latency is that a frame should be playable when received (in a good case - with slicing - decoding can even start before the full frame has been downloaded).
The biggest obstacle is the container format. RTMP is one of the good ones in this aspect, a single frame contains its own timing (and framing) next to it, and so is MPEG-TS (used in HLS). Other containers, like MKV (in some aspects) and MP4 (DASH) need to know the whole movie fragment (GOP) before muxing, because framing and timing info is not with the frame data, but in a its own chunk. Basically you receive all the metadata, then all the frame data.
We usually consume HLS as a series of small-ish files, this is cheap because you can incorporate a classic CDN, but I don't think you absolutely have to use it like that. You can create a TS stream on-the-fly (and emulate a large .ts file), this way while the broadcaster is transmitting the frame you can start sending it to the viewer.

I have not tested how well today's browsers handle it, but I can't think of a good reason why they wouldn't.

from stream-m.

heard HLS has at least a few seconds of latency, because of generating the fragment and the m3u8.
and RTMP can achieve <1s latency.

if it streams as a large MPEG-TS container, and it can be seen as just an HTTP stream. and shouldn't be called HLS.
and the source uses RTMP to stream mostly, so the server needs to convert protocal from RTMP to HTTP. and then the latency might be about 1s. but not tested.

from stream-m.

The m3u8 can be generated in advance, the files don't have to be there immediately, I don't know of a size limit that an .ts can be. You can call it HLS in a sense that any HLS-capable player should be able to play it.

from stream-m.

but if use m3u8 and fragment then there would be massive latency.

.ts has no size limit I guess. since the TV is using MPEG-TS

from stream-m.

You can generate m3u8 without any knowledge of the stream, it can be static and just point to the stream's name. On the URL (pointed by the m3u8) the server can serve .ts as an endless file.

This way no additional latency is introduced expect a relatively small buffer on the server side (let's say 24k).

from stream-m.