I used Plex for my home media for almost a year, then it stopped playing nice for reasons I gave up on diagnosing. While looking at alternatives, I found Jellyfin which is much more responsive, IMO, and the UI is much nicer as well.

It gets relegated to playing Fraggle Rock and Bluey on repeat for my kiddo these days, but I am absolutely in love with the software.

What are some other FOSS gems that are a better experience UX/UI-wise than their proprietary counterparts?

EDIT: Autocorrect turned something into "smaller" instead of what I meant it to be when I wrote this post, and I can't remember what I meant for it to say so it got axed instead.

you are viewing a single comment's thread
view the rest of the comments

[–] CodexArcanum@lemmy.world 1 points 1 year ago

A simple explanation: Compressed video is typically stored in such a way that you have say, one full frame every 5 frames or so. The in-between frames are just what changed from the previous frame. (Actually, smart compression is adaptive, changing how many full frames it needs depending on what the content is.)

So going forward a frame is easy. The current view is stored in the frame buffer, and you just add the changes to the next frame.

Ah, but how to go back? There are (at least) 3 possibilities.

Reverse the process. "Subtract" the last frame data. But this may leave nothing behind, and so probably isn't viable.
Double buffer. You have to keep the previous frame around in a second buffer. This adds a new copy operation every frame, and another buffer in memory, but performance for that probably isn't too bad. But you eat that performance all the time just so you can rewind one frame. And to rewind more than just 1 frame, you actually need many past frame's buffered! So something more like a stack of old frames would need to be kept around (like a stack of photos) and you can riffle back through them anytime. We'd throw away old frames past the last checkpoint, but ultimately this is just an increasingly expensive way to do it. This would need to be optional I think.
Last option is the classic comp sci tradeoff: if option 2 used a lot of memory, option 3 uses a lot of calculation. Each time you go back a frame, we find the previous checkpoint frame, and then apply each change frame up to where you rewound to. This takes a moment to calculate each time, but unless you're QTE-ing on the frame back button it's probably fast enough!

The best solution probably mixes 2 and 3. Maybe a double or triple frame buffer, with the option to calculate new back-frames as further needed?

Anyway, that was fun to think about!