Is there a previous frame hotkey?

[qwerti3465]

Phew. From Web Search straight to very heated discussion (:

I am not capable of providing the code and I appreciate the devs' work on this open source project.
So please don't shoot, but let me still suggest a (in my mind) simple workaround as I would love to continue using VLC for this:
_____________________
Only when user enters the frame by frame mode (pressing -e-) the frames he e-ed through will be retainined in memory, up to a maximum of x.
And only those are the ones that are accessible via a "previous frame" feature.
x is a parameter settable somewhere in Preferences (and probably limited to something) so the user can decide how much memory to dedicate to this.
Done.
_____________________

Yes, that wouldn't enable to pause the video and immediately access previous frames (which I gathered seems hard to implement).
BUT it would probably still cover about 99 % of use cases for this:
"Is this frame the best? No, next one? No - next one? - ***** is was one of the 2 last ones after all." [Press SHIFT-Left --> Repeat]

For the other side of the medal (we want something slightly before the freshly paused video, the existing options (jumping back a tiny bit) are completely fine.

[Khanomen]

If it's so easy, why are you not doing it? Talk is cheap.

Not everyone is a coder, but you are going off about how this is supposedly

On a logical level, this feature is algorithmically impossible

yet for such a claim of impossibility in your own words, when given a verifiable example PROVING that it is clearly NOT impossible, you move the goal posts and now demand this person give a technical breakdown of how other open source video players work. Do you not see how absurd you're acting? Do you really have no self-awareness? You are so far up your own ass that its no wonder VLC is in such a place when compared to its other video player peers. You make a claim, then are given proof as to why that claim is not true, so you backpedal away and then point the finger back at them and exclaim they are the ones who are infact dodging the topic.

Im not going to make any comment about how easy something may or may not be, nor the concept of rolling buffers, as i am not experienced with VLC's code base, and the spaghetti mess it must be given your attitude, but i am going to say there are plenty of examples of video players having no issue at all stepping back a single frame, Potplayer, SMPlayer, Media Player Classic, ffs even YouTube can step backwards single frames. IT IS POSSIBLE, and clearly something that other players have been able to implement without every computer to ever run it exploding, but no one here seems to what to do it.

[Rémi Denis-Courmont]

Well, yeah, it is possible, just needs either unbounded time or unbounded memory as per complexity theory.

In some sunny day scenarii, it is possible with reasonable finite time and memory. That's how video editors work. This has been explained over and over, but obviously VLC cannot make the strong assumptions that video editors afford.

No amount of arguing that I am an idiot, even though multiple VLC developers made the same points here and elsewhere in the past, will change the situation. Nor will any amount of circumstantial evidence that it is conditionally practically feasible (YouTube can choose its video format, VLC cannot).

Frankly, I've had more than enough of all the abuse coming my way. I am utterly disgusted by the attitude of many freeloaders here (including a number of them that were banned). You should be ashamed of yourselves. But since you don't seem to understand, we'll just have to ban all further trolls.

[FrameBackWanter]

I, like others, arrived here through a Google search looking for this feature. Reading this thread is one of the worst decisions I've made recently. I will never have this time back and I am worse for it. Rémi, I ask that you consider objectively why people in this thread have reacted to you in the way that they have. Shifting the burden of proof to the layman who comes to you in good faith (initially, at least) fools no one. If you are incapable of/uninterested in implementing a feature that exists in other software, that is not anyone else's fault. Demanding that the solution be explained to you before you will accept that it is possible is childish, and the sole reason for why you are being treated this way. I do not know how to build an airplane and yet I accept that they exist and function -- you can do this with software developed by other people. It does not make you a worse person or developer to concede that this feature does exist elsewhere, does function elsewhere, and that it is reasonable for people to want that feature to exist in VLC, which is robust to such a degree that its exclusion feels incongruous with the rest of the software's capabilities. I expect to be banned and for this post to be deleted, and indeed will never return or check for a response, but I at least hope that you read all of this first.

[Rémi Denis-Courmont]

VLC devs have already discussed this multiple times in the past and concluded that it is not generally feasible with usable performance and realistic memory use. See also the infamous infinite GOP problem.

We are not putting any burden of proof on anybody. We already explained multiple times why it does not work. People refuse the explanation. The only other way that we know how to demonstrate the problem is to have people try to implement it. That's why we are left we suggesting exactly that. If you know better how to explain it, you're welcome.

[H0lly]

Ok.
How is it that this very feature is implemented and working just fine in various other media players, though?
readers of this thread are currently left to believe that this must be down to some sort of black magic.

forgive my ignorance if this has been explained elsewhere. in that case, a link to this other place would've been useful though.
this thread is the first thing that pops up when searching for this feature in google, after all.

I think qwerti3465 describes it very nicely here:

"Is this frame the best? No, next one? No - next one? - ***** is was one of the 2 last ones after all." [Press SHIFT-Left --> Repeat]

essentially, I think this is all that people would like to be able to do (i.e. not having to press shift-left and having to risk to go past the good frame once again1).
there has to be at least one workaround for providing that functionality.

[Rémi Denis-Courmont]

So lets say that you keep the last two frames in memory. What happens when the user presses the previous frame button three times in a row?

The only two general algorithms to achieve rendering video backward are:

• Store all frames from the beginning, i.e. unbound memory usage.
• Go back to the beginning of the video, and decode all frames in order until the current frame is found, i.e. unbound computation time.

In some particular cases, you can find a previous seek point that's not all the way to the beginning, but that depends on the media.

[olsonadr]

Hi! This is obviously a rough issue in terms of developer-user discussion. I understand that the main problem is that people don't read what's been said, but I am a dummy computer science student who thinks this is interesting.

Is there anything stopping a mode from existing where just the single previous frame is cached, such that someone can be in playback or stepping forward frame-by-frame, with the current frame replacing the previous in the cache each time a new one is loaded. With this, the user could effectively just "undo" the last frame advancement? This avoids the issue of computation time so long as the frame is not infinitely large, which sounds like a codec problem or some streaming paradigm I'm not aware of, because the user can never press the previous frame button more than once. It would be a one-time undo button, rather than a consecutive previous frame button.

The main workflow I'm missing this for is moving up until a specific milestone in the video, then reversing exactly one frame to see the last value that existed before that milestone. Having just one undo button would satisfy this need for me, although I don't know if it would for others. Feel free to not waste time responding if this has been asked before! Thanks for all your hard work on the program and for your patience dealing with this and similar threads!

[johnny1234]

Hello!

I registered to jump in the discussion because I would like to see this feature in VLC and not have to change player.

I am not a programmer, but I did a bit of programming a while ago and I managed a few basic projects... So here's my thoughts/suggestions:

What I find odd about the memory consumption argument (keeping all frames in memory from the beginning of the video) is that we can already seek the video anywhere we want with a mouse click or with right/left arrows without running into any memory issue. This is already what we do to bypass the lack of "back one frame" function... We click a bit before on the timeline and then we press "e" several times until we reach the previous frame, and hope we don't go too far again! So, if we can already go anywhere in the video without running into any potential issue that is raised by "back one frame" function, this could be used to avoid all those issues. For example, if we can go back 1 second and press "e" several times to reach the previous frames, this means we don't have to store all frames since the beginning of the video. Nowadays, there is only 60 frames per second maximum in most videos.

My suggestion might not work, because like I said, I am not a programmer... But as I understand it, all you guys need is a way to track the position of the currently displayed frame (a counter?? ... for example, we are currently frozen at video time 1m56s + 22 frames), and then "seek" the video 1 second backwards (or any chosen arbitrary interval) in the same way that would be done by clicking the timeline and then save the frames forward between the seeked position and the frame that is displayed on screen. Then you would have a bunch of frames in memory to be able to go back to. I mean, when we use the "Jump to specific time" function, VLC always jumps to the same frame at the beginning of a chosen second in the video. It does not choose an arbitrary frame at the time we entered... So at least this means VLC "knows" which frame begins every second of the video and is able to consistently jump to the same frame every time we enter a specific time... Then it would just be a matter of keeping track of how many frames passed that "beginning-of-a-second-frame" we are now at and just rewind to the first frame of the specific second and go forward to the previous frame. For example, we are currently displaying frame 1m56s + 22 frames, user clicks "back one frame" button, we rewind to the first frame of 1m56s position and forward 21 frames. This looks like the only thing we need is a counter to "remember" how many frames passed since the first frame of a specific second and reset that counter every time the video "passes" one full second. It does not even look like we need to store any frame at all into memory. Just rewind to the beginning of the second and forward a specific number of frames based on the marked position. But maybe this is impossible, I don't know, I am just thinking loudly.

Anyway, I just wanted to give my thoughts and if it can help anyone, why not... I don't want to be rude to any hard-working volunteer here. I've helped programmers do something that was supposedly "impossible" in the past because I just thought of something that was entirely different of what they thought before... Not because they were not good programmers, only because they had been into the project for so long that they couldn't see any other possibility.

Keep up the good work!

EDITS 1-2: Edited a part to make it more clear... Sorry, English is not my first language!

[Rémi Denis-Courmont]

In general, VLC seeking is not accurate, so you can't simply seek to the previous frame. Besides, you don't generally know the exact timestamp of all the previous frames.

In fact, some formats cannot provide accurate seeking (short of parsing everything from the beginning) - notably MPEG-TS.

[Safe-Keeper]

It proves other players can do it. As I already said, the answer might be in the source code of MPV and other open source players.
Even Windows Media Player can do frame by frame backward.

I've chosen this Big Buck Bunny video because it's a rights free and well encoded 4k video which can be freely distributed. You can use any other video you want.

Notice that in 2021 VLC still has problems with frame by frame forward:
https://forum.videolan.org/viewtopic.php?f=14&t=154822

Something which has been reported many times and many years ago:
https://forum.videolan.org/viewtopic.php?f=14&t=61937

So I guess frame by frame backward might come in ten years time at best. It sounds like VLC was frozen like ten years ago and no useful user feature other players have will be added soon.
At the end, year after year, VLC is getting more and more late to the party, hélas.

So yes, do that, keep on waiting while we are using other players for this feature and some other ones as well.

Yes, it's weird. VLC player is my player of choice and I love how it, but issues like not being able to skip one frame forward for more than a few frames, and not being able to go back one frame at a time at all, are really weird.

[Rémi Denis-Courmont]

You're comparing apple and oranges here. VLC can go forward any number of frames. That's what it does in normal playback after all. There's just some bug in the stepping code waiting for someone to volunteer to fix it.

Playing backward is a whole different matter. I don't know any player that can actually play backward. And that's really the point. Stepping as such is not the issue. If you can play, you can step. Playing backward is the issue.

[johnny1234]

In general, VLC seeking is not accurate, so you can't simply seek to the previous frame. Besides, you don't generally know the exact timestamp of all the previous frames.

In fact, some formats cannot provide accurate seeking (short of parsing everything from the beginning) - notably MPEG-TS.

Alright, I think I understand better now.

Thank you for answering, I appreciate Merci!

[thrillho]

Remi can you explain why this plugin - https://addons.videolan.org/p/1154013/ - cannot be natively built into VLC? (even if there's a warning to say it will use more CPU usage because yes it does use more, but nothing that a modern PC can't handle).
Secondly, could you also give it a try since you've asked several times on this thread for other people to offer a solution, so here I am offering one - what do you think of it?

[Rémi Denis-Courmont]

You can already do precise seek in the VLC GUI though, just like that plugin, it won't always work correctly.

It does not look to me that this plugin is really providing what people mean and want when they ask for "previous frame".

[PrevFramesPlz]

I'd just like to throw in my two cents regarding this topic. The free and open source (GPLv2) VirtualDub video capture/editing program has been able to go back one frame at a time for years. I've even held down the back arrow key in the timeline [to go back one frame at a time via key repeating, roughly 15fps], and the software had no problem reading a ~250GB uncompressed 2560x1440/60fps video recorded with FRAPS (I can't speak for compressed videos as I haven't tried that yet).

Maybe some of that code can be used in VLC, or at least inspected and implemented similarly?

Just something to think about.

[Rémi Denis-Courmont]

Previous frame over uncompressed video is easy, at least if the file format is properly indexed. The problems with showing the previous frame have nothing to do with file size.

[callidus]

Time for me to chime in…and it's not a rant.

It's been sufficiently established that the circumstances don't allow for a previous frame function. I think one thing has been overlooked by those fervently demanding the implementation: As far as I remember and believe, VLC has always taken the position of being able to playback as many video formats as possible. This in itself is not an easy feat and must have certainly contributed to VLC's popularity. Those who remember a time from before VLC will remember having to download different codec packs, plug-ins for obscure players and different players (anyone remember Flip Player or Flip for Mac on a Mac?). VLC has solved many of these annoyances – cross-platform. Yes, video has come a long way. Being able to playback different video formats and doing that in a way that is the same experience is probably another reason for VLC's success. Plus, it's free, regularly maintained, FOSS, small in footprint etc.

While it would probably be possible to implement a previous frame functionality for some, well-defined formats, that same experience might not be possible for other formats. If I'm not mistaken, some streaming formats would have difficulties with that, or some of the older formats. I'm no developer for video, but have read up on the GOP (no, not the US Republicans) that Rémi mentioned. Having a distant development background myself, one of the many things that concern you is the "what if not" question: What do you do if a certain situation does not take place? How do you handle that? So here, that might mean (and I'm just guessing): What if frames are missing? What if the time is inaccurate? The experience you would have as a user would not be the same. Other video players might be able to handle a previous frame, but can they handle all the video formats as graciously as VLC, even incomplete ones?

My theme here is "same experience". You don't want a WMV to behave differently to an AVI, TS, MPEG or whatnot (again, I've never delved into the depth of video, but think that there is some issue here). That argument of YouTube of a previous poster is obvious moot: YouTube has one format it needs to deal with.

I for my part have installed the above-mentioned aptly named extension "Jump to time Previous frame v3" because like most of you here, I was looking for a previous frame feature and have been following this topic and waiting for this for quite some time, but I think I get it why it's not there. The extension works in most cases (use the "1/FPS" setting); it unfortunately doesn't have a shortcut key on Macs, so I maltreat my mouse then. Certainly, it'd be better if this is built-in, but there is a solution that would work for most scenarios. The number in the second input box should be 1/frame rate. Frame rate is in the Media Information window. So for 25 fps, that would be 0.04. Works in most cases.

If you want to go by rewind x seconds and then hit the 'E' key, maybe go to Preferences > Show All > Interface > Hotkey settings and set "Very short jump length" to maybe 1 (second). Which modifier keys you need to press probably depends on your OS, but you'll find that in the Basic Preferences under Hotkeys.

[potatolover]

This thread did actually help me solve this problem. Just use MPV and a video file format which isn't arcane. Thanks for the help! Hope everyone else sees the lesson here, too.

[Youngp33]

i think there is a simple fix to this issue... 99% of people that want to go 1 frame back are those that are going 1 frame forward and just wants that last frame of action, before going forward 1 more to realizing they went forward 1 frame too far, then with their mouse going backwards into the video ONLY to repeat the same thing... wanting that last frame of action just to miss it by 1 frame...

solution: why try generate a new frame going backwards when you can just display what was already displayed.... for example if i have 5 frames. 1.2.3.4.5 IF i am on 5th frame, why cant you just display the same EXACT 4th frame instead of trying to generate a new one? use cache or something.... 5 frame cache or i dont know..

i really have no clue how code works but this is common sense.. if i go frame by frame forward and only want to go few frames back? why not just display the previous frames i was already shown instead of trying to play the video backwards and reanalyze what is happening to catch a frame of good quality.... makes no sense...

Maybe a plugin or something that TEMPORARY saves each frame you go frame by frame forward so that you can just go back on those frames instead of trying to generate new ones... and then once VLC is closed or even another video is put on, the frames you saved by going frame by frame forward is deleted since it will no longer be used?

i mean this is something that is possible right?

[LydianLights]

Why not have a set of codecs for which this feature is supported, and only implement this feature for those codecs? Isn't it possible to implement this feature for those codecs which support accurate time-reporting capabilities so you'd know how many frames have passed since the previous I-frame?

I mean this is the obvious solution. But for some reason the response is "Absolutely impossible you massive idiot, why don't you code it yourself?"
I can understand "we don't have time to do it", but wow what an actually hostile response.

[Rémi Denis-Courmont]

If it's so obvious, why don't you do it? One thing that is obvious for sure is that existing VLC developers have gotten so disgusted by the demands and lectures here that they will never even try to implement this feature on their free time.

The most hostile posts against VLC devs were deleted as CoC violations. Your complaints is hurtful, unwelcome and counter-productive.

[brycenesbitt]

This thread helped me to find a solution. The single frame forward back feature is important to me when reviewing footage from a body camera.

While I still like and use VLC, based on the above I installed SMPlayer, which has this feature and supports the basic MP4 codec format of the camera. The hot keys are "," and "." the same as YouTube. Like VLC, SMPlayer is an open source project with built in codecs, and it's available on the Windows store. Holding the hot key has the nice effect of a slow motion play.

Uploading a video to YouTube also works for this same purpose: YouTube will transcode it into a format that's single frame forward and back compatible .

[faither]

In general, VLC seeking is not accurate, so you can't simply seek to the previous frame. Besides, you don't generally know the exact timestamp of all the previous frames.

In fact, some formats cannot provide accurate seeking (short of parsing everything from the beginning) - notably MPEG-TS.

Hey all! Just to clarify:

Perhaps you had the same idea and I thought of the similar to @johnny1234 suggested - once a user pressed "frame backwards", seek to ~1 second before the current time, pre-render the amount of frames the video's framerate is (e.g. 24) at both ends (12 frames<>cursor<>12 frames, or 2x in total, for example, 24 frames<>cursor<>24 frames), store them in cache, and allow a user to shift through them. Perhaps there may be issues at the render ends or middle (e.g. 62 frame is 60), so what if it would pre-render additional frames (e.g. 4+24+4 - 12+4 frames<>cursor<>12+4 frames, 6+30+6, 10+60+10) where the first term is additional frames at the start, the second - at the end. Perhaps the correct additional amount can be calculated via specific statistical codec formula (or set in user config). If the user selected frame outside of the pre-rendered range, repeat the process with changed range (e.g. +/- ~1 second).

In addition, assuming the inaccuracy of the issue, in order to try to select the actual current frame once a user pressed "frame backwards", what if it would pre-render X amount frames and select the current frame based on image comparison from the pre-render middle (with the one which was on the viewport at the moment the user initialized the procedure)? It might fail sometimes, but also try to select the most similar frame as an initial while running through pre-rendered frames, though it may result in unexpected occasions in case two similar frames exist (toggleable in user config).

Once a user resumed the play, clear the cache. If the codec doesn't support seeking, disable the feature.

In the end, it might be inaccurate in case of the currently selected frame only, wouldn't it? Even an inaccurate feature might significantly help - seek 1-10 frames instead of 1-200.
All in all, it would be some kind of "frame mode" with a temporary pre-rendered frames stored in a cache either accurate or not.

Considering the above, what would possibly go wrong?

[Rémi Denis-Courmont]

With all due respect, it's already been explained up-thread. Your proposal pretty much assumes full-intra-only video; it will work with pretty much nothing but professional pre-production videos.