Hacker News new | past | comments | ask | show | jobs | submit login

> There's no good technical reason not to enable lossless compression

Why would you want to losslessly compress audio or video? The resulting files would be huge--often too huge to steam. Lossy compression is what you want.

I must be misunderstanding the article?




My guess is they mean "visually lossless" i.e. "lossy" compression but with high quality settings so the user won't notice any difference.

That's a slightly odd way to phrase it, and I'm amazed that it's not a basic part of any streaming service these days, but makes more sense to me than the other suggestions.


I interpret that as meaning the difference between using stream copy and re-encoding videos when converting between different formats.

For instance, the user might upload an H.264 video as an MP4 file. Streaming services generally won't serve the MP4 file itself, but will create an HTTP Live Streaming (HLS) version where the video is split into multiple .ts chunks along with a .m3u8 playlist.

However, such services (including YouTube) will generally re-encode the video when doing so, and the end result will have poorer quality than the original uploaded file.

This is actually unnecessary because .ts files support the H.264 codec, so the video does not need to be re-encoded. Instead the streams can be copied to retain their original quality.

If additional compression is necessary, I suppose it would be possible to apply HTTP compression using algorithms such as gzip or deflate.

Of course, this is purely speculation. It would be nice if Cloudflare clarified what they meant. But it would certainly be great if they used stream copying where possible instead of re-encoding.


If you read on for context, it sounds like they are comparing to the case where the customer simply sends some uncompressed video file, and pointing out that you might as well enable lossless compression in this case. However, CDNs (or somebody) introduce technical obstacles for this because they charge by bandwidth, so compression would hurt their profits.


> uncompressed video file

1920x1080 at 3 bytes per pixel and 30 frames per second is 11GB for just one minute of video, and 186MB per second. That's far too big and expensive to stream, and outside of somewhat special circumstances I've never heard of anyone storing video in such a huge format.


Agreed. We don't have the whole story here, I'm just trying to understand from context. Perhaps the thing that's being sent is not a raw video file, but some other file that could still be improved via lossless compression.


I would assume because the CDN customers make downstream promises to their own customers that the data will maintain losslessness. There are two potential reasons why that guarantee might be useful that I can think of:

- your product is explicitly lossless as a feature (like Tidal for streaming lossless music)

- you have to provide the files to others for reasons other than watching or listening (like editing), where integrity matters, and the use case/context requires a stream instead of just a file download


I dont think theyre saying lossy isnt useful - but that too many people arent doing _any_ compression at all. Thats the way I read it; I could be wrong.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: