HN user

slashink

921 karma

video @ discord prev video @ twitch

hn at jonasbengtson.se

https://jonasbengtson.se

Posts3
Comments128
View on HN

(i work at discord)

Not saying that wasn't ONE of the reasons but the main reason was really that a large chunk of users had no idea that they even had a discriminator, as it was added on top of your chosen username. "add me on discord, my username is slashink" didn't work as people expected and caused more confusion than it was solving. This wasn't universally true either, if you come from a platform like Blizzard's Battle.net that has had discriminators since Battlenet 2.0 came out in 2009 it was a natural part of your identity. End of the day there were more users that expected usernames to be unique the way they are today than expected discriminators.

Addressing that tension was the core reason we made this change. We are almost 3 years past this decision ( https://discord.com/blog/usernames ) and I personally think this change was a positive one.

For what I hack on I often run into issues with the FFI performance between go/c# <-> c/c++. I’d rather not write C or C++ and Rust is one of the few languages that allows me to mess around with obscure libs at native performance and yet slap a web interface in front of it. cxx/bindgen is stellar in how fast they allow you to wrap libraries. These cases is where I would want like the simplest most opinionated web framework (like gin in Go).

For everything else, there’s Go IMO.

This is unhinged and I love every part of it! Apart from the repo having an attitude I often miss from the modern internet I also learnt something reading the code on how FUSE works!

Hey Sean, we both worked at Twitch Video but I left just as you were joining. I currently work on the Discord video stack and am somewhat curious about how you imagine Discord leveraging WHIP/WHEP. Do you see it as a way for these clients to broadcast outwards to services like Twitch or more as an interoperability tool?

The author ends the review by saying “AVP is the superior product” so I find it hard to agree with your take. The information presented clearly shows the tradeoffs that Apple has chosen with their displays. It’s left up to the reader to decide if that’s a subjectively more enjoyable experience but from the objective viewpoint, the article does a good job at showcasing the drawbacks.

Yeah it sets timers, that's about it. Not saying this product is good but the intention of what they are trying to enable here is a world apart from what Apple is running on the watch.

My understanding is that modern renderers render in a "physically accurate" way. However, cameras throughout history has never captured images in a "physically accurate" way but rather through a set of imperfect techniques (lenses, film etc) which produces a certain look. When rendering, it's hard to make things seem realistic as they often look too perfect but something like this gets closer to how a photo would look.

Credit card reward systems & points are not free. Comes at the cost of higher transaction fees that eventually get passed on to the customer.

I’ve found these schemes much less prevalent in Europe (with the exception of AMEX, but half of the vendors in Europe seems to not accept that anyway).

On top of that, in the EU, interchange fees are capped to 0.3% of the transaction for credit cards and to 0.2% for debit cards. This prevents it from becoming the points hell of the US market.

There are tons of these solutions in production for well over 10 years. Big media customers has run virtualized edit bays in AWS for at least 4 years at this point.

Reasons people don't use these solutions are the same reason Mighty ended up not working. Even in CAD applications, latency matters when trying to move objects in 3D space with precise mouse input or using a 3dconnexion spacemouse. Sure, you can overcome latency by doing what Google essentially invested in with Stadia, run GPU's closer to the edge but at that point the cost of just buying workstations for your employees is not that different from acquiring a stable connection (for 8+ hours a day) with the fee of renting the hardware.

I WANT to switch to Firefox but the reality is that the experience is still sometimes rough compared to chrome. It’s the small things that gets me. On Mac, clicking a link when Firefox isn’t open sometimes opens two windows. Sometimes the keyboard shortcuts stops working if you just tab to the app as you have to click on it for keyboard shortcuts to start working etc. I know other browsers plays a lot of tricks to feel snappy but reality is that the tricks works, Firefox can at times “feel” slower doing operations.

Chrome has none of these issues and as an effect brave is good. That’s why I’m testing brave.

I really tried this time, 9 month of Firefox.

Not sure if you can draw that conclusion yet. The deck has been perpetually sold out since launch and is still a 6 month wait to get a device, they are selling them faster than they make them at the moment.

I don’t think this product will ever compete against the broad marketing effort of Nintendo however, it’s sort of a niche product in the end. With that said the comparison itself is odd.

Full disclosure: I do NOT own a deck and I do not intend to buy one.

Phone number verification is purely one of many ways for Discord to drive down the amount of spam. Not used for any other purposes. We’re ofc working hard on enabling alternative solutions.

Source: I lead the anti-abuse team at Discord

You can just implement the Default trait yourself and set sane defaults right? At least that’s how I use it, implement the default trait manually to easily return a initialized struct.

Also a good question.

The issue here is the architectural difference between the hardware decoder and the GPU. What happens under the hood with MSE ( https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...) is that you are responsible for handing off a buffer to the hardware decoder as a bitstream. Underneath, the GPU sets up a texture and sends the bitstream to the hardware decoder that's responsible for painting the decoded video into that texture.

What often ends up happening is that the GPU driver says "yes the hardware decoder can do this", it accepts the bitstream, sets up the texture for you which is bound against your canvas in HTML. Starts playing the video, moves the timeline playhead but the actual buffer is just an empty black texture. From the software's point of view, the pipeline is doing what it's supposed, due to the hardware decoder being a black box from the Javascript perspective it's impossible to know if it "actually" worked. Good decoders will throw errors or refuse to advance the PTS, bad decoders won't.

Knowing this, your second suggestion was to read back the canvas and detect video. That would work but the problem here is "what constitutes working video". We can detect if the video is just a black box but what if the video plays back but at 1 frame per second, or plays back with the wrong colors. It's impossible to know without knowing the exact source content, a luxury that a UGC platform like Twitch does not have.

For this reason just doing heuristics with WebGL is often the "best" path to detecting bad actors when it comes to decoders.