16 ms·

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 htt

by lairv 2y ago

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 https://forum.videolan.org/viewtopic.php?t=120627

sergiotapia 2y ago
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?
- aaplok 2y ago
  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?
  - efilife 2y ago
    > 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?
    - aaplok 2y ago
      > 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.
      - efilife 2y ago
        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
      - asveikau 2y ago
        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.
  - mtrower 2y ago
    > 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"?
  - account42 2y ago
    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.
- mannyv 2y ago
  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.
  - Dylan16807 2y ago
    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.
    - weaksauce 2y ago
      yeah that's a weird edge case that's not really worth considering. it's obviously something that can be done technically even if some edge cases are not performant.
    - mannyv 2y ago
      You misunderstand. The point is you have to go backwards to find a keyframe, then render forwards from that. Going backwards might be hard because if you structured your code in certain ways you may not be able to go backwards efficiently. You can "seek", but how far back to you want to seek? A second? Two seconds? current-X frames? key frames may be in a standard cadence, but they may not be. So again, how far back do you seek to go back one frame? And keyframes may be abstracted away from the player itself, since really, the codecs are the ones that deal with that stuff. For example, I believe mjpeg doesn't do frame differencing (I'm probably wrong about that). The ideal implementation would save the last X frames then re-render once you go back like X/2 frames. But again, it depends.
      - Aeolun 2y ago
        Since I can drag the bar backwards in VLC and have it resume playback apparently this is already implemented? This would be a very narrow use of that.
- variadix 2y ago
  I think technically he’s correct (I haven’t worked on media decoding code, but I understand how common video encoding formats work). If you have a long video with only a single key frame at the beginning then to step back you would need to, starting from the beginning of the video, decode every frame up to the previous frame you wanted to jump to in order to apply frame deltas, also assuming you have some sort of frame counter to determine when you’ve reached the target frame. In the worst case this does require a lot of compute, but this is an edge case if you primarily care about common video formats with normal encoding settings. I assume seeking backwards is also painfully slow on videos encoded in this manner, so why stepping back 1 frame is out of the question when compared to seeking backwards, I don’t fully understand, it must have something to do with precise frame counts being unavailable on some hardware decoders for some formats (and there being no good workaround) so you _may_ not actually go back 1 frame. I don’t see any reason it couldn’t be supported for a set of formats with reasonable encoding/decoding settings, and provide some error message for other formats if a user attempts to step back, e.g. reverse frame stepping unavailable for current video due to format/encoding/decoding settings.
  - sergiotapia 2y ago
    that's still a whole lot of yapping that as an end user I don't care about. i can frame scrub forwards and backwards in multiple other apps. right? very weird response from the vlc team in that original thread.
    - makeitdouble 2y ago
      The back and forth in itself feels so weird to me, with so many hurt feelings: - the devs expressed in no uncertain terms that they don't want to do it (the first answer is just perfect) - every third comment is about "we know you don't want to do it, but as users why should we care ?" Well, if you don't care about the devs, on what base are you asking them to care about your specific problem ?
      - justin66 2y ago
        > Well, if you don't care about the devs, on what base are you asking them to care about your specific problem ? Caring about the user's requirements is part of the dev's job description. Caring about the dev's... anything is not in the user's job description. (one advantage commercial software has: it really does help when there's an interface between the dev and the user in the form of customer support. or a commercial incentive to actually work on what the user wants.)
- F3nd0 2y ago
  From what I can see, he's neither an ass nor adamant that it's impossible. He claims it's impossible to universally support the jump within certain technical constraints (which VLC supposedly limits itself to). The only time I saw him being unpleasant in the thread is when people ignored his explanations and acted very entitled. Correct me if I'm wrong on anything here, but VLC is an independent free software project developed in no small part by volunteers; they have every right to choose their technical direction and compromises, and it seemed the people insulting them were in no position to demand anything from them.
efilife 2y ago
VLC is pretty bad and it shows the more you use it. It doesn't let the audio clip/exceed safe volumes and always applies some sort of a limiter, even if it's disabled everywhere in the settings. Try using an EQ on a bass-heavy track and see that it's limited. Try jumping back multiple times in a song at its beginning, and it will play in lower pitch.
- darby_nine 2y ago
  > VLC is pretty bad and it shows the more you use it. Compared to what? Such a statement is meaningless without comparison.
  - opan 2y ago
    Compared to mpv. Some would also say compared to mpc-hc.
    - hollerith 2y ago
      The first sentence on https://mpc-hc.org/ https://mpc-hc.org/ is, "MPC-HC is not under development since 2017. Please switch to something else."
      - infofarmer 2y ago
        search engines and wikipedia point to actively maintained versions
      - defrost 2y ago
        Instead of MPC-HC v1.7.13 (2017) maybe try MPC-HC v2.3.4 (2024) https://github.com/clsid2/mpc-hc https://github.com/clsid2/mpc-hc In many ways it's a display wrapper about codec components, the display part is in active maintainance and bug fix mode (last update two weeks ago) and the codecs are constantly being improved (and expanded as new ones emerge). https://www.codecguide.com/ https://www.codecguide.com/ There are two or three MPC-HC spin offs that are tweaking the core to do new things.
Always42 2y ago
I have ran into this issue as well. I believe my solution was to use pot player but i am not sure if its open source
j1elo 2y ago
Wow those answers are indeed funny. I agree that as an OSS dev/maintainer, it's easy to fall on the vice of over-generalization and crusade for the perfect solution, and it feels that's exactly what happened there. > this feature is algorithmically impossible > You're just looking at one specific video, not the general problem. > is not generally possible. As a fellow multimedia dev, man, who cares? Sometimes we forget that software ought to be useful, not hypothetical ideals of truth. Just implement the feature for those codecs that support it and which probably are in the 98% percentile of what users actually use, regardless of the damned "general case". Or accept and announce shamelessly that you don't have either the knowledge or the development resources to tackle such a complex feature. But excuses about not being possible for absolutely every possible codec in a completely generic way is just denying that the world is just a chaotic and dirty place where things are not ideal nor perfect. Just give your users a real-world solution (or rejection).
- ziml77 2y ago
  I notice a lot of devs try to deny the chaos of the world. It's almost like the code is where they go to hide from things that can't be cleanly and unambiguously expressed. I don't know how they get away with that though. In the coding work that I do, I'm constantly dealing with rules that have exceptions on top of exceptions. I just need to special-case some things, because the alternative is not delivering what the business needs.
  - jbverschoor 2y ago
    And this is exactly the problem when these devs are in charge of creating systems that actually do matter. They will not support edge cases, problems in a process, etc.
    - vharish 2y ago
      I mean.. can you show anyone piece of software or hardware or for that matter any man made creation that solves for all edge cases?
darby_nine 2y ago
> Like said earlier codec frame access is very problematic Wow. Talk about not understanding the user.
justin66 2y ago
The developer responds to a comment: But many players are able to do it for years. with: If it's so easy, why are you not doing it? He's not just a butthole, he's a stereotypical open source developer butthole. On the other hand, if he worked for Microsoft, he'd be claiming that it takes a PhD to do it...
- Levitating 2y ago
  In his defense, some commenters had a pretty rude attitude. You cannot demand developers to implement a feature or call them out on being lazy. Nobody even offered to research how other players accomplish this. They just expect that because they believe it can be done someome should do the work for them. At least Remi was actually andering questions on the forums. This attitude towards open source maintainers is what's getting them all burned out.
  - KingMob 2y ago
    As a FOSS maintainer, I have sympathy for him, but as a communicator, I see he really failed to address multiple commenters pointing out that several other FOSS video projects had the feature. (At least in the first page of comments.)
  - IshKebab 2y ago
    I don't think the other people commenting were being at all rude. They asked nicely if a feature would be possible. He replied with a blank "No" and from then on it was pretty much "but other players can do it so it must be possible" and him rudely and incorrectly asserting that it isn't and that anyway if it was why don't they do it if they want it so much. The correct response would have been something like "it's more difficult to do and in some circumstances it will have very bad performance so we haven't done it yet". This is classic "It's hard and I can't be bothered so I'll make up some technical reason why it's impossible". Programmers do this all the time and it's kind of annoying. (And yes I understand video coding and I know why it's more difficult in some cases.)
    - hobofan 2y ago
anigbrowl 2y ago
I'll be happy to switch over to MPV for this alone. VLC is great in general, but lacking some basic features. This sort of 'not possible' nonsense from developers is always a sign of a project's long-term decline.
- mnsc 2y ago
  "not possible" is as much nonsense as "everything is possible". Is it possible for vlc to implement support for rendering and editing common 3d object models? Yes! But is it possible given what vlc was set out to do? No! I think another sign of a projects long term decline is developers that are all too happy to expand the scope of the project. If that happens I just know that down the line the feature I started using the software because of is down prioritized due to the "need of supporting markdown in the email editor" when the software started as a MSN chat archiver.
  - thiht 2y ago
    So you’re saying going forward 1 frame in a video is in the scope, but going back 1 frame is out of scope. Weird stance.
    - mnsc 2y ago
      If that feature would introduce a need to reactor or re-architect major parts of the the logic since everything has been built with the purpose of the playing video forwards supporting as many codecs as possible. Then, yes. And as a long time user of vlc video playback (and transcoding) I have never wanted to go back one frame. I always wanted to go back like 15 seconds, and that has worked forever.
      - thiht 2y ago
        > I have never wanted to go back one frame Good for you I guess? I have never wanted to go forward one frame so let’s remove that too
      - mardifoufs 2y ago
varenc 2y ago
Slightly related: mpv also has excellent backward playing capability! Of course video encodings aren’t optimized for this so it does some work to make the performance reasonable.
ThrowawayTestr 2y ago
You can press e to frame advance. Can't go back though.
romanows 2y ago
I was hoping that mpv would work a bit better than vlc for sending video to chromecast, but unfortunately, another similarly amusing thread: https://github.com/mpv-player/mpv/issues/177 https://github.com/mpv-player/mpv/issues/177
- latexr 2y ago
  Far from me to defend the whole mpv team[1], but the dev in that thread is a ghost (deleted user). I remember them, they were always rude and eventually got kicked out of the project and loudly complained about “being removed from the project [they] created”. I never found the exact reason why, though I can’t help but think the attitude had something to do with it. [1] Some are quite nice and competent. Others are exceedingly rude and will e.g. jump on an issue that had thus far been entirely cordial just to, without provocation, insult users for using whatever OS they don’t like.
  - throwaway11747 2y ago
    The last issue that caused them to leave was their desire to move mpv to their own build system, which they believed they could write in a weekend. Other mpv developers thought that was a stupid idea and argued in favor of something more standard, such as meson. That was the last straw for both sides.
    - deleted 2y ago
      [deleted]
    - latexr 2y ago
      > their own build system, which they believed they could write in a weekend. That doesn’t seem right: > (…) I started this over a year ago (…) https://github.com/mpv-player/mpv/pull/7801#issuecomment-641850335 https://github.com/mpv-player/mpv/pull/7801#issuecomment-641... > Other mpv developers thought that was a stupid idea and argued in favor of something more standard That doesn’t seem right either. I just read the whole PR thread and I see a bunch of users arguing for it, not other maintainers. The maintainer was certainly controversial and I found several commits and bad decisions which look to be almost universally hated, but it’s not clear to me this specific problem was what caused them to quit or that it was motivated by other maintainers. If you could provide a source for your claim, it would be appreciated.
a-dub 2y ago
i can imagine how it would be annoying in a system that is designed to process live streams as opposed to one that is designed to have random access to the stream via persistent storage. if the target frame were not an i frame, you'd have to dig up the preceding i frame and replay everything up to the target frame. pretty easy for random access, not so much for a monotonic stream of frames.
plq 2y ago
Quote from that thread: > It can be added in theory, but there would be certain problems. Like said earlier codec frame access is very problematic (I, P and B frames), because in worst case scenario you have to decode about 248 sequential Full HD H.264 frames before you can get previous image (so there will be major LAG). Having used the 'previous frame' feature in mpv, I suspect this is exactly how it's implemented.
breck 2y ago
This thread is amazing. Thanks for pointing it out. What's lovely is that it is indeed possible, but not trivial, and you can see Remi is sort of baiting to catch smart talented programmers to the project. You can see the patience and long term horizon needed to lead a volunteer open source project. Time to study VLC more. Thanks!
- thiht 2y ago
  Yeah he’s probably playing 5d chess, not just being an ass
- account42 2y ago
  I don't see Remi's behavior in that thread attracting more developers than it pushes away.
PUSH_AX 2y ago
That guy sounds like a nightmare to work with.
IndySun 2y ago
That is one funny, informative read! Although, the first response, I feel, aught to have been 'non'. I can hear it now.
hatsunearu 2y ago
What really sucks ass is mpv doesn't have features to show what the frame count of the frame you're looking at is.
throwaway2037 2y ago
Wow, reading this now very old discussion makes me cringe a little bit when I see dingers like these: > If you think it is easy, VLC is open-source: you are welcome to provide the easy patch. Somehow, I won't be holding my breath. > If it's so easy, why are you not doing it? Talk is cheap. > I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers. > And I don't take moral lesson from an hypocrit who feels like they can demand work from "toxic" volunteers and even state that they are not there to do any actual work. There are so many (passive-)aggressive comments in that discussion. This is the primary reason why I never get involved with open source projects any more. The discussions are so toxic. I always wind up feeling terrible about myself after "trying to help" an open source project by reporting bugs or submitting patches to fix bugs.
deleted 2y ago
[deleted]
account42 2y ago
That was an interesting read. - Great example of letting perfect be the enemy of good. - Hilarious example of a developer making claims of what users want while ignoring the users in front of him. - Shows how CoCs can be and often end up being used in toxic ways. Is Remi the sole active developer or why did no other dev chime in to defuse the discussion? I'm all for open source projects sticking to their vision and standing up to unreasonable user demands but it really is in your own best interest as a developer to learn to communicate effectively - and keep an open mind for feature requests that sound unreasonable to you and first make sure if you understand what is being asked for.

by lairv 2y ago

sergiotapia 2y ago

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?

aaplok 2y ago
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?
- efilife 2y ago
  > 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?
  - aaplok 2y ago
    > 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.
    - efilife 2y ago
      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
    - asveikau 2y ago
      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.
- mtrower 2y ago
  > 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"?
- account42 2y ago
  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.
mannyv 2y ago
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.
- Dylan16807 2y ago
  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.
  - weaksauce 2y ago
    yeah that's a weird edge case that's not really worth considering. it's obviously something that can be done technically even if some edge cases are not performant.
  - mannyv 2y ago
    You misunderstand. The point is you have to go backwards to find a keyframe, then render forwards from that. Going backwards might be hard because if you structured your code in certain ways you may not be able to go backwards efficiently. You can "seek", but how far back to you want to seek? A second? Two seconds? current-X frames? key frames may be in a standard cadence, but they may not be. So again, how far back do you seek to go back one frame? And keyframes may be abstracted away from the player itself, since really, the codecs are the ones that deal with that stuff. For example, I believe mjpeg doesn't do frame differencing (I'm probably wrong about that). The ideal implementation would save the last X frames then re-render once you go back like X/2 frames. But again, it depends.
    - Aeolun 2y ago
      Since I can drag the bar backwards in VLC and have it resume playback apparently this is already implemented? This would be a very narrow use of that.
variadix 2y ago
I think technically he’s correct (I haven’t worked on media decoding code, but I understand how common video encoding formats work). If you have a long video with only a single key frame at the beginning then to step back you would need to, starting from the beginning of the video, decode every frame up to the previous frame you wanted to jump to in order to apply frame deltas, also assuming you have some sort of frame counter to determine when you’ve reached the target frame. In the worst case this does require a lot of compute, but this is an edge case if you primarily care about common video formats with normal encoding settings. I assume seeking backwards is also painfully slow on videos encoded in this manner, so why stepping back 1 frame is out of the question when compared to seeking backwards, I don’t fully understand, it must have something to do with precise frame counts being unavailable on some hardware decoders for some formats (and there being no good workaround) so you _may_ not actually go back 1 frame. I don’t see any reason it couldn’t be supported for a set of formats with reasonable encoding/decoding settings, and provide some error message for other formats if a user attempts to step back, e.g. reverse frame stepping unavailable for current video due to format/encoding/decoding settings.
- sergiotapia 2y ago
  that's still a whole lot of yapping that as an end user I don't care about. i can frame scrub forwards and backwards in multiple other apps. right? very weird response from the vlc team in that original thread.
  - makeitdouble 2y ago
    The back and forth in itself feels so weird to me, with so many hurt feelings: - the devs expressed in no uncertain terms that they don't want to do it (the first answer is just perfect) - every third comment is about "we know you don't want to do it, but as users why should we care ?" Well, if you don't care about the devs, on what base are you asking them to care about your specific problem ?
    - justin66 2y ago
      > Well, if you don't care about the devs, on what base are you asking them to care about your specific problem ? Caring about the user's requirements is part of the dev's job description. Caring about the dev's... anything is not in the user's job description. (one advantage commercial software has: it really does help when there's an interface between the dev and the user in the form of customer support. or a commercial incentive to actually work on what the user wants.)
F3nd0 2y ago
From what I can see, he's neither an ass nor adamant that it's impossible. He claims it's impossible to universally support the jump within certain technical constraints (which VLC supposedly limits itself to). The only time I saw him being unpleasant in the thread is when people ignored his explanations and acted very entitled. Correct me if I'm wrong on anything here, but VLC is an independent free software project developed in no small part by volunteers; they have every right to choose their technical direction and compromises, and it seemed the people insulting them were in no position to demand anything from them.

efilife 2y ago

VLC is pretty bad and it shows the more you use it. It doesn't let the audio clip/exceed safe volumes and always applies some sort of a limiter, even if it's disabled everywhere in the settings. Try using an EQ on a bass-heavy track and see that it's limited. Try jumping back multiple times in a song at its beginning, and it will play in lower pitch.

darby_nine 2y ago
> VLC is pretty bad and it shows the more you use it. Compared to what? Such a statement is meaningless without comparison.
- opan 2y ago
  Compared to mpv. Some would also say compared to mpc-hc.
  - hollerith 2y ago
    The first sentence on https://mpc-hc.org/ https://mpc-hc.org/ is, "MPC-HC is not under development since 2017. Please switch to something else."
    - infofarmer 2y ago
      search engines and wikipedia point to actively maintained versions
    - defrost 2y ago
      Instead of MPC-HC v1.7.13 (2017) maybe try MPC-HC v2.3.4 (2024) https://github.com/clsid2/mpc-hc https://github.com/clsid2/mpc-hc In many ways it's a display wrapper about codec components, the display part is in active maintainance and bug fix mode (last update two weeks ago) and the codecs are constantly being improved (and expanded as new ones emerge). https://www.codecguide.com/ https://www.codecguide.com/ There are two or three MPC-HC spin offs that are tweaking the core to do new things.

Always42 2y ago

I have ran into this issue as well. I believe my solution was to use pot player but i am not sure if its open source

j1elo 2y ago

Wow those answers are indeed funny. I agree that as an OSS dev/maintainer, it's easy to fall on the vice of over-generalization and crusade for the perfect solution, and it feels that's exactly what happened there. > this feature is algorithmically impossible > You're just looking at one specific video, not the general problem. > is not generally possible. As a fellow multimedia dev, man, who cares? Sometimes we forget that software ought to be useful, not hypothetical ideals of truth. Just implement the feature for those codecs that support it and which probably are in the 98% percentile of what users actually use, regardless of the damned "general case". Or accept and announce shamelessly that you don't have either the knowledge or the development resources to tackle such a complex feature. But excuses about not being possible for absolutely every possible codec in a completely generic way is just denying that the world is just a chaotic and dirty place where things are not ideal nor perfect. Just give your users a real-world solution (or rejection).

ziml77 2y ago
I notice a lot of devs try to deny the chaos of the world. It's almost like the code is where they go to hide from things that can't be cleanly and unambiguously expressed. I don't know how they get away with that though. In the coding work that I do, I'm constantly dealing with rules that have exceptions on top of exceptions. I just need to special-case some things, because the alternative is not delivering what the business needs.
- jbverschoor 2y ago
  And this is exactly the problem when these devs are in charge of creating systems that actually do matter. They will not support edge cases, problems in a process, etc.
  - vharish 2y ago
    I mean.. can you show anyone piece of software or hardware or for that matter any man made creation that solves for all edge cases?

darby_nine 2y ago

> Like said earlier codec frame access is very problematic Wow. Talk about not understanding the user.

justin66 2y ago

The developer responds to a comment: But many players are able to do it for years. with: If it's so easy, why are you not doing it? He's not just a butthole, he's a stereotypical open source developer butthole. On the other hand, if he worked for Microsoft, he'd be claiming that it takes a PhD to do it...

Levitating 2y ago
In his defense, some commenters had a pretty rude attitude. You cannot demand developers to implement a feature or call them out on being lazy. Nobody even offered to research how other players accomplish this. They just expect that because they believe it can be done someome should do the work for them. At least Remi was actually andering questions on the forums. This attitude towards open source maintainers is what's getting them all burned out.
- KingMob 2y ago
  As a FOSS maintainer, I have sympathy for him, but as a communicator, I see he really failed to address multiple commenters pointing out that several other FOSS video projects had the feature. (At least in the first page of comments.)
- IshKebab 2y ago
  I don't think the other people commenting were being at all rude. They asked nicely if a feature would be possible. He replied with a blank "No" and from then on it was pretty much "but other players can do it so it must be possible" and him rudely and incorrectly asserting that it isn't and that anyway if it was why don't they do it if they want it so much. The correct response would have been something like "it's more difficult to do and in some circumstances it will have very bad performance so we haven't done it yet". This is classic "It's hard and I can't be bothered so I'll make up some technical reason why it's impossible". Programmers do this all the time and it's kind of annoying. (And yes I understand video coding and I know why it's more difficult in some cases.)
  - hobofan 2y ago

anigbrowl 2y ago

I'll be happy to switch over to MPV for this alone. VLC is great in general, but lacking some basic features. This sort of 'not possible' nonsense from developers is always a sign of a project's long-term decline.

mnsc 2y ago
"not possible" is as much nonsense as "everything is possible". Is it possible for vlc to implement support for rendering and editing common 3d object models? Yes! But is it possible given what vlc was set out to do? No! I think another sign of a projects long term decline is developers that are all too happy to expand the scope of the project. If that happens I just know that down the line the feature I started using the software because of is down prioritized due to the "need of supporting markdown in the email editor" when the software started as a MSN chat archiver.
- thiht 2y ago
  So you’re saying going forward 1 frame in a video is in the scope, but going back 1 frame is out of scope. Weird stance.
  - mnsc 2y ago
    If that feature would introduce a need to reactor or re-architect major parts of the the logic since everything has been built with the purpose of the playing video forwards supporting as many codecs as possible. Then, yes. And as a long time user of vlc video playback (and transcoding) I have never wanted to go back one frame. I always wanted to go back like 15 seconds, and that has worked forever.
    - thiht 2y ago
      > I have never wanted to go back one frame Good for you I guess? I have never wanted to go forward one frame so let’s remove that too
    - mardifoufs 2y ago

varenc 2y ago

Slightly related: mpv also has excellent backward playing capability! Of course video encodings aren’t optimized for this so it does some work to make the performance reasonable.

ThrowawayTestr 2y ago

You can press e to frame advance. Can't go back though.

romanows 2y ago

I was hoping that mpv would work a bit better than vlc for sending video to chromecast, but unfortunately, another similarly amusing thread: https://github.com/mpv-player/mpv/issues/177 https://github.com/mpv-player/mpv/issues/177

latexr 2y ago
Far from me to defend the whole mpv team[1], but the dev in that thread is a ghost (deleted user). I remember them, they were always rude and eventually got kicked out of the project and loudly complained about “being removed from the project [they] created”. I never found the exact reason why, though I can’t help but think the attitude had something to do with it. [1] Some are quite nice and competent. Others are exceedingly rude and will e.g. jump on an issue that had thus far been entirely cordial just to, without provocation, insult users for using whatever OS they don’t like.
- throwaway11747 2y ago
  The last issue that caused them to leave was their desire to move mpv to their own build system, which they believed they could write in a weekend. Other mpv developers thought that was a stupid idea and argued in favor of something more standard, such as meson. That was the last straw for both sides.
  - deleted 2y ago
    [deleted]
  - latexr 2y ago
    > their own build system, which they believed they could write in a weekend. That doesn’t seem right: > (…) I started this over a year ago (…) https://github.com/mpv-player/mpv/pull/7801#issuecomment-641850335 https://github.com/mpv-player/mpv/pull/7801#issuecomment-641... > Other mpv developers thought that was a stupid idea and argued in favor of something more standard That doesn’t seem right either. I just read the whole PR thread and I see a bunch of users arguing for it, not other maintainers. The maintainer was certainly controversial and I found several commits and bad decisions which look to be almost universally hated, but it’s not clear to me this specific problem was what caused them to quit or that it was motivated by other maintainers. If you could provide a source for your claim, it would be appreciated.

a-dub 2y ago

i can imagine how it would be annoying in a system that is designed to process live streams as opposed to one that is designed to have random access to the stream via persistent storage. if the target frame were not an i frame, you'd have to dig up the preceding i frame and replay everything up to the target frame. pretty easy for random access, not so much for a monotonic stream of frames.

plq 2y ago

Quote from that thread: > It can be added in theory, but there would be certain problems. Like said earlier codec frame access is very problematic (I, P and B frames), because in worst case scenario you have to decode about 248 sequential Full HD H.264 frames before you can get previous image (so there will be major LAG). Having used the 'previous frame' feature in mpv, I suspect this is exactly how it's implemented.

breck 2y ago

This thread is amazing. Thanks for pointing it out. What's lovely is that it is indeed possible, but not trivial, and you can see Remi is sort of baiting to catch smart talented programmers to the project. You can see the patience and long term horizon needed to lead a volunteer open source project. Time to study VLC more. Thanks!

thiht 2y ago
Yeah he’s probably playing 5d chess, not just being an ass
account42 2y ago
I don't see Remi's behavior in that thread attracting more developers than it pushes away.

PUSH_AX 2y ago

That guy sounds like a nightmare to work with.

IndySun 2y ago

That is one funny, informative read! Although, the first response, I feel, aught to have been 'non'. I can hear it now.

hatsunearu 2y ago

What really sucks ass is mpv doesn't have features to show what the frame count of the frame you're looking at is.

throwaway2037 2y ago

Wow, reading this now very old discussion makes me cringe a little bit when I see dingers like these: > If you think it is easy, VLC is open-source: you are welcome to provide the easy patch. Somehow, I won't be holding my breath. > If it's so easy, why are you not doing it? Talk is cheap. > I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers. > And I don't take moral lesson from an hypocrit who feels like they can demand work from "toxic" volunteers and even state that they are not there to do any actual work. There are so many (passive-)aggressive comments in that discussion. This is the primary reason why I never get involved with open source projects any more. The discussions are so toxic. I always wind up feeling terrible about myself after "trying to help" an open source project by reporting bugs or submitting patches to fix bugs.

deleted 2y ago

[deleted]

account42 2y ago

That was an interesting read. - Great example of letting perfect be the enemy of good. - Hilarious example of a developer making claims of what users want while ignoring the users in front of him. - Shows how CoCs can be and often end up being used in toxic ways. Is Remi the sole active developer or why did no other dev chime in to defuse the discussion? I'm all for open source projects sticking to their vision and standing up to unreasonable user demands but it really is in your own best interest as a developer to learn to communicate effectively - and keep an open mind for feature requests that sound unreasonable to you and first make sure if you understand what is being asked for.