Frame-by-frame forward/reverse

[padorange]

Sigh. Is it hard to understand that backward compressed video playback is generally impossible, albeit possible with varying degree of computational, memory and coding complexity in some particular cases?

Yes it was hard to understand.
I was a developer (not really anymore) and i can understand it was difficult, but "(generally) impossible" seems a bit overestimated...
I confirm space5 previous comment : some software (simple player) do this from the beginning. Take Quicktime player, it do this (frame by frame backward/foreward with arrow and also play back and foreward) from 1990 (when multimedia was invented), with lot of codecs without any problem (sometime it can be a bit slow but never failed).
Yes it was probably difficult (compression algo are made for foreward), but invoking bad reason (memoty, app size) was not really compatible with experience (QT Player again, 1990).
I originated from MacOS world (now Linux) but Quicktime player was one of the software i regret because i have not found any successor and that for 2 functions : backward/foreward frame by frame with arrow key (direct arrow key no shortcut) and also the possibility to display a playtime with minutes/seconds and frame. This allow me to analyze video and count precise timing (frame precision).

From experience, it is known that a feature that does not always work will trigger user complaints. It took only a day or so to implement forward step-by-step on top of existing forward playback. It would take many months to implement step-by-step backward playback. No volunteer VLC developer is willing and mentally and financially able to spend that much of their free time, only to end up on the receiving end of bug reports from an angry entitled users.

You're right a function must work for end user or it was a bad experience and i can understand there was no volunteer. Free software works like this, it was the rules.

Bluntly, the copious amount of negative criticisms and threats of switching to competing applications, plus the many censored trolling messages, only makes the matter (way) worse. What is instead needed here is either a motivated developer or (very large) funding.

Yes but the opposite is also probably true, it can also revealed it was a feature lot of users need

[Rémi Denis-Courmont]

So you want VLC to do reverse frame-by-frame on the file formats and codecs that QT supported in the early nineties? Somehow, I doubt that that's what most users want.

I don't need to mention that algorithm complexity, be it code, algorithmic or memory complexity has increased several orders of magnitude since then.

[Dorraj]

I'm not sure about anyone else but I was never "threatening" to switching to competition, I believe most others weren't doing that either. The point is there is a useful feature that many other competitors have, that VLC does not. This is not "negative criticism", this is users pointing out a feature they want, and places to look at that have already figured this out. Calling people "entitled" for pointing this stuff out is a great way to turn people away.

Also, a feature does not need to be 10000% working in order to be implemented. If it doesn't work up to the perfect standards that you apparently need, then put "EXPERIMENTAL" or "UNSTABLE" next to it in the advanced options to turn it on or something. I'd rather have a mostly-working feature, than a non-existent feature. But hey, I'm just a user asking for a feature, not a dev who knows how to create stuff like this, so I guess my opinion on the matter is irrelevant.

[shape5]

I’m sorry to hear about the negative troll posts which is way over the top, beyond even being completely uncalled for. I mean it’s freeware – show some appreciation and respect.

I posted this above on May 28th and wanted to check back on it since it wasn’t answered directly: As a next best alternative, would it not be feasible to make new hotkeys that move the playback bar position back at the smallest possible increment (rather than frame-by-frame, w/out it taking months)?

[kdo]

I'm confused, so perhaps someone could explain. It seems to me that VLC can go to an arbitrary frame. I can click on the time bar or I can push shift-left and it seems like it can go anywhere. So I think all we want is a feature to go to the arbitrary time that is one frame before the current one. Why isn't this just a user interface feature and not some complicated thing about video decoding? Is the problem that this works only in some formats? If so, what does clicking on the time bar do in those formats? If clicking on the time bar only sometimes works, why would it be any worse for frame reverse to only sometimes work?

[Rémi Denis-Courmont]

VLC can't go to an arbitrary frame. It can seek with some precision, but it's definitely not "frame-accurate".

And even if it were frame-accurate, how would you know when is the previous frame? Not all videos have perfect frame rate.

[Rick01]

I am familiar with how compression works with some video file formats and understand very well the problem of moving one frame back (the need to recalculate from the previous I-frame up to the frame to be viewed).

I do not know exactly how all file formats work. That said, I'm wondering if it is possible to step forward frame by frame (as is currently available), but to reverse to the previous I-frame?

If so, the need for the significant recalculation of a potentially large number of P-frames wouldn't really (instantly) be needed, but a user could then step forward from that I-frame.

[Rémi Denis-Courmont]

How do you know where the previous I-frame is? You could save the last position, of course... but then what if the user wants to go more than one I-frame back?

[ryano12]

How do you know where the previous I-frame is? You could save the last position, of course... but then what if the user wants to go more than one I-frame back?

The player knows the frame rate of the video that it's playing.
VLC can jump back in time by 1 second very rapidly.
Can it not just be setup to jump back by n x seconds, where n = 1/FPS?
Or if 1 second is the minimum jump back time, and the ability to jump forward frame by frame exists, can VLC not just jump back by 1 second and then skip forward by n x frames, where n = FPS-1.

Both scenarios would obviously not be ideal or pretty from a developers stand point, but it would get the job done. Even if it took 1 or 2 seconds to jump back on frame, people won't mind.

[Rémi Denis-Courmont]

Explain to me how to map seconds to file offset that the operating system can seek to...

Repeating myself here, but the only general way to find the previous frame accurately is to decode everything from the beginning, always keeping track of the previous frame, until reaching the current point. Then show the last previous frame.

Some files have an index of seekpoints/GOPs, so that decoding is only necessary from the start of the GOP. But that is not generally available (or correctly recorded).

[MickM]

Cautiously thinking out loud here (and not wanting to incur anybody's wrath). I was wondering what typical amount of real-time exists between these key frames? Let's say it was 1 second. Given that VLC excels at playing movies in real time, and assuming at any given instant VLC knows (or can easily determine) the location of the previous key frame, then couldn't you just jump back to the previous key frame and play the movie up to the desired previous frame? It might look ugly getting there (and maybe you could blank the screen till you got there), and it'll take up to 1 second - but it's better than nothing. If this can be done at faster than real time speeds then all the better. No fancy frame buffering involved etc. - just conventional movie playing.

[Rémi Denis-Courmont]

It varies. But the first problem is finding GOP start accurately. Normal seeking needs not be (and is not) that accurate.

Of course the real first problem is for somebody to have the skills, motivation and enormous amount of time needed to implement this, even though it will be generally very slow.

[MickM]

Thanks. Obviously if locating the key frames is convoluted then there's goes that theory .

[orangefuzzz]

If one frame reverse is hard or impossible, just program the command to do a 1 second reverse and then skip forward 1 second minus one frame. I think there are alternative ways to reach the same end result.

[Rémi Denis-Courmont]

That won't work for multiple reasons as explained several times up-thread already.

[GGeorge]

Hi, no expert of codecs he3re, but how it is so easy possible to do a "several seconds jump", and not a "frame-back-step"
Would it maybe work for a fixed frame-rate ?
Generic & clean programming [maybe devide into file formats bzw. codecs with fixed / varying(?) frame-rates ?]
Hope its getting implemented somehow

[shape5]

As I inquired back in Oct 2021, would this really not be possible? Any small increment is better than none at all.

I posted this above on May 28th and wanted to check back on it since it wasn’t answered directly: As a next best alternative, would it not be feasible to make new hotkeys that move the playback bar position back at the smallest possible increment (rather than frame-by-frame, w/out it taking months)?

[Rémi Denis-Courmont]

This was already answered several times up-thread. If you prefer to experience it for yourself, you can patch the backward seek to be however short you want, and see the (bad) result.