slhck

Yes, I mean cold sales emails – marketers reaching out to CEOs or other decision makers, selling them staff augmentation services, growth hacking, marketing support, lead generation, design services, etc. They'd claim legitimate interest by "personalizing" the email and claiming that it is relevant for you in a business sense. (Anyway, I don't think that these are fully compliant with GDPR either, because most often, they will have scraped your email address from somewhere, and do not provide a way to unsubscribe.)

Unfortunately, not in a business context, where marketers can claim "legitimate interest" in various ways. Also, in which way would it matter that they are illegal? Random companies keep sending them anyway; there are virtually no legal repercussions here.

Just saw this, and as a small business owner in the B2B market, this sounds very useful. Gmail's existing spam filters do not reliably detect this type of marketing.

I wish your landing page had a simple "how it works" explanation with a screen shot or diagram, rather than forcing me to sign in directly, and also allowing the app to read *and* send emails. Also, I don't see any pricing?

Finally, signing up, I got an error:

Error 1101 Ray ID: 89d4e0957c2f5a44 • 2024-07-03 06:39:15 UTC - Worker threw exception

I agree it would be good to clarify this. I have a product that does some background job processing using Sidekiq and Redis, and it seems that this would not constitute "making the software available", in particular where it says:

Making the functionality of the Software or Modified version available to third parties includes (...) offering a product or service, the value of which entirely or primarily derives from the value of the Software or Modified version (...).

Since the value is not _primarily_ derived from using Redis, I guess it's fine. I am sure the majority of projects using Redis in some way do not derive their main value from Redis.

Generally, capitalize longer words. But this really depends on the style book you choose to follow (MLA, APA, CMOS). See: https://en.wikipedia.org/wiki/Title_case

Sure, the whole point of CRF is to set a quality target and forget about it, or, with ABR, to be as good as you can with an average bitrate target (under constraints). But you can't do that across resolutions, e.g. do you pick the higher bitrate 360p version, or the lower bitrate 480p one, considering both coding artifacts and upscaling degradation?

> This is overrated - of course that's how you do it, what else would you do?

That's not what has been done previously for adaptive streaming. I guess you are referring to what encoding modes like CRF do for an individual, entire file? Or where else has this kind of approach been shown before?

In the early days of streaming you would've done constant bitrate for MPEG-TS, even adding zero bytes to pad "easy" scenes. Later you'd have selected 2-pass ABR with some VBV bitrate constraints to not mess up the decoding buffer. At the time, YouTube did something where they tried to predict the CRF they'd need to achieve a certain (average) bitrate target (can't find the reference anymore). With per-title encoding (which was also popularized by Netflix) you could change the target bitrates for an entire title based on a previous complexity analysis. It took quite some time for other players in the field to also hop on the per-title encoding train.

Going to a per-scene/per-shot level is the novely here, and exhaustively finding the best possible combination of QP/resolution pairs for an entire encoding ladder that also optimizes subjective quality – and not just MSE.

Precisely this! There's no need to code the same information twice; it just means you have to think more about what the graph shows.

Both. The 180 degree rule just makes sure motion blur looks as intended and is a mostly artistic choice that can vary depending on the scene. E.g. for action sequences or particularly smooth motion in a dreamy scene, you can break this rule. Or, if there's moving water, you might want to choose a particular shutter in relation to the preset frame rate.

The overall frame rate gives you the distinction between a typical movie vs a TV-style documentary. The overall frame rate stays fixed across a movie and should normally not be changed.

I'd say: "She has said goodbye too many times before."

Because it still has relevance for the present, it should be present perfect.

Unless if course it's about finally quitting, then the past tense makes sense.

Nice tool. Some suggestions:

- Allow playback via Space button. Show a play marker to let the user know where in the sample they are, even without having selected a part.

- Choose a sample that is easier on the ears than high-pitched bird song. I was really shocked when the first loud part came.

See https://tailscale.com/kb/1232/derp-servers/

They use those relay servers for handling NAT issues, and figuring out which one has the lowest latency requires them to ping them all.

That said you can run your own one if you need to.

I don't follow your argument. I've lived in various major European cities and it was always easy enough to find a discount supermarket (Lidl, Aldi etc.) within walking distance, and if not, maybe within 5 minutes of cycling. There would've rarely been a need to use the (more expensive, but certainly not 50%) corner grocery store. Everyone can afford this — quite the contrary: people often ignore the hundreds of Euros they spend on a car, because it's just a given for them. (That said, I know there are lots of people who depend on the car for getting to a work location because of lack of public transport.)

I don't know about the building you're talking about and can't weigh in on this.

Which are?

Sure, it does not hurt to wear such clothes. But those arguments aren't mutually exclusive, and by always repeating them, public discussions tend to shift towards the arguments that blame the weaker ones (i.e., cyclists, pedestrians), often neglecting the underlying issues at fault (reckless car drivers or unsafe infrastructure).

For instance, in many cases, when a car has injured a cyclist severely, there could have been infrastructure to prevent this (e.g. separate bike lanes, clear road layouts, …). A helmet would not have prevented the accident.

Similarly, unless someone's crossing a dark street at night without looking for oncoming traffic, why should pedestrians have to be wearing reflective gear all the time, when there could be well-illuminated crosswalks, slower driving speeds, speed bumps etc.?

(I'm not claiming there aren't cyclists ignoring red lights or pedestrians randomly crossing roads in unsafe situations … that's usually the next argument.)

It's apparently not in the interest of traffic engineers in the U.S. to care for pedestrian (or cyclist) safety. It's been this way since the post-war area where everything was built for cars, and this seems to have manifested in peoples' minds like the concrete they built. Hard to remove this. People seem to fight over minor improvements (like adding a protected bike lane or making safer crosswalks) while a drastic change would be necessary (like building completely different roads or changing underlying laws).

I'd recommend checking out the "Not Just Bikes" YouTube channel for some interesting observations on the differences between the U.S. and Europe when it comes to traffic safety. Also, Strong Towns is a resource you might want to check out: https://www.strongtowns.org/

From a technical perspective that would make sense, but it's unrealistic to achieve this in practice. It would be impossible for the entire market to support that. In order to maintain the artistic intent across different platforms, it's better to imprint it in the source. I guess lots of directors and DPs are frustrated enough with motion smoothing and other "enhancements" on modern TVs.

High-end digital cinema cameras are not _that_ grainy per se. The sensors are very clean.

The level of grain you get from digital cinema photography is mostly by artistic choice and added through the camera or in post production. Sometimes the movie is shot digitally and transferred to film, then scanned. This was done for Dune (2021), for instance.

Also, ARRI (who make the most renowned cameras for cinematic use) now specifically let you choose a grain texture on the Alexa 35 that is imprinted in the digital material. [1]

[1]: https://www.arri.com/en/learn-help/learn-help-camera-system/...

That would make sense. Just like some overlays could be added later.

Many productions specifically want film grain. Directors and DPs have very concrete aesthetic intentions when they go for film grain, so you're likely to find lots of movies with film grain added in post when they were shot on almost noiseless digital cameras. (For instance, one might scan the grain from an old film stock and apply it to the digital footage later.)

Netflix is only optimizing the pipeline here, trying not to mess with the artistic intent.

This article is not very informative. The referenced video is a couple of years old — this is all not news.

I think this article is just a plug for the company website and should be removed from HN.

This is a very comprehensive guide with actually reasonable examples and suggestions!

I think there's really not much more to add here, because eventually you'll be deep in the rabbithole that is FFmpeg, and you'll be browsing mailing lists, visiting Stack Exchange, etc. to get help.

Cross-referencing the FFmpeg wiki wherever possible would be good, as there is so much outdated information on the Internet, and at least the wiki is a somewhat up-to-date reference.

As someone who only needs to use Flexbox/Grid every once in a while, this is precisely what I needed.

I've been struggling with static documentation like the one from Tailwind [1] or MDN [2]. Writing good and intuitive documentation is hard, surely this must have been quite an effort.

[1]: https://tailwindcss.com/docs/flex-direction

[2]: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...

Yes, that is indeed a common problem. You can run Docker in rootless mode [1], which probably works for 99% of your development requirements. For production it is not always a good choice, as some features may not work properly (most importantly, Docker Swarm) or require extra configuration (allowing to expose privileged ports).

[1]: https://docs.docker.com/engine/security/rootless/

Your program needs to be able to output its version (e.g. with a --version CLI option), and with setup.py I could at least parse __init__.py. The pyproject.toml file doesn't do that, so suddenly I have to maintain two version numbers.

I maintain half a dozen small Python packages. I don't do emails, tweets, etc. I just want to create releases easily when there's a bug fix. It not only saves time to automate this step (I can use the same script to release each package), it also means you can't forget things. Before I had a script, I always forgot to push the tag, or run the changelog, etc.

I know commitizen and it doesn't do that. It enforces particular forms of commit messages, but it does not bump versions in Python projects.

This is really nice. The only thing I'm missing here is a simple way to bump versions. Any ideas on how to do that?

For Node, it's quite simple and even built into npm. Also the version is only part of the package.json file. For Python you probably have your version somewhere in __init__.py, and I always end up writing ugly bash scripts that modify multiple places with sed.

He actually sold $2 million worth of shares two weeks ago. Good timing, I guess?

https://www.sec.gov/Archives/edgar/data/1527728/000173112222...

This is really interesting. Have you published this approach somewhere? It'd be nice to read more about it.

And the issue with that is that they're using PSNR and SSIM as quality metrics, which are useful for images, but haven't been designed for video, so they cannot take into account temporal factors and how motion masks distortion, etc.

I think for AV1 they're using VMAF too, which is an actual video quality metric (https://github.com/Netflix/vmaf).