I think you need to look into your hiring portal. I have actually applied to this position (or a position with the exact same description) many months ago. Never heard anything. Which is strange since I have decades of video encoding, video player, c++, and cross platform development experience at both startups and FANG.
"If a small amount of my taxes goes to somebodies rent or healthcare, instead of paving roads for the Amazon trucks to drive on, or the FAA for the Amazon airplanes, them I might as well just be homeless myself!" What a strange argument.
This is a straw man. Nobody is talking about funding people to the point where they get everything they need for free. That's insane. We are talking about giving people bootstraps so they can pull them selves up with them. Reducing poverty reduces crime and health care costs as well.
This mentality is exactly the problem. The idea that people with more money should get to decide how people with less money get to spend it. And if they don't sped it the way they want, Its waste.
Codec standards are defined for decoder compatibility. So no matter what encoder produces a stream, a “standard” decoder can display it. But encoders are free to do whatever they want within those bounds. Each encoder may choose to make trade offs that are incompatible with each other. So stitching often requires using the same encoder. Getting everyone to agree on a common sequence header is just not going to happen. It would need to be built into the codec specification. And no modern codec has cross implementation stitching as a design goal. It would be possible to make an implementation that parsed an existing stream and created a stitchable output, but there is no financial incentive to create that encoder.
EDIT. Some decoders can be reinitialized by adding parameters in band. But this is technically illegal in some formats (like mp4) but it may "just work" in some playback environments
Flash "low latency" was just RTMP. CDNs used to offer RTMP solutions, but they were always priced significantly higher than their corresponding HTTP solutions.
When the iPhone came out, HTTP video was the ONLY way to stream video to it. It was clear Flash would never be supported on the iPhone. Flash was also a security nightmare.
So in that environment, The options were:
1) Don't support video on iOS
2) Build a system that can deliver video to iOS, but keep the old RTMP infrastructure running too.
3) Build a system that can deliver video to iOS, Deprecate the old RTMP infrastructure. This option also has a byproduct of reduced bandwidth bills.
For a company, Option 3 is clearly the best choice.
edit: And for the record, latency was discussed a lot during that transition (maybe not very publicly). But between needing iOS support, and reducing bandwidth costs, latency was a problem that was decided to be solved later.
"Streaming" in the media industry just means you don't need to download the entire file before playing it back. The majority of streaming services use something like HLS or DASH that breaks up the video into a bunch of little 2 to 10 seconds files. The player will then download them as needed.
But even then, many CDNs CAN "stream" using chunked transfer encoding.
EDIT: I’m sure you have a dozen great candidates in your resume pile you reject for a type-o or an unknown school, or something. Do a second pass.