←back to thread

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

(mpv.io)
1113 points Bluestein | 3 comments | 17 Aug 24 18:56 UTC | HN request time: 0s | source
Show context
lairv ◴[17 Aug 24 21:38 UTC] 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 ◴[17 Aug 24 22:06 UTC] 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 ◴[17 Aug 24 22:30 UTC] 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 ◴[17 Aug 24 22:42 UTC] 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 ◴[18 Aug 24 00:45 UTC] No.41279260{4}[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 ◴[18 Aug 24 01:27 UTC] No.41279434{5}[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 #
KingMob ◴[18 Aug 24 05:48 UTC] No.41280375{6}[source]▶
It's because the developer is misconstruing a non-technical decision they made as a technical limitation.

The commenters are trying to point this out, which misses the reality that the developer probably isn't going to budge from their requirement of universal support.

That dev's rationalization also sends a signal to any commenter with the technical chops to submit a PR, that it will probably be rejected for not supporting 100% of the codecs. I have no doubt people who could do it, over the years looked at that thread and concluded it would be a waste of their time.

replies(1): >>41281735 #
1. a1o ◴[18 Aug 24 11:43 UTC] No.41281735{7}[source]▶
If someone really wanted to do it they will be contributing already continually and at some point start working on this with the expectation that they are the one maintaining it. And it would be fine because by then developers would already trust that person since they've been reliable.

It's not about "technical chops", it's about being constantly available, reliable person that shows to contribute day after day. If you don't do that why should a dev make the scope of their work bigger if they won't be able to keep putting the same quality of work?

replies(1): >>41288304 #
2. KingMob ◴[19 Aug 24 06:19 UTC] No.41288304[source]▶
> why should a dev make the scope of their work bigger if they won't be able to keep putting the same quality of work?

They shouldn't...but that's not at all what the primary developer said.

The issue is the primary dev seems to require reverse seek functionality to work with all codecs, and since some obscure codecs can't efficiently support it, they're not interested. Their challenge to others to submit a PR is counteracted by all the signs that they might provide a high-to-impossible barrier to approval.

It's not clear that even a trusted contributor would be able to sway this person's mind. Most likely, contributors either agree, or keep quiet on the issue if they disagree.

replies(1): >>41290352 #
3. account42 ◴[19 Aug 24 12:13 UTC] No.41290352[source]▶
It's telling that there is no other VLC developer commenting in that thread - neither to support the decision and calm things down nor to go agains Remi's decree.