slimscsi

Often the increased encoding cost does pay for the reduced bandwidth cost. And that assumes you can navigate and afford the HEVC license.

Its called Opus 5

If you have that many candidates where you can't even answer them, Why are you here asking for more?

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.

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 it isn’t funding subsistence it isn’t basic income" is just rhetorical dressing of the term "basic income".

"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.

reminds me a lot of Innuendo Studios "Always a bigger fish" video https://www.youtube.com/watch?v=agzNANfNlTs

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

GPL-2.0 license in GitHub. MIT license on snap store. $19 in Mac OS APP store.

Yes, and we do, but that is not the slow part: https://en.wikipedia.org/wiki/Motion_compensation

And as for seams: https://en.wikipedia.org/wiki/Deblocking_filter

If an install is necessary, you have already lost 90% of your viewers.

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.

Cost and scale. HTTP video is significantly cheaper to deliver because of the robust and competitive CDN market.

You can deliver all your video via WebRTC with lower latency, but your bandwidth bill will be an order of magnitude higher.

I think this is very unlikely. I think it way more likely that apples CPU team uses linux to test chip designs, and engineering samples.

Thank you.

My point is, I am comparing temporal dimension to temporal dimension regardless of how many special dimensions there are. And I don’t understand the argument that an audio sample is more analogous to a pixel that it is a frame on a time line.

Including pixel intensity, you are correct. Infact it has thee planes, so you could even call it 9 demential If you break it down that way.

I’m not sure I’d agree here. RTPM is probably the most popular live streaming protocol, and it typically has huge variations in instantaneous frames rates. However it’s time base is hard coded to 1/1000. Which means it can’t even accurately represent 30fps. Flicks would be at least a massive improvement here. And even given variable frame rate, a time base must be chosen in advance, so flicks is at least as good as any other value.

Thanks again for the refresher. But again I am keenly aware for how floating point works. As for audience, this is not a hacker new exclusive. It just happens to be here rite now. It will probably make rounds in other forums as well. If you want to write an post an article on how floating point works. I’ll be happy to read it!

Its comparing 1 dimensional space to 2 demential space. So, any comparison is gong to be a little hand wavy. But temporally, I believe the comparison is apt.

Thanks for the comment. For the record, I am very aware of iee 754, And I am aware that some numbers that have infinite repetition in decimal can have an exact representation. I actually thought about pointing that out. However I decided that it didn't add much to the post. It was written for more of a general audience and diving into those details, while would make the post more technically correct, would not actually add any value for the average reader.

fixed, thank you!

You are correct! I will fix that

EARTH!

> std::vector uses constructors and destructors to create and destroy objects which in some cases can be significantly slower than memcpy().

This is precisely what vector::emplace() solves, and std::move should be faster than swap and pop. Modern C++ has changed a lot, this article ignores the massive improvements added in c++11,14,17.