True that.You are comparing video editors that takes Gigabytes of RAM and video player, that takes a few 100MB...
I forgot to mention that sometimes hitting the "e" key too many times to go to the next frame results in vlc freezing. Not sure what's causing that.All I have to do then is hit eeeee f eeee f e f e f eeeee f and I have captured the critical snapshots of the bouquet toss.
I have a patch for this.I forgot to mention that sometimes hitting the "e" key too many times to go to the next frame results in vlc freezing. Not sure what's causing that.All I have to do then is hit eeeee f eeee f e f e f eeeee f and I have captured the critical snapshots of the bouquet toss.
Not all file formats support accurate seeking efficiently. In general, you still need to parse the file linearily from the beginning to get an accurate backward change of time position. And frankly, I wouldn't call decoding everything from the last keyframe as an "low on resource", even if the file formart supports accurate seeking more efficiently.Logically [because] you obviously can't go back one frame with the way normal video compression works, it must be stepping back to the first full video frame, key frame, i frame, whatever the proper term is, then encoding forward to "current frame - 1"
i´m also 100% with you.Not all file formats support accurate seeking efficiently. In general, you still need to parse the file linearily from the beginning to get an accurate backward change of time position. And frankly, I wouldn't call decoding everything from the last keyframe as an "low on resource", even if the file formart supports accurate seeking more efficiently.Logically [because] you obviously can't go back one frame with the way normal video compression works, it must be stepping back to the first full video frame, key frame, i frame, whatever the proper term is, then encoding forward to "current frame - 1"
Now if we assume that:then, sure, it is theoretically possible to seek backward and with that, implement step-by-step previous frame.
- the file format supports accurate seeking efficiently,
- the video is encoded with reasonably frequent key frames,
- and the system is powerful enough to decode a full group of picture faster than the user will skip frames
But how do you explain the above constraints to typical users?
And who will spend the time or money to implement all of that in VLC? (Realistically, this requires quite a few developer-months or tens of thousands of euros.)
Return to “VLC media player Feature Requests”
Users browsing this forum: No registered users and 26 guests