1061
What are some FOSS programs that you think are a far better user experience than their counterparts? (sh.itjust.works)
submitted 2 years ago* (last edited 2 years ago) by to c/opensource@lemmy.ml
627 comments fedilink hide all child comments
 

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
[–] 2 points 2 years ago* (2 children)

From what I recall it has to do with encoding and how the data stored references the following frame but not previous. Still seems like some engineering could be done to solve, so it it's not as simple as "current Frame--"

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 3 points 2 years ago

    It's absolutely possible, though. MPV has it. It definitely takes longer than going forward, and sometimes I have to press the "back one frame" shortcut 2-5 times per frame. But, it does exist.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 2 years ago (1 child)

    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.

    1. Reverse the process. "Subtract" the last frame data. But this may leave nothing behind, and so probably isn't viable.
    2. 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.
    3. 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!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    Option 3 is the usual method, & it works quite fast on almost any machine that's even capable of decoding high bitrate video fast enough to keep up with its framerate, in the first place. On a HDD, that previous frame may briefly require seeking to get back to, but no such delay occurs with flash storage.

    Of course, it doesn't need to be done fast; we're talking about long looks at single frames!

    For best results, frame-capture apps use cross-frame interpolation with motion estimation (& these days, AI).

    I don't remember the last device I saw, that would struggle with this in any way. It's basically just been dismissed as unimportant, by the VLC devs, rather than actually being all-that-difficult to implement.

    I'm shocked that VLC doesn't offer reverse playback by now, given the absolutely enormous video resources & random access storage, we're all blessed with now.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •