this post was submitted on 21 Sep 2023
1036 points (97.8% liked)
Open Source
31760 readers
182 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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--"
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.
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!
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.
That makes a lot of sense, thanks! I'm a dev but not in video so it's always nice to learn a few things about how problems in other domains are solved.
Reverse playback would be pretty fun! Maybe it's hard to sync up the reverse audio? 😄
Hahahah, very!