Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC at Snapchat

eng.snap.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: QUIC at Snapchat

#41

Post by prussian »

londons_explore wrote: post #35
solarkraft wrote: post #33

Earlier quoted context omitted.

The reason is fairly simple. Most phones have a slight to extreme (on the order of seconds) delay taking photos. Snaps are about moments. Instagram takes an actual photo and it often results in much worse photos (the picture quality is better, the moment often missed). I'm not sure about this, but I think I remember Snapchat even having implemented actual photo taking and being frustrated about it. Of course a reason…

A lot of android phones have a manufacturer provided camera app which has special abilities - for example, it uses private API's to adjust focus, do zero shutter delay capturing, select which camera to use on 'quad camera' phones, do 'auto expose on faces in the scene', do various HDR in signal processing hardware that regular apps don't have access to, etc. Any app which just uses the android camera API doesn't have…

So in such cases, why not just use a camera activity or at least expose a configurable choice for which experience the android user prefers? It is unfortunate that the camera API clearly needs more work though.

Re: QUIC at Snapchat

#42

Post by gen220 »

regecks wrote: post #9

Today, are there any messaging frameworks similar to zeromq or nanomsg ng, implementing a QUIC transport? Looking to play with a bit. gRPC is a bit heavy for me and lacks a pure-C implementation.

I know you already mentioned it, but gRPC does support QUIC.

If it helps at all, the C++ surface wraps a C core [1], which supports QUIC via an opt-in Cronet dependency [2][3].

If you wanted to roll your own messaging framework, you'd probably want to build on top of at least Cronet, if not gRPC core.

[1]: The pure C core: https://github.com/grpc/grpc/tree/master/src/core

[2]: A visualization of the stacks: https://grpc.io/blog/grpc-stacks/

[3]: https://github.com/grpc/grpc/tree/master/src/core/ext/transp...

Re: QUIC at Snapchat

#43

Post by defaultname »

londons_explore wrote: post #35
solarkraft wrote: post #33

Earlier quoted context omitted.

The reason is fairly simple. Most phones have a slight to extreme (on the order of seconds) delay taking photos. Snaps are about moments. Instagram takes an actual photo and it often results in much worse photos (the picture quality is better, the moment often missed). I'm not sure about this, but I think I remember Snapchat even having implemented actual photo taking and being frustrated about it. Of course a reason…

A lot of android phones have a manufacturer provided camera app which has special abilities - for example, it uses private API's to adjust focus, do zero shutter delay capturing, select which camera to use on 'quad camera' phones, do 'auto expose on faces in the scene', do various HDR in signal processing hardware that regular apps don't have access to, etc. Any app which just uses the android camera API doesn't have…

Which device is this? Focus control has been a pretty basic API element since v1. Unless the device is reporting that it has a fixed lens erroneously, that is super weird.

Having said that, the Camera subsystem is most certainly subpar on Android. It is crash prone, only recovering after a full system reset, which makes developing anything novel a giant pain in the ass. It also is full of random bullshit even if you're using Google's anointed, in-house devices. I remember an update suddenly randomly yielding frame rate capability values multiplied by 1000, chaos monkey style. Code ends up being littered with "If this bullshit device on this bullshit version, then...". It's a gigantic waste of time.

And then as Google started trying to differentiate their own devices with exclusive imaging features, things really started going off the rails.

Re: QUIC at Snapchat

#44

Post by thebean11 »

greysonp wrote: post #38
howolduis wrote: post #11

Snaps speed? How about you actually use the camera on android phones?? snapchat doesn't even USE the camera on Android phones. Instead, it takes a screenshot of the screen, resulting ina terrible quality. It's really embarrassing that they're still doing this for a company this big...

Former Snap employee here (albeit 3 years ago). They care a lot about their camera, particularly speed. They do, in fact, use the "proper" camera APIs on the devices where it's fast enough, and they'll hide the latency by using a screenshot first and then subbing in the higher quality image later. But at the time this was only done for whitelisted devices that could do this operation fast enough. A lot of devices hav…

Just out of curiosity is the whitelist public?

Re: QUIC at Snapchat

#45

Post by foobarbazetc »

As someone who's spent the last 11 days or so helping debug a bug in a live QUIC implementation, I'm... sort of unconvinced that it's a good idea in general.

Every implementation (maybe not Google's?) is just a poorly designed TCP stack, where most of the code is just copy/pasted out of Linux or FreeBSD, and everything learned in those OSes about building resilient TCP stacks is just forgotten only to be rediscovered again.

Not to mention that it's just a huge, huge pain to debug because you can't telnet or openssl s_client to a port and type out some HTTP. And Wireshark is basically useless even when you have your SSL keys saved.

Here's a table of a bunch of QUIC implementations and their compatibility with other QUIC implementations:

https://interop.seemann.io

I mean... why? A lot of smart people are involved here so... there has to be a good reason? I'm not sure a couple of % is worth it.

Re: QUIC at Snapchat

#46

Post by flakiness »

dargueta wrote: post #17
flakiness wrote: post #10

Cronet on the client side is no brainer, at least for Android. It's Chrome's network stack. I wonder what they're using on the server side. Is there any obvious choice that is not even worth a mention, or they implemented it by themselves ?

Seems they use Envoy as the API Gateway https://eng.snap.com/monolith-to-multicloud-microservices-sn...

Cool, thanks for the pointer!

Re: QUIC at Snapchat

#47

Post by MonaroVXR »

greysonp wrote: post #38
howolduis wrote: post #11

Snaps speed? How about you actually use the camera on android phones?? snapchat doesn't even USE the camera on Android phones. Instead, it takes a screenshot of the screen, resulting ina terrible quality. It's really embarrassing that they're still doing this for a company this big...

Former Snap employee here (albeit 3 years ago). They care a lot about their camera, particularly speed. They do, in fact, use the "proper" camera APIs on the devices where it's fast enough, and they'll hide the latency by using a screenshot first and then subbing in the higher quality image later. But at the time this was only done for whitelisted devices that could do this operation fast enough. A lot of devices hav…

What do you mean with slow camera's? The people I hear the most, are people with high-end phones complaining about this.

So that means, that high-end phones aren't that fast after all? (Because what is high-end actually? Price, performance, both?)

Maybe latency, opening the camera? Or getting image itself?

Re: QUIC at Snapchat

#48

Post by dargueta »

foobarbazetc wrote: post #45

As someone who's spent the last 11 days or so helping debug a bug in a live QUIC implementation, I'm... sort of unconvinced that it's a good idea in general. Every implementation (maybe not Google's?) is just a poorly designed TCP stack, where most of the code is just copy/pasted out of Linux or FreeBSD, and everything learned in those OSes about building resilient TCP stacks is just forgotten only to be rediscovered…

I mean, it _is_ a Google project https://research.google/pubs/pub46403/ :)

Re: QUIC at Snapchat

#49

Post by dargueta »

gen220 wrote: post #42
regecks wrote: post #9

Today, are there any messaging frameworks similar to zeromq or nanomsg ng, implementing a QUIC transport? Looking to play with a bit. gRPC is a bit heavy for me and lacks a pure-C implementation.

I know you already mentioned it, but gRPC does support QUIC. If it helps at all, the C++ surface wraps a C core [1], which supports QUIC via an opt-in Cronet dependency [2][3]. If you wanted to roll your own messaging framework, you'd probably want to build on top of at least Cronet, if not gRPC core. [1]: The pure C core: https://github.com/grpc/grpc/tree/master/src/core [2]: A visualization of the stacks: https://g…

Nit, the core is not C ([1]), it's C++. So it's not really usable by anyone wanting a pure C gRPC application.

[1] https://github.com/grpc/grpc/pull/24737#discussion_r52257262...

Re: QUIC at Snapchat

#50

Post by gen220 »

dargueta wrote: post #49
gen220 wrote: post #42

Earlier quoted context omitted.

I know you already mentioned it, but gRPC does support QUIC. If it helps at all, the C++ surface wraps a C core [1], which supports QUIC via an opt-in Cronet dependency [2][3]. If you wanted to roll your own messaging framework, you'd probably want to build on top of at least Cronet, if not gRPC core. [1]: The pure C core: https://github.com/grpc/grpc/tree/master/src/core [2]: A visualization of the stacks: https://g…

Nit, the core is not C ([1]), it's C++. So it's not really usable by anyone wanting a pure C gRPC application. [1] https://github.com/grpc/grpc/pull/24737#discussion_r52257262...

Oh wow, I wasn't aware of this!

Thank you for leaving this comment.

Post reply on HN