Is there a previous frame hotkey?

[beef623]

Would it be reasonable to add an option to provide the number of frames to cache for stepping through?

I don't think there are a huge number of people asking for this so even having it in the advanced section and defaulting it to 0 would probably be ok.

Then, when someone steps forward, just before the step is made cache the frame you're currently on up to the amount configured by the queue and just drop the last one off the list if more than that are stepped through. Then you'd also know how many frames you have so you could prevent a user from going farther back than is queued (maybe with a little error message).

[Rémi Denis-Courmont]

If hardware decoding acceleration is in use, which is most often the case nowadays, this would not be configurable, so not much point.

[beef623]

Ah, gotcha.

[JuicyJuuce]

I think one of the breakdowns in this conversation is that many users are coming here with their experiences that represent typical use, but Remi as a developer has to keep in mind all the atypical uses, no matter how uncommon they are. This is, after all, what sets VLC apart from all the other players in the market: it's broad video format support.

In that light, one of the repeated arguments boils down to, "why don't you just do what I'm already doing manually: stepping back 3 seconds and then going forward until we get back to where we started." Remi's response seems to be simply that not all video formats support that stepping back ability, which appears to me to essentially be the same as the "Jump To Specific Time" feature. I don't have one of those atypical videos on hand in order to test this, but presumably VLC knows if the currently loaded video is incapable of supporting "Jump To Specific Time" or if not it fails gracefully once the user tries to use this feature.

Maybe VLC could have a bimodal response in order to provide the previous frame feature. If it can jump back a few seconds, great, problem solved. In the scenarios where it can't, it instead jumps back to the beginning of the video and gives the user a progress bar dialog box in the middle of the screen as it scrubs forward to the original frame. This dialog box would have a "cancel" button in case this task takes inordinately long.

Since, as Remi has described, other video players do not support "previous frame" for these problematic video formats, in the end VLC will be left having comparable capabilities to its competitors for typical video formats and an altogether unique (if slow) capability that all its competitors lack for the problematic formats.

(Alternatively, VLC could simply indicate to the user that this feature is not available for the problematic formats, in the same way that it currently does for the "Jump to Specific Time" feature.)

[moviesfan20]

I've read most of this thread and I think I have understood the issues.
I'm almost affraid to say this, but I might have an idea...
I really do believe I could help here.

Why complicate things by figuring out how to go backwards, when it could be done the easy and dumb way, going forward instead?
Hear me out:

User plays the video in whichever format he likes. The video plays as it normally does until the user decides to pause.
From here the user could then presses the "next frame" button. VLC would then transcode the next 15 frames in the background to a (lossless) format that DOES support backward frame navigation.
The user could then navigate forward for 15 frames and then backward within them. What's important to note is that the user CANNOT go backwards from where he paused, and can only navigate from within the 15 frames ahead of the pause.
This solution seems to work for the issues in this thread!

If you have can't resuming because it's impossible to know which frame we are on after the user moved frames? So what, just resume at the same place he paused, as if nothing was changed, end the subroutine and continue.
15 frames is too much? Make it 1 by default and let the user decide.
Hardware decoding acceleration an issue? Make it only available if the user disables acceleration. OR since the video is already paused, it could even be disabled when starting to transcode and re-enabled right before the user resumes the video.
Yeah, this might be more complex than I give it credit, but I believe that the possibility of navigating frames more valuable than acceleration or memory, and I'm sure, as you know, I'm not the only one.


There is one downfall to this and it comes down to: is VLC able to transcode from the current paused frame. I assume it is possible to transcode directly from the data in the GPU buffer but if it's not possible for every format, well, I don't have a solution other than forcing the current frame to become an I-frame (if that's even possible) to speed up the transcoding.

On a side note: Technically the forward frame limit is still limitless, well.. if this solution is dynamic.
This solution needs a "max backward jumps/frames". The user would still have unlimited forward steps but the transcoding would have to be done gradually following the user forward and keeping the backwards limit to the same value (on purpose) making it so it would lower memory and processing without going behind the pause frame.


Point being: 100% of the users that do not want frame-by-frame navigation will have 0 impact by this solution because it is only computing things AFTER the user paused AND then pressed the "next frame" button.
If you don't use it, you won't see it or feel it.
Other than the possibility of this solution being impossible, it's fool proof. It CANNOT affect anyone negatively when deployed: It is opt-in by design, working almost as it's own seperate thing.

Sure it's not the prettiest or most efficient, but It can be implimented in a way that works for every kind of video format (assuming my above assumption) without one's head or computer exploding trying to make the code work for each and every other format.
It gets the job done and being only 15 frames, I can't see how transcoding that runs on the side while paused would cause more issues than it solves. (Technically I can, but I think it's worth a shot.)

I for one would call that a good feature. One I would have no problem using instead of an impossible to make full backward navigation.
It's ALMOST just as good, but outright ALWAYS better than nothing.
On the bright side, it would also satisfy 95% of the comments here and in the ones in the future.



Sorry for the super long message, I sort of tried to keep it breif and detailed.
I am truly trying to help make life a bit easier by giving my input.
Best of luck, hope it helps.

[Rémi Denis-Courmont]

That can be done in theory. It just won't do what people want, which is to go backward from the current point (i.e. without first going forward).

[moviesfan20]

Yeah, that's where I thought this solution could bridge it.
Though, like you say, it's not going backwards, but if someone was given a big enough amount of transcoded frames, would they even notice?

It might not be exactly the same thing, but many of the requests I've seen mainly just want a way to undo the last action of "next frame" (a ctrl+z basically), either for comparason, screen capture, precision, etc.
Given that people tend to look at media in forward speed, as long as they pause before what they are looking for, I don't think anyone would complain, let alone notice.
If (and when) they do notice and wonder why, at least the explanation is a much easier pill to swallow.
A simple "can't jump frames behind the pointer" popping up on the screen would be enough for most.
Best of both worlds.

There is major twist to that idea, might be overkill, but does seem feasable: it is to constantly transcode but also have the video playback lagg behind it, so to speak.
This is quite a different angle and I do understand why it's not really desirable since it must be constantly transcoding rather then only running when paused and at that point I think it's inching closer to video editing.
Otherwise, another idea; who's to say you must always display the first frame in the GPU frame buffer?

[JuicyJuuce]

Maybe VLC could have a bimodal response in order to provide the previous frame feature. If it can jump back a few seconds, great, problem solved. In the scenarios where it can't...

Any thoughts on my comment above? After reading through everyone's comments, I believe it addresses everything.

[Rémi Denis-Courmont]

Because of how buffering works, VLC rarely ever has previous pictures left (other than the non-chronologically order reference pictures). The picture buffers get used for forward picture decoded ahead of time. So in practice that trick would basically almost never work.

The only way to implement backward frame-by-frame is to implement backward playback and that's extremely complicated (and slow) as noted many times.

[JuicyJuuce]

Maybe I'm misunderstanding (or maybe you mistook my comment for someone else's) but I don't believe the proposal I described above depends on using leftover previous pictures. The idea was essentially to jump back a few seconds then scrub forward to the N-1 frame (like what most users are currently doing manually to simulate a previous frame feature in VLC). If jumping back a couple seconds is not possible for the current video's format, then jump back to the beginning of the video or have the previous frame feature greyed out (kind of like how "Jump to Specific Time" is disabled currently for videos that can't support that feature).

[Rémi Denis-Courmont]

In other words, you want to add a backward button that is always greyed out.

[JuicyJuuce]

Don't most users experience having the "Jump to Specific Time" button usually not greyed out? If that feature is supported for a given video format, then won't the method I described also be? (Since it would depend simply on the ability to jump back to a specific time a couple seconds earlier and then scrubbing forward from that point to the N-1 frame.)

[Rémi Denis-Courmont]

Jump to specific time is a lie. It's not accurate and/or will wait for the next key frame in most cases.

And even then how do you know what time to jump to? Not all media have fixed exact informed frame rate.

[JuicyJuuce]

Doesn't each frame in some common media formats have some sort of identifier or time stamp? So that even if jumping to a specific time a few seconds back is not very accurate, if from that point you stepped forward frame by frame you would (in those media) know when you arrived at the N-1 or N frame just by looking at that?

Or is there really no way for VLC to identify the fact that it has arrived back at a frame it has played before? (in some common formats, not all)

[Rémi Denis-Courmont]

This has already been covered in previous posts. We are turning in circles here.

The shared understanding of the main VLC developpers that this is very hard and tedious to implement and would have terrible performance, so we don't have the time and motivation for it. If you disagree, then this is an open-source community project, so by all means, do the implementation and submit it.

[eraclitus]

After a long time, I just installed VLC to give it another try, and realized that the previous frame hotkey is not available.
I briefly went through some pages of this thread. I see technical reason have been mentioned.
I tried tons of video players and yes, there are indeed few video players capable of handling the frame-by-frame approach flawlessly.

I'm adding this here in case someone is looking for an alternative solution.
So, for Windows users, if you need a good solution to the frame-by-frame problem on Windows, give Bomi a try.
In my experience, is the most reliable player for that case scenario.
It's been discontinued, and the last release is from 2015, but it runs just fine, and the UI is still great giving the user an almost borderless experience (the only thing you'll notice while playing a video is the topbar)
I've been using it for my work on a daily basis for many years now without any issue.
The hotkeys for previous, and next frame are customizable. I assigned mines to

Code: Select all

[

and

Code: Select all

]

like in Blackmagic Fusion.

[gatoamb]

I don't believe there is. Is there a way that it could be made known to the developers?

[gatoamb]

A related idea: why don't you let the user decide how much time is buffered for both backwards and forwards (separately) from the current point meaning a computer wouldn't have to do more work with it's processors, just keep the preloaded memory for a few seconds longer. It is already buffering forward, so it should not be hard to keep the buffer. Also any frame buffer is much more important than my otherwised unused memory. I have no experience with doing stuff like this, but to me it doesn't sound too hard to implement.

I've read most of this thread and I think I have understood the issues.
I'm almost affraid to say this, but I might have an idea...
I really do believe I could help here.

Why complicate things by figuring out how to go backwards, when it could be done the easy and dumb way, going forward instead?
Hear me out:

User plays the video in whichever format he likes. The video plays as it normally does until the user decides to pause.
From here the user could then presses the "next frame" button. VLC would then transcode the next 15 frames in the background to a (lossless) format that DOES support backward frame navigation.
The user could then navigate forward for 15 frames and then backward within them. What's important to note is that the user CANNOT go backwards from where he paused, and can only navigate from within the 15 frames ahead of the pause.
This solution seems to work for the issues in this thread!

If you have can't resuming because it's impossible to know which frame we are on after the user moved frames? So what, just resume at the same place he paused, as if nothing was changed, end the subroutine and continue.
15 frames is too much? Make it 1 by default and let the user decide.
Hardware decoding acceleration an issue? Make it only available if the user disables acceleration. OR since the video is already paused, it could even be disabled when starting to transcode and re-enabled right before the user resumes the video.
Yeah, this might be more complex than I give it credit, but I believe that the possibility of navigating frames more valuable than acceleration or memory, and I'm sure, as you know, I'm not the only one.


There is one downfall to this and it comes down to: is VLC able to transcode from the current paused frame. I assume it is possible to transcode directly from the data in the GPU buffer but if it's not possible for every format, well, I don't have a solution other than forcing the current frame to become an I-frame (if that's even possible) to speed up the transcoding.

On a side note: Technically the forward frame limit is still limitless, well.. if this solution is dynamic.
This solution needs a "max backward jumps/frames". The user would still have unlimited forward steps but the transcoding would have to be done gradually following the user forward and keeping the backwards limit to the same value (on purpose) making it so it would lower memory and processing without going behind the pause frame.


Point being: 100% of the users that do not want frame-by-frame navigation will have 0 impact by this solution because it is only computing things AFTER the user paused AND then pressed the "next frame" button.
If you don't use it, you won't see it or feel it.
Other than the possibility of this solution being impossible, it's fool proof. It CANNOT affect anyone negatively when deployed: It is opt-in by design, working almost as it's own seperate thing.

Sure it's not the prettiest or most efficient, but It can be implimented in a way that works for every kind of video format (assuming my above assumption) without one's head or computer exploding trying to make the code work for each and every other format.
It gets the job done and being only 15 frames, I can't see how transcoding that runs on the side while paused would cause more issues than it solves. (Technically I can, but I think it's worth a shot.)

I for one would call that a good feature. One I would have no problem using instead of an impossible to make full backward navigation.
It's ALMOST just as good, but outright ALWAYS better than nothing.
On the bright side, it would also satisfy 95% of the comments here and in the ones in the future.



Sorry for the super long message, I sort of tried to keep it breif and detailed.
I am truly trying to help make life a bit easier by giving my input.
Best of luck, hope it helps.

[Rémi Denis-Courmont]

That approach cannot be generalised into a proper solution to play backwards, so it only makes sense if users would actually want it as is.

And I'm pretty sure that most users in want of backwards frame-by-frame would not be satisfied with that. With that said, if you think they would, patches are welcome.

[ayaheey]

Holy hell.
The amount of entitled people with absolutely no tech background coming here, and not only demanding volunteer developers do what they want, but having the audacity to tell the developers what and how to do it rustled my jimmies so hard I made an account just to comment on that.

Literally who on God's green earth do you think you are, barging in here, giving the software engineers your advice on how to continue their work on the VLC project? Do you honestly think that, you, Mr "My-parents-think-i'm-good-with-computers-i'm-sooo-tech-savvy" have just come up with a solution to a 10+ year-old algorithmically impossible question? What sort of self-absorbed narcissist thinks he just figured it out better than the people working on it for years?

The type of people who always go "I've got a great app idea wanna hear it?" when you tell them you're a developer.

"what you mean codecs and video formats and complexity theory bro just..just you know, the way it goes a frame forward, but the other way around. get it?"
"hurr durr what you mean much memory i got memory bro just put a checkbox for potato pc people"
"muh GOP bro 3 seconds buffer it you know the cache"
"b-but other players do it youre just lazy why not just buffer a second whats the matter"

You absolute muppets.
You turd-hurling baffoons.

[JuicyJuuce]

a 10+ year-old algorithmically impossible question

It’s not algorithmically impossible, it’s just not generalizable to all video formats. As evidenced by the fact that several other video players have this functionality and that the developer in this thread ultimately admitted that the issue is that it would be difficult and tedious to implement.

And that’s fine! It’s volunteer work for free software, they have zero obligation to do anything. The issue is doing the motte and bailey of acting like it’s algorithmically impossible and then falling back to saying it’s too hard when challenged. Just say it’s difficult and not worth your time and leave it at that.

[Rémi Denis-Courmont]

It is generally impossible with both bound algorithmic complexity and bound memory usage. Nobody ever said that it was systematically impossible.

To take the extreme, if you have a file consisting of only one track of raw video at a fixed frame rate and nothing else whatsoever, then you can trivially implement accurate seek and don't need to pre-roll the video decoder.

What I did see is insults and mockery made of the developers, with the worst offences having been censored. By taking the defense of those despicable people and attacking the developers, you are leaning on the limits of what the administrator tolerate here. You have been warned.

[NARFNra]

Hi! I would like to make a suggestion. My apologies if this seems presumptuous, but I thought I'd offer it after finding the thread since it seems like it's been the cause of endless consternation for everyone involved.

It seems clear to me that this thread can ultimately be summed up as the following:
1. Q: Does VLC have a previous frame hotkey? A: No.
2. Q: Will VLC ever have a previous frame feature? A: No one on the project is interested in adding such a feature because it would be quite difficult to implement for everything. If you want to try to code your own you might be able to add it since it's an open source project, but it's entirely up to you.
3. Q: Why doesn't VLC have a previous frame feature while some other programs do? A: Because it's difficult to generalize. VLC's design goal is to support as many video formats as it can, and it's going to focus on that for any features it chooses to add. Frame advance is easy to code for any video format, it's what all of them are built to do, but only a few video formats allow for the opposite. Making other formats support this would sometimes require encoding the entire video from the beginning again. As such, VLC has no interest in adding such a thing, nor any sort of hacky work around that uses seek + frame advance to do the same. If you want this feature, you should try some other program.

I think that if this information was presented in clear FAQ like form earlier in the thread, or perhaps if this was posted as its own thread, this would help avoid unnecessary conflict. We keep seeing it inevitably opened up again by people who don't really understand that VLC won't have this feature while other programs do because it's not one of VLC's priorities. But it's clearly an open and shut case where all of this discussion is pretty much pointless, right? If anyone's actually going to change something on this topic, they'll do so by making it themselves and submitting it through the source code rather than talking about it in here. It's clearly becoming very frustrating for the dev team to read this thread. You could even give examples of other software people could use if they want this feature, so they'd stop bothering you with the question.

So my suggestion is - why not just lock this thread and then formally state this information somewhere quickly visible, like by editing the second post or something? This would mean that people who find this thread through google search like I did will immediately know the situation and people won't feel the need to keep replying arguing over whether or not it's theoretically possible. So long as the thread isn't locked and people keep seeing it as they search the question on google, they're going to keep popping on in here and asking the same tired old questions that no one wants to repeat themselves answering. That's why I think it'd make things a lot simpler to lock the thread and put the full explanation somewhere prominent, since it's a years old topic anyway. Nearly a decade, actually...

As I said, it may not be my place to discuss forum management, but I just wanted to weigh in on a topic that seems to have been quite frustrating for people. There's a reason that forums used to treat necroing threads as an issue, after all!

[AutoBaker]

At the risk of an antagonist / defensive reply from Remi I wanted to add my 10 cents. Firstly, a massive thank you to the developers of VLC, I've been using this program for over 10 years so far and it's always had the widest codec support and is reliable and functional. Your work is amazing and hugely appreciated.

I don't have experience in Windows programming, and I don't think I have the expertise to build a patch or provide an alternative that works better. However, I have picked up a little bit about video files over time and I know that this feature is not "impossible" as previously stated. Maybe it's impossible to be done in the way that VLC has been built, but it's been done in many programs as pointed out, so it's a case of working out the best way to do it.

I also want to point out that this feature is really important to me. I use VLC as the default for playing videos, but when I need to scrub backwards, my current process is fairly lengthy:
- Open Adobe Premiere Pro
- Create a new temporary project which includes selecting a folder location
- Import the file
- Open the file in Source monitor, or if it's a RAW / 4K / 8K file, I'll need to create a sequence, drag the file in & fully render it
- I am now able to scrub forward and backward, in frames or steps

As you can see, almost any way that VLC could implement a "step backward" feature would save more time and computing power then this workflow, which takes several minutes to set up. It's been explained a lot about how difficult it is to implement without lots of difficulties, but can't that decision be given to the user? Add the feature, do the best you can, have it disabled by default, and provide a warning when it's enabled that it could use a lot of computing power to use this feature. Then it's down to the user?

Consider a few methods:

- I open a 4K video in VLC, and immediately scrub to a frame in the middle of the video. The frame renders almost immediately, less then half a second. If I scrub backwards, it again renders the frame almost immediately. To select that point in the video, I'm presuming VLC decodes the video from the beginning, all the way to the point I select. A step backward function could simply look at the timebase of the video file, look at the current PTS (Presentation Time Stamp) of the current frame, decode the video up to the current frame, all the while caching the previous frame. Once it reaches the same PTS as the current frame, it simply shows the cached, previously rendered frame. I know that's computationally expensive, but realistically that would take less then a second to calculate. There are situations where it will take longer but I'd prefer to do that, rather than creating a new Premiere Pro project every time I want to scrub a video backwards.

- Then again, with a little bit of logic, you could make this a bit smoother. On the very first video encode, you could build a database of all the I-frames (keyframes) in the video. Then, when a user steps back a frame, we search the database for the closest I-frame location from the database, and then decode from that point on in the same way as above, caching the previous frame. This avoids decoding the whole file again, but also ensures that a complete frame is rendered. This might not be a huge amount quicker, but it would save a lot of decoding.

- Alternatively, just cache or transcode the whole dam thing in a format that can be scubbed very easily. As someone that works with video files a lot, I'm more than happy for VLC to transcode the video into whatever format it thinks is best to give me the best experience possible.

I guess what I'm saying, is that any way that's possible to provide this feature will be better then not having the feature! I know some of these methods won't be friendly to users that aren't looking to get the most out of VLC, but that can all be worked around using some opt-in settings as mentioned.

[HixonECG]

If you go to Jump to Time Previous Frame v3, you can add on the ability to go forward and backward one frame at a time in one interface.
It has been beneficial for me, and does other stuff too, so it might be worth checking out.
As for the developers, if recreating or integrating this is too difficult, which to me is questionable since this works very well in my experience and is a small lua file, then can we at least be able to use add-ons to customize the keyboard shortcuts or interface icons? Being able to click forward and backward one frame at a time with keys would be fast than having to bring up an interface and mouse click between them.

And for just adding such a feature into VLC, I understand that maybe this won't work for all video formats. But for those that can support it why not let the program see that and support it, or give the user the option with a warning that it might not work properly? Or at least test it out with users and see how people take to it. Most users will never touch that feature, but there is a large community of video creators that absolutely would and do.