Correction: A shortcut key is there for frame stepping.and shortcut keys are there for frame-stepping
It is THAT hard to implement.I think a lot of people would like this "back-frame" function, including myself. It's almost impossible to capture the correct frame without this function. Surely it can't be THAT difficult to implement?
Wow!I have a quick patch for backward stepping. It is very very very very ugly and will not be merged. But if needed contact me (if you are a programmer, of course).
...I see it like this...have a pref: Number of frames to keep in memory for frame skipping, default to say 10 or 20. As VLC plays the file forward it would keep each frame (in memory or in a cache on disk), it wouldn't matter what format the source video was in (if VLC can play/decode the video, it can remember that frame), take one frame at a time (as you are playing the file normally) & "remember" them (basically do the same as the "snapshot" function, just to memory or a specific disk location {a cache, separate from user-initiated snapshots}). Regardless of muxer/codec/whatever...or being a local file or not. I understand "seeking" backward is "THAT hard" (even tho the seek bar does go backward?)...but this would not be seeking, it's just "remembering (caching) what you already decoded".It is THAT hard to implement.
...yes, I'm not a VLC dev, so I have no idea how frames are rendered. BUT I can imagine: you "somehow" decode the "frame" from all the file formats VLC supports, this part I don't care about...then you "draw" that frame to the screen, this part I do care about. As soon as you "draw" it to the screen, it might as well be a "screenshot"/"bitmap" (or other more compressed format, like png). That is what I'm saying: AFTER VLC's already decoded the frame, then save a copy to a buffer. Yes, I do know about "key frames", I do know that "not all frames are complete". But that's still simple: every keyframe, you start a new reference buffer frame: draw to screen, draw to a buffer (or draw only to the buffer & "copy" that to the screen {if copying is faster than "drawing" twice}). On the next frame, a non-keyframe, draw to screen (which properly covers the image already on screen), copy the last buffered frame to a new buffer & draw the partial frame on the copy of the buffer, so then the buffer would have a full "keyframe", for each frame. You can run the buffer (copy it to the screen) forwards or backwards (without seeking the original source), since they are essentially just images/screenshots now.Sorry, but you have a very naive idea on how frames are rendered in VLC.
...I have nowhere to start. & I can't compile VLC. You said you had a patch that was "very very very very ugly", if you posted that online somewhere, people would have a "place to start". I'd like to see the method you chose that, even you, thought was very ugly.Patches are welcome though...
The frames are inside the GPU. So you would need to keep 20 frames (btw, why 20 and not 40 or 60) of 6MB each in an extra memory pool on the CPU side and do one or two extra copying of ALL frames in VLC? You realize the impact in performance, no?I'd like you to tell me exactly why taking a "snapshot" of each rendered frame would NOT work. I think my idea is fine. Prove me wrong. No, I have no idea how VLC renders frames, but I'm talking about after it's on screen...or at least, after it's decoded & ready to be drawn. Once it's decoded & ready to be "drawn"...simply draw to the screen & also to a "frame buffer".
Return to “VLC media player Feature Requests”
Users browsing this forum: Bing [Bot], Google [Bot] and 3 guests