slashink

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.

Resolved this with nyanpasu64.

I understand the concern, trust me. We’re working on alternative methods.

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.

I didn't interpret the comment as an acquisition to my original comment.

It's good to ask the hard questions and even though I'm not able to answer it in detail I still think that 'tmpz22' brought up a good point in that data can be used for both good and bad at the same time.

Good question!

So the problem here is a bit different. It's not that devices will say "I can play Format X" and then not play it. It's that devices say "I can play Format X at Resolution A, B, C". When you give the device resolution A and B it succeeds but at resolution C it fails to decode it.

In H.264 this would be the "Level" https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels . A device may say that it can decode Level 4.2 but in reality it can only do 4.1. That means it can play back 1080p30 but not 1080p60. The only way to know is to actually try and observe the failure (which often btw is a silent failure fro m the browsers point of view, meaning you need to rely on user reports).

I don't work at Twitch anymore so I can't answer your question without guessing and I rather not.

There is always a likelihood that data gets used for reasons beyond the original purpose. In the best of world the hardware that runs on consumers devices would do the right thing which would allow the web to be a perfect sandbox. I think we're slowly getting there, in terms of video it's slowly getting to a point where H.264 support is "universally true" rather than a minefield although VP9 and AV1 is a bit of being back to square one.

I think the spirit of my original comment was not to say "I promise that X company isn't doing Y" more to explain why this code existed in the first place. A search engine doesn't need to know what WebGL capabilities a device has as it doesn't deal with rendering whereas a site that has to work with hardware decoders most likely does need to know.

That's a fair take. In a sense it's is a "fingerprinting" method although I personally think fingerprinting embodies using this data to track devices between contexts.

If you're interested why this data was exposed in the first place, the MDN docs has good info https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug... . "Generally, the graphics driver information should only be used in edge cases to optimize your WebGL content or to debug GPU problems."

Sadly that's the reality of some of these tools. The intent was good and in many cases they are a necessity to create a web experience that works on every device. On the flip side this allows people to use this data to fingerprint.

Some of these are probably fingerprinting but the Twitch one isn't (I worked on the video system at Twitch for a number of years).

"player-core-variant-....js" is the Javascript video player and it uses WebGL as a way to guess what video format the browser can handle. A lot of the times mobile android devices will say "I can play video X, Y, Z" but when sent a bitstream of Y it fails to decode it. WebGL allows you to get a good indication of the supported hardware features which you can use to guess what the actual underlying hardware decoder is.

This is sadly the state of a lot of "lower end" mobile SoCs. They will pretend to do anything but in reality it just... doesn't.

Compared to losing the RV it seems like a negligible cost for what the commenter describes as “older RV”.

I have zero tolerance for trying to evaluate candidates on things other than performance against what the interview is benchmarking against. Hearing something like that would have had me instantly report it to HR.

It makes me angry now even reading it. Why would this have any impact on the work the candidate would be able to perform?

I hadn’t considered this before but you’re absolutely right. Driving is a continuous operation so it’s almost impossible to pick up without the prior context.

You just let the javascript send a heartbeat ping. If you don't receive the ping but served the page you can determine that the user agent did not execute the javascript.

Yeah also you are technically right. The specific reason we ended up at 44100 is a VHS constraint but the 44* ballpark was what I wanted to clarify. Nevertheless always fun to see this pop up on HN, there is so much forgotten reasoning about standards that we’ve carried over into the modern world.

Not the only reason. A combination of CD targeting a useable spectrum just above 20KHz (human hearing) which meant having more than double due to Shannon-Nyqvist ( https://en.m.wikipedia.org/wiki/Nyquist–Shannon_sampling_the... ). With the need of filter cutoff on the high end, 44000 was enough to avoid aliasing and still have a good useable spectrum.

The second part is finding a good sample rate that you can easily clock on VHS. That’s where the this stems from although they technically could have gone for a different sample rate at a lower bit depth. 44100 ended up being a good trade off between different requirements.

Most 4K demos on Pouet the last years has been Windows only. Demoscene parties usually specifies exactly what computer they will run the demos on in advance so groups can optimize for that setup. The code sometimes only run on that particular setup.

It's a term for "light bloom" commonly used in rendering and games. https://en.wikipedia.org/wiki/Bloom_(shader_effect)

You're right that it's not that related to a bloom filter data structure.

The tip that someone gave me a couple of years back that has changed my writing is to once the document is finished, print it (or transfer to another shaped device/change the font) and read it out loud for yourself. Transferring the writing to another environment and medium (speech), errors that you've missed for days suddenly become very obvious.

Doesn't take that much time and the quality of the writing goes up when hearing the prose as I perceive it differently, which allows me to feed this back into the final edit.

Always a balance with a tradeoff, I'm not sure if to uninstall here or come to terms with the business model.

Hello! I work on the video platform @ twitch. We’ve been working a lot on that issue. Viewer count numbers should be significantly faster today and will get even more responsive soon!

I'm open to help write bindings or cool demos if you're interested.

I would love to use your algorithm for a personal hobby project. So far I’ve ported other similar algorithms such as Colorchord but this seems like an interesting take on getting data out.

Being able write a lib to plug into TouchDesigner or OF would make it fun to write other kinds of visualisations.

Wasn’t the timeline concept a core part of Google Wave? If I recall correctly you were able to scrub through the entire history of a document in a similar way.

I can’t comment on your opinion here because I don’t know enough, but I wanted to highlight how interesting the use of the word “cosplay” is.

I understand exactly what you mean when you use the word cosplay, however, it also strikes me that this word wouldn’t be used in the same way 10 years ago as it is today. Just an observation.

Yeah I take issue with this also. I've tried to get my dad to stop smoking for the past 15 years and I've come to terms that it just won't happen.

So for me it's more about helping him risk manage, getting him on vaping instead of cigarettes is "less shitty" way of getting that fix for him, even if I'm fully aware that it's not healthy in any shape or form.

It's the lesser of two evils for sure, however, nobody should pick up vaping if you aren't currently smoking cigarettes.

You’re right. Aviation comes down to being a numbers game. If one aircraft exhibits variances, the problem needs to be understood and if bad fixed before it has a chance to cause a real issue.

Sony ARW is 14 bits on the A7 line. Canon 5D Mark IV RAW is 14 bit and so is the Nikon counterpart. Even the cheap Blackmagic Pocket Cinema Camera shoots 12 bit RAW.

Why is this important? Most of these cameras images end up on the web. VP9, HEVC and HEIC all support HDR10 so with the right processing this should come through.