6 ms·

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.

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.