Is there a previous frame hotkey?

[Cynthia Moore]

I see that there is a hotkey ("e") for the next frame, but I do not see one for the previous frame. Is there one? Is there a "previous frame" function? Thanks

[Rémi Denis-Courmont]

No.

[Cynthia Moore]

You are nothing if not succinct.

[RadicalxEdward]

I was hoping to figure out how to do this as well since the shortest time i seem to be able to jump back is 10 seconds. I'm not a dev so i don't understand why next frame is so easy and previous isn't. but i've seen other forum posts (by remi i believe) answering this multiple times (which is probably why he only said no this time) but apparently it's much harder to do previous than next coding wise and performance wise. I don't understand it, but that's the answer for me, you and anyone else who finds this post unfortunately.

[RadicalxEdward]

Just found this and it explains why it doesn't work pretty clearly. For anyone who doesn't understand, most videos are compressed which means not every frame is actually a full image. only the parts that are different from the last fully loaded frame (to oversimplify it. i'm sure many can explain it in MUCH more detail than I) so going backwards also means searching for the last full frame and everything inbetween.

Pierre d'Herbemont kirjoitti 28.08.2009 kello 18:15:
>
> On Aug 28, 2009, at 5:09 PM, Rémi Denis-Courmont wrote:
>
> > Le vendredi 28 août 2009 18:06:15 Pierre d'Herbemont, vous avez
> > écrit :
> >> On Oct 22, 2008, at 10:22 PM, git version control wrote:
> >>> vlc | branch: master | Laurent Aimar <fenrir at videolan.org> | Mon Oct
> >>> 13 23:15:00 2008 +0200| [321e04ca2733320670bada94ae1b12e0e9ceb046] |
> >>> committer: Laurent Aimar
> >>>
> >>> Added hotkey code for input "frame-next".
> >>
> >> What kind of limitation prevents us from having "frame-previous"?
> >
> > Of course, there is no limitation at the hotkey layer but...
> >
> > Many modern codecs don't support backward playback. The input code
> > does not
> > support it.
>
> I was wondering if there could be some kind of emulation at the input
> code level. ie - seek back to the right(!?) frame, and then frame next
> to find the frame we want. Easy to say... No idea if this is realistic/
> easy.
>

It can be added in theory, but there would be certain problems. Like said earlier codec frame access is very problematic (I, P and B frames), because in worst case scenario you have to decode about 248 sequential Full HD H.264 frames before you can get previous image (so there will be major LAG). And you really cannot cache so many previous frames because they will eat all the memory very quickly.

So it will be either super slow in some cases or memory hog all the time.

Also not all access methods support random access all the time (so you really cannot seek), so it will cause frustatration in users when keys or GUI buttons don't work (this just a minor annoyance).

[Jean-Baptiste Kempf]

You can set the short jump to something smaller.

[avinashlobo]

Hello,

I've been looking for the same feature in VLC for a while now. I understand that it is a pretty complicated issue and hope it can be eventually resolved.

For those who need stepping backwards, Quicktime 7 can do this for the files that it can handle.

[dandv]

I understand the slight technical difficulty behind going one frame back, but it's mostly an excuse to not implement the feature (and be "cool" about it with one-word answers).

SMPlayer does support going one frame back - press `.`. This is super useful when searching for a particular frame to save as an image/screenshot.

Yes, it takes longer to find the previous keyframe and decode from there forward, but still much faster (~1 second typically) than having the user manually seek back then forward until the frame they accidentally skipped over.

Please consider implementing this. It's not hard. And it's been requested for almost 10 years now.

[Rémi Denis-Courmont]

There is not a slight technical difficulty. On a logical level, this feature is algorithmically impossible, except for the extreme: You can decode all frames up to the previous one. But this would be far too slow for anything except really short videos.

Video editors can seek frame by frame in both directions, but they only support the very narrow set of file formats and codec profiles that allow it.

If you think it is easy, VLC is open-source: you are welcome to provide the easy patch. Somehow, I won't be holding my breath.

[rodhos]

Is it possible to decode just 1 or 3 seconds and save those frames to cache only when the user press the backward frame button?

1. User presses backward frame button.
2. VLC decodes 3 seconds as when pressing shift+left arrow.
3. Those frames are saved to cache.
4. The user is able to seek those cached frames forward and backwards.
5. If the user reaches the limits another 3s needs to be cached.
6 If user hits the play button the cache is deleted and disabled.

[Rémi Denis-Courmont]

No, even that's not possible. The pictures that need to be retained in memory are defined by the codec, i.e. reference frames. On top of that, we have to over-provision picture buffers for multithreaded decoding as well.

There is simply hardly any memory left for extra picture buffers, especially with hardware-accelerated decoding.

[Lotesdelere]

But many players are able to do it for years. MPC-HC (Ctrl+Left) and MPV (,) just to name the ones I'm actually using, but I know there are other ones and MPlayer can do it as well as Dandv said.

SMPlayer does support going one frame back - press `.`

It might not be perfect but a least it works, even with hardware acceleration. It's a fact.
All of the players I've named are open source, so it's easy to check how they are doing it.

[Rémi Denis-Courmont]

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

[Lotesdelere]

I'm not saying it's easy but that many other players are proving it's possible.

[Rémi Denis-Courmont]

Explain how to render the previous frame with reasonable time and memory use with an infinite GOP, and I'll believe that it's realistically possible.

Of course, in theory, it's possible to decode the video from the beginning until the previous picture. It's just ridiculously heavy on processing and storage for videos of non-trivial length.

[Lotesdelere]

I don't explain how other players work, I just see they do work.
Example using another cross-platform open source player: MPV v0.33 release playing Big Buck Bunny H.264 3840x2160p, you can seek anywhere in the file and hit the comma key, it instantly displays the previous frame without any glitch nor image corruption and you can hit the "," again and again it still works.

Average memory usage is about 500 MB which is not what I call a heavy memory load for a 2160p video, it works on a low end PC with only 2GB of RAM and even in a virtual machine.
It's a fact, check it yourself.

[Rémi Denis-Courmont]

This fails to answer my question and proves nothing. You're just looking at one specific video, not the general problem. We all know that under some constraining assumptions it is feasible. Video editing software prove that over a decade ago well before MPV.

With that said, I will be waiting for a patchset on vlc-devel implementing this allegedly easy and feasible feature, and not reply to this thread until that.

[Lotesdelere]

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.

[trueboss926]

So this has been ongoing for 7 years. Seriously how hard is it to implement it? All Ive been hearing from the developers are excuses, excuses, excuses. I dont see how other players were able to have it. This is just pure laziness.

[Rémi Denis-Courmont]

I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers.

[dav36rye]

just got here from a Google search. I gotta say the replies from Remi sound defensively toxic. I'm not here to program the app, I'm just here to find a simple feature and/or request it. Like has been said earlier there are ALREADY other free, open-source programs that do this very thing. I really don't care if using the feature uses more memory or takes longer or whatever, and anyone asking for the feature doesn't care either. Heck, me being on Chrome with just 3 tabs open (my original google page + 2 results in videolan.org) is taking up a gigabyte of memory. If you're that worried about people on potatoes trying to use the feature, add a checkbox to enable it under advanced features with a warning it requires certain minimum specs.

Anyway whatever, I was just sort of shocked to see people getting dumpstered simply for asking about a feature. I'm off to download one of the other options that works for me.

[Rémi Denis-Courmont]

OK, we have noted that you don't care about consuming memory to keep all decoded video frames. Keeping frames for Full HD video only requires about 100 megabytes/second. And they're stored on the GPU RAM. What could possibly go wrong...

And I don't take moral lesson from an hypocrit who feels like they can demand work from "toxic" volunteers and even state that they are not there to do any actual work.

This matter has been considered more than a decade ago by several VLC developers, as well as other experts from VideoLAN. It is not generally possible. If you think it is possible, explain exactly how. Evasive references to mpv or other software does not count as an explanation.

[witek]

I might have a simple suggestion:

I notice that on any video, I can manually seek back ~1 second by using "Jump to Specific Time" and entering 1 second prior to the current playback position. Then, I can press the Next Frame hotkey to scroll forward to the correct frame.
Could we use this sort of operation, in code, as a work-around way to enable "Previous Frame" functionality? It might have problems with a few video codecs, but this method seems to work well for many videos I've tested it on manually.

On lower-spec machines the Previous Frame key might work slower, but it would be very useful for many people to have this as an optional feature / hotkey.

Any thoughts on this approach?

Edit: Then again - since Jump to Specific Time works for 1 second increments, maybe it could work for frames too. Again, I don't think this needs to work beautifully for every codec under the sun, if we see ugly artifacts appear on certain codecs, i'm willing to live with that to be able to use this function on most codecs.

[Rémi Denis-Courmont]

That only works if the GOPs are known to be no longer than one second. We don't. And lets not forget that not all file formats support accurate time reporting and seeking. This has been explained in previous threads already.

[justforthis]

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?

Can't VLC just record how many frames it has moved forward since the previous I-frame? That is just a single integer, whose size will determine the max. number of frames it can count between I-frames. You can set a parameter for the max. number VLC is willing to store of "how many frames since the last I-frame", and expose the modification of that number as a modifiable parameter in advanced settings. I mean, can't a 32-bit integers count up to 4294967295 frames? If that is not enough, then just use a 64-bit integer.

The fewer such codecs there are, the fewer the developer resources required to implement this feature *for only those codecs* (which is what everybody is asking for).

[~tbftebmh-sl]