- For the convert page, the tool seems to conflate codec and container format. For example, for MKV option, the tool specifies libx264, when MKV is capable of many more codecs. In addition, a lot of the times when people want to "convert", e.g. from MP4 to MKV, they mean to remux - i.e. "-c copy", which doesn't seem like an option here.
- For the compress page, the tool allows you to specify the target size, however the command output limits bitrate instead of target size. This means that the output size will vary depending on how long the input is, and will almost never be the specified target size.
I would suggest merge the "Convert" and "Compress" tabs, and allow specifying:
- video bitrate (-b:v)
- video codec (-c:v)
- audio bitrate (-b:a)
- audio codec (-c:a)
- container format
I found handbrake to be a good GUI-based alternative if ffmpeg commands are overwhelming.
It’s worth noting that this same restriction of not being able to do perspective transformations is also one of the defining characteristics of PlayStation 1 graphics. And the workaround of subdivision is also the same workaround PS1 games used.
I made something that achieved similar results with existing technologies by abusing STUN/TURN.
It does not handle discovery but it does allow local communication without a server.
I have the 5-bay variant of the same NAS. I decided to put TrueNAS Scale on it using a Samsung USB stick using the internal USB. I chose one that’s widely used for Tesla dashcam, so I know it is at least somewhat durable.
I’m happy with it so far. I still find the CPU performance very lacking so I’m planning on upgrading to something beefier.
The reason I think is that GM is multinational. And while Buick is not doing well in the US, it’s doing very well in China (80%+ of sales of the brand is in China).
The crosswalk button my city uses has an LED that illuminates if the button was pressed before. It’s a great UX improvement over the ones without the LED.
(1) Noted. The main graphic emphasizes reporting rate over the delta, in both the axes selection and the ranking - and indeed the ranking is the main takeaway from many of the readers. If you rank by percentage delta of report rate, the graphic would be drastically different. This newer graphic wouldn't be "fair" either, as countries with higher control (no money) report rate would have a relatively low percentage delta.
(2) The World Bank Enterprise Survey data is listed under the title "Percent of firms using e-mail to interact with clients/suppliers" (for which China is at 85%) which I think is not the same as email penetration rate (which in the above reference in my parent comment, is at <40%). I understand your reasoning that cross country data is hard to come across.
I also read your reply in Science. I believe that while there are multiple limitations conducting the research - all perfectly reasonable - the limitations nonetheless affected the credibility of Fig. 1 - the main figure of the paper.
It is also mentioned in the reply that creating new social accounts is unfeasible. While I think this is true, wouldn't a single account per platform suffice? Most social platforms allow anonymity for display names / handles. If the social account name does not bear resemblance to an actual name, I don't think the participants would notice.
> The business cards displayed the owner’s name and email address and we used fictitious but commonplace male names for each country.
This is assuming that email is a ubiquitous communication method in all countries, which is not true. USA has a very high email penetration rate, so does Japan (where all phones use email instead of SMS). On the other end of the spectrum, China's email penetration rate is less than 40% [1]. Business in China is conducted over WeChat and phone calls instead of email. If the person receiving the wallet does not have an email account, or doesn't even know what email is, I'd imagine the email contact rate to be quite low.
I know exactly where this is from. This has been floating around the Chinese Internet for a bit. The repo is originally at https://github.com/wheatup/evil.js but has been made private since then. A few variants of this was made and uploaded to NPM.
Here's a English translation of the README.md in that specific repo.
> What? The notorious 996 company wants you to hit the road?
>
> Do you want to leave a small "gift" for your project before you go?
>
> Let's sneak this project into yours, and your project will have, but not limited to, the following magical effects:
>
> - When the length of the array is divisible by 7, Array.includes will always return false.
> - When it's Sunday, the result of the Array.map method always loses the last element.
> - There is a 2% chance that the result of Array.filter will lose the last element.
> - setTimeout will always trigger one second slower than expected.
> - 10% of Promise.then will not register on Sundays.
> - JSON.stringify will change uppercase I to lowercase l.
> - The result of Date.getTime() will always be one hour behind.
> - There is a 5% chance that localStorage.getItem will return an empty string.
We must protect human lives at all costs, even at the cost of human lives.
Jokes aside, what we really want to know is that - what are the human lives lost lockdown v.s. no lockdown, maybe also factor in the possible economic downturns. The government did a not-so-good job convincing people that doing a lockdown is indeed better than the alternative - "We ran the numbers, it seems like doing a lockdown at this stage is beneficial" sounds better than doing a lockdown just for the sake of it.
And: limiting information to people doesn't help boost confidence.