CODEWITHSUNDEEP
videovideo-streaminghttp-live-streamingmpeg-dashvideo-on-demand
zeus
zeus

Reputation: 12937

How to properly store on HTTP web server video files (HLS, dash, mp4, h264, etc)

I need to store lot of video files on my http web server (each video must be maximum 3 min). These video will be play on an android/ios app (similar to instagram).

But now I don't know with formats will be optimal. I definitively would like to have adaptive bitrate streaming (like hls or dash). But I don't know with codec to use (for example H.264 or H.265), with container to use (mp4?), in what different bitrates I need to encode the video, etc...

Upvotes: 1

Views: 1880

Answers (1)

Mick
Mick

Reputation: 25491

The usual architecture for a 'proper' OTT video streaming service is to store your ABR streams in a 'carousel' format at the head end or server side and use a JIT (Just in Time) packager to serve the streams to end devices as needed, at the time they are requested by the user, most often via a CDN.

The JIT packager converts from the carousel format to the required streaming format for the end device, typically HLS or DASH, on the fly.

Apple devices and browsers typically prefer HLS and Windows and Google derives and browsers now prefer DASH generally. In the past Windows devices used SmoothStreaming and Flash used HDS, but these ABR streaming protocols are much less common now.

Give that you want your JIT packager to have to do as little work as possible when converting from your carousel format to the streamed format, storing in fragmented MP4, CMAF (https://mpeg.chiariglione.org/standards/mpeg-a/common-media-application-format), is probably the right approach now. Up until recently, HLS only supported TS (https://en.wikipedia.org/wiki/MPEG_transport_stream) format for the video segments but it now supports fragmented MP4, which means it is aligned with DASH.

If your videos are to be encrypted then the JIT packager will generally do JIT encryption also. At the current time, the encryption mode (the 'flavour' of AES encryption) is different between DRM systems/devices so even though Common Encryption (CENC - https://en.wikipedia.org/wiki/MPEG_Common_Encryption) means a single stream can contain key information for any of the major DRM's, in practice at this time an encrypted stream will usually be different for iOS devices compared to other devices. This is changing as everyone is moving towards the same encryption mode, but it will take a while for users device to be replaced/or updated.

On the bit rates question, it does depend on the devices you want to support and how many streams you are prepared to have.

For example, there is no point in supporting bit rates beyond the display capabilities of your target devices.

Big operators tend to support 5-9 bit rates, but you probably don'y need this many if you are mainly targeting short video on mobile devices.

Upvotes: 1

Related Questions