Mpv – A free, open-source, and cross-platform media player

He mentions in the thread that he had to delete posts offensive to the developers. Maybe that's why?

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?

> 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 because these users just can't code?

> Maybe because these users just can't code?

It would be still interesting that the intersection between the set of users who claim on this forum it's possible and the set of users who can code is empty.

The users noticed that other players can do that, so it wasn't hard to deduce this is possible. You don't need to know how to code to notice that someone, somewhere had done something

I haven't looked into any claims or followed these links, so I don't know what the limitation is.

But abstractly, it's absolutely possible to write a program that decodes frame at a time and displays them slowly.

Now, whether there is some architectural difficulty based on design decisions within their player, or any player, I don't know.

Edit: I guess downvoters have never worked with a video decoder api before? I just read the link and it seems like the rationale is to not seek one frame backwards because you'd have to seek to a key frame and waste some work? That's not the same as it not being possible.

> He mentions in the thread that he had to delete posts offensive to the developers. Maybe that's why?

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"?

He also accuses other users whose (benign) posts weren't deleted of CoC violations so I'm not going to assume his judgement for deletion was reasonable unless I see the deleted posts.