H264 is not a streaming format. HLS is, and it is pretty much "Apple's format". It's pretty backwards, and everyone was forced to support it because it was the one streaming format you could use in iStuff.
There are a lot of usability issues with firewalls and proxies that make implementing other streaming protocols very difficult, and the HLS design basically causes the implementer to adopt a pattern that is resilient to those problems.
Networks got a lot better after Covid had everyone work from home so IT had to sort the hot-path out for videoconferencing. Nowadays I think WebRTC would be fine, but in 2009 I think HLS was pretty smart.
I am comparing HLS with other HTTP-based streaming formats - DASH and SmoothStreaming. They definitely have their issues (DASH in particular is the epitome of the second system syndrome) but they fix the two most glaring issues with HLS: separate manifests and non-aligned segments.
Source: I write an HTTP streaming client library for a living.
Separate manifests and non aligned segments have a real impact on the ability of the client to switch qualities in responsabilità to bandwith change, and this to avoid stalling.
BTW, when I say "HLS is pretty backwards" I mean designed unergonomically and without clear requirements in mind, not a step back from what existed before. I would guess this is because the original specification was something like "whatever Major League Baseball can easily stream from their existing setup" (see the various Pantos drafts that ultimately became RFC8216)
Oh you're quite right! I was definitely mis-remembering silverlight.
> Separate manifests and non aligned segments have a real impact on the ability of the client to switch qualities in responsabilità to bandwith change, and this to avoid stalling.
I don't know if that's actually true. I sell ads, so I'm collecting delivery data on billions of devices, but only over the crappy internet that has a lot of ads on it, and at least for short videos, and the long videos after the places those short videos are, HLS stalls less than Dash and silverlight: HLS publishers make more money.
I would be interested in learning more.
> I mean designed unergonomically and without clear requirements in mind
I can easily agree with that. I misinterpreted what you meant by "backwards" as referring to the progress of the experience.
Back when streaming meant RTP/RTSP the MPEG-4 file format, and the way bitstreams were packaged, definitely supported streaming. Not only does the format have a sample mapping table but it supports streaming hint tracks to give a server packetizing hints.
Scaling RTSP was difficult because it required two way signaling with the server and for the server to maintain client state. Using HTTP instead allowed for stateless servers in a CDN to easily scale and pushed stream negotiation onto the client. Besides simplifying the server side of streaming it made it much easier for clients switching from cellular to WiFi to maintain a stream, RTSP (and protocols like it) can't really handle clients switching addresses mid-stream.
HLS was a significant improvement over other options for live (rtmp) and adaptive bitrate solutions.
I mean it could be delivered via HTTP and was was built off of open standards for the manifest files. (HLS just breaks down mp4 files into smaller chunks and lists them in a text manifest file based on the mp3 playlist spec) *
It significantly moved the needle forward on how video was delivered and did so in a standards based way until DASH came along.
Not sure why the hate here for their “proprietary standard” it wasn't proprietary - just no one was using it and it eventually became a defacto standard because it “just works”.
In particular, HLS allows existing HTTP load balancers and content distribution networks to be reused for video streaming -- you don't need to build or buy application-specific infrastructure to use it, as you would have with previous streaming protocols.
