←back to thread

1113 points Bluestein | 1 comments | | HN request time: 0.229s | source
Show context
lairv ◴[] No.41278203[source]
I use it to inspect video frames by frames, particularly being able to go back one frame. VLC doesn't support it, this thread about the feature is hilarious https://forum.videolan.org/viewtopic.php?t=120627
replies(19): >>41278382 #>>41278499 #>>41278639 #>>41278719 #>>41279342 #>>41279364 #>>41279561 #>>41279827 #>>41279842 #>>41279920 #>>41280125 #>>41281214 #>>41281733 #>>41282953 #>>41283275 #>>41284169 #>>41287180 #>>41289348 #>>41289743 #
sergiotapia ◴[] No.41278382[source]
i wonder why he's such an ass about it, and totally adamant that it's impossible when multiple players already do this fast. ego?
replies(4): >>41278485 #>>41278542 #>>41278658 #>>41278802 #
mannyv ◴[] No.41278542[source]
To do this well you need to keep the old frames around...or go back to the previous keyframe and re-render. That might be hard if your design is playback-optimized.
replies(3): >>41278621 #>>41279096 #>>41281533 #
Dylan16807 ◴[] No.41278621[source]
Re-rendering shouldn't be hard, it's just a specialized version of seeking. VLC has seeking.

The claim that you would have to decode all previous frames in the entire video is... completely baffling to see coming from the dev. He's arguing a stupid technicality that a video might not have keyframes. That's not a reason to omit the feature entirely.

replies(3): >>41278876 #>>41279208 #>>41279260 #
throwaway22032 ◴[] No.41279260[source]
The strange thing is that the same argument is true for seeking in general.

Going back from frame 500000 to frame 499999 is in the limiting case as complex as seeking from 1 to 499999, and in most cases far better.

I think the forum thread would be better answered "you do it, I don't need this feature" which is basically the gist of it and is a completely fair answer.

replies(1): >>41279434 #
a1o ◴[] No.41279434[source]
It's not even about doing it, once added you have to maintain it, and then tomorrow a new format arises that makes this more a hassle, or some memory issue in an existing format is fixed in a way that changes it's memory profile and now VLC will crash with an out of memory.

Seriously, I don't get these people that have infinite demands from open source developers and contribute zero.

replies(2): >>41279445 #>>41280375 #
armada651 ◴[] No.41279445[source]
You already have to maintain seeking code, stepping back one frame is just a specialized case for your seeking code.
replies(1): >>41280779 #
mrob ◴[] No.41280779[source]
You already have to maintain code for seeking by time. There's not necessarily any easy way to convert between time and frame count.
replies(1): >>41281111 #
_flux ◴[] No.41281111[source]
VLC knows the timestamp of the current frame. From that information it can seek to a frame that is before the current frame, possibly by just subtracting the inverse of frame rate from the current frame's timestamp and if seeking to that time results in seeking to the same frame, try again a bit older.

I'm relatively sure this can be implemented in terms of timestamp-based seeking. Quite possibly the metadata of the frames is already in the memory, further simplifying the process.

replies(1): >>41281803 #
lupusreal ◴[] No.41281803[source]
> just subtracting the inverse of frame rate from the current frame's timestamp

Variable frame rate (VFR) videos break this approach. It might seem like an esoteric edge case, TV and movies aren't VFR after all, but VFR is extremely common in videos from smartphones.

replies(2): >>41288866 #>>41290396 #
1. _flux ◴[] No.41288866[source]
This is why I also suggested a fallback in case it lands up in the same frame, but yes, it also needs checking that the next frame is indeed the original frame.

I expect it to work unless the frame rate is wildly varying, e.g. 60 fps and 60 spf in the same video. I guess one reasonable use case would be video that's triggered by motion, though. It would still work for almost every video.