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):
In fairness to him, he offers the posters an opportunity to propose a technical solution and responds to all the posts that do it. It is interesting that nobody in the thread went to check in the code of mpv, smplayer, etc. to see how it's done there. Surely this would be the best response to his request for technical suggestions?
Maybe. As those posts have (allegedly) been deleted, it is now impossible to say. It seems probable though. I do find it interesting that he didn't delete the post, spewing actual verbal abuse at the people who dared to propose possible solutions in good faith.
> It is interesting that nobody in the thread went to check in the code of mpv, smplayer, etc. to see how it's done there. Surely this would be the best response to his request for technical suggestions
He has flatly ignored and refused to address, that these other players can do this at all. He makes only mention of "video editors". Well, and YouTube -- cherry picking the easiest case to attack (on grounds of single file format).
At the end of the day, what he needs is an algorithm, which can then be applied against the VLC codebase. For example:
* track timestamp of latest keyframe
* track nframes since latest keyframe
* optionally, keep some sort of unique id to positively identify this keyframe
- now, scrub back to last keyframe (if time accounting is sloppy for this format, overscrub by some amount, the run forward to the keyframe. If overscrubbing is significant, this is where you could compare the keyframe against the reference, to ensure you aren't way far back and needing to run forward further)
- okay, you've found your keyframe; advance (nframes - 1)
- profit
If he comes back and says "that's not fully general", that's true --- but the people asking for this don't care if it's fully general; it's suitable for common use cases and that's what they want. Let it work where it will work. Give up where it won't.
If he comes back and says "sure, that could work, but I don't have time, send a patch", well, okay, that's understandable.
What's actually happening is he's coming back and saying that won't work at all, that it won't support the majority of cases, will take too much compute, etc. and that's just flat out not true. You can do it selectively for the common cases. He might not want to, but that's different from can't.
Like, consider a scenario where you're playing back realtime video over a network connection. You won't necessarily be able to seek forward in that scenario -- you might not have enough video buffered, or hell, the connection could be plain interrupted. Imagine if they just didn't implement forward seek because the solution could not be fully generalized...
And who is going to spend time coding such a thing up, knowing that it is likely to be rejected as "not fully general"?