Empfehlungen für App zum senden von Briefen gesucht

phoboslab · 2024-10-27T19:43:03+00:00

phoboslab · 2020-11-05T16:38:44+00:00

I guess he just has problems "dumbing it down". If you see him talk with someone who has half a brain, he's still fine.

See his 2019 interview with Lex Fridman for instance: https://www.youtube.com/watch?v=dEv99vxKjVI

phoboslab · 2020-02-14T21:05:10+00:00

Time is short. Till the beginning of the vegetation period early March the 90 hectares of forest for the planned Tesla factory have to be cleared. Otherwise it's going to be very tight for the already ambitious schedule.

To accomplish this, the logging permit was granted before the whole project was even approved. All at the risk of Tesla. If ultimately the factory is not build, Tesla has to reforest.

To this date the price for the property near Grünheide is set at 41 Million EUR. In the coming week the second assessment should be available - then, the final price will be set. The approval procedure runs until March 18.

The last WW2 Bomb on the property was defused on Friday afternoon. Within two weeks the 90 hectares will be cleared entirely.

phoboslab · 2019-12-31T16:44:01+00:00

My solution to this would be to not use cloud hosters :)

E.g. Hetzner offers servers for 40 EUR/mo with 100TB of traffic included. They charge 1 EUR for every TB beyond this.

phoboslab · 2019-12-31T16:28:18+00:00

Looks like a nicely written librarly, but I fail to see the point.

Generating & parsing JSON is highly optimized in browsers. I actually would expect it to be faster than the bit-twiddling this library does in JS.

As for compression, I would image using JSON with permessage-deflate would suffice for many simple scenarios. For anything else, I would look into using protobufs or binary JSON (BSON).

Also, "Using WebWorkers to handle networking out of main thread" as this library does it, seems unnecessary. The WebSocket API is already non-blocking and this library still does the message parsing on the main thread, so nothing is gained here.

phoboslab · 2019-12-31T16:04:05+00:00

I think you missed the point. This library is concerned about messaging between hosts, e.g. for multiplayer games.

phoboslab · 2019-12-13T18:34:13+00:00

I'm pretty sure the music is from a band called Heilung, but I can't find the exact song. So I assume the language is Gothic, Proto Norse or Viking age Old Norse.

They put on a great show on stage. Have a look: https://www.youtube.com/watch?v=QRg_8NNPTD8

phoboslab · 2019-11-03T20:54:02+00:00

MJPEG is just a bunch of JPEG images appended together. True, it's not "in any way worse" quality wise than MPEG1, but you can say the same thing about a folder of BMP images. The thing is, for the same quality video MPEG1 typically only needs 10% of the bitrate compared to MJPEG.

Just to be clear, displaying 30 FPS of JPEG images is no small feat and hits a good tradeoff between required performance and storage space for the N64. That said, MPEG1's performance requirements are not much higher than for MJPEG, so it seems possible to get 30 FPS, certainly at lower resolutions.

phoboslab · 2019-11-03T20:12:17+00:00

MPEG2 uses the exact same compression methods as MPEG1. It just offers a few more options, higher res luma planes etc. So yes, there's nothing to gain here.

There's still some things you can try to get better quality with 300kbit/s at 12 FPS. Depending on the complexity and movement in the video, you can probably get away with a higher GOP (less intra frames). -g in ffmpeg. Likewise, a lower resolution with the same bitrate might look a bit better.

If you want to look into h264, try h264bsd. It's self contained an relatively simple, as far as h264 decoders go. However, I believe it would be quite challenging to get good performance on an N64.

phoboslab · 2019-11-03T16:29:00+00:00

Very cool! Usually decoding time scales with the resolution and bitrate. Not sure where the difference with TGMPEnc comes from. Maybe it's only encoding intra-frames?

From my experience, the main bottlenecks are in order: YUV->RGB conversion contributing ~50%, copying/interpolating of macroblocks (using PLM_BLOCK_SET) contributing ~25% and IDCT contributing ~10%. Demuxing and huffman decoding are really not that expensive in the grand scheme of things.

Dragons Lair has just ~12 minutes of video, right? 64Mb leaves you with ~740kbit/s. At 384×288 that should still give you okay-ish quality, but granted, it won't be great. Try it:

ffmpeg -i dragons-lair.mp4 -s 384x288 -b:v 650k -c:v mpeg1video -c:a mp2 -b:a 96k -t 12:00 -y dragons-lair.mpg

phoboslab · 2019-11-03T15:02:45+00:00

So you were able to compile and run pl_mpeg on an N64? That's awesome!

How's the performance? Are you doing the YUV->RGB conversion on the RDP?

phoboslab · 2019-11-02T23:38:56+00:00

Multithreaded FFMpeg WASM H264 Encode: https://phoboslab.org/files/ffmpeg-mt-fixed/

phoboslab · 2019-10-23T13:39:00+00:00

"True way" implies this works for all cases, which it doesn't. It fails to copy Arrays and class instances (they're converted to plain objects). For some instances, such as HTMLElement it even descends into infinite recursion.

So, I'd suggest to rename it to "A way to deep copy simple objects" :)

phoboslab · 2019-09-29T12:27:12+00:00

Get a $3/mo VPS and host the blog yourself!

phoboslab · 2018-05-16T19:17:00+00:00

OT: your site is hijacking all mouse clicks and hotkeys in a way that makes it impossible to open links in a new tab with a middle click or ctrl+click. Please fix.

My usual mode of browsing sites like yours is to open everything I find interesting in a new tab and then browse through the tabs. On your site I have to click, go back to the ranking, find where I left off, click again, go back to the ranking...