> 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"?
> It's of course work to do, and I'm not super motivated to send them that patch, and there's the question of it it would be merged
That's my issue; he calls for people to send patches, but anyone capable of writing such a patch is also probably going to see that he's not positive on the matter, and that his "patches welcome" is really pretty passive aggressive in this instance. At least, that's how it comes off to me. I would expect that, should I submit such a patch, it would simply be rejected on the basis that "it is not a general solution".
One other team at my workplace insisted that they can’t make their product compatible with our product, because it would take a team and half year. I knew that it’s a lie, but we convinced them to “allow” us to make for them. I finished - alone - in four days.
It was never merged. It was purely political. It was never about whether it’s possible or not.
There's also a middle ground: Painstakingly describe the solution first, along with its downside of not being general in the same way as some of the existing features (I guess for example seeking back 10 seconds) are not, and ask whether a patch implementing this solution would be welcome before implementing it.
I wanted to report a big about VLC's extraordinarily badly designed "Magnification/Zoom" user interface, so first I searched the forum to see if there was any other discussion about it, which there naturally was.
So I painstakingly wrote up an extremely detailed description of a bunch of interrelated bugs related to zooming and how it terribly interacted with other features like rotation, in response to the VLC development team brushing off another user complaining about its terrible "Magnification/Zoom" user interface, and they brushed me off too because they were too lazy to read it.
They told me to just submit a bug report, but I pointed out that I was describing a several interrelated bugs, which would require submitting many bug reports, which they would have known if they had actually bothered to read what I painstakingly wrote in great detail with step by step instructions about how to reproduce the bugs and suggestions for improvements, so I obviously wanted to discuss them all first to see if they were even worth my time submitting multiple bug reports about, or if all my efforts reporting bugs and trying to fix them and submit patches would be a waste of time, brushed off and ignored like they did to the other users who described the bugs and usability problems they were experiencing.
Jean-Baptiste Kempf himself replied "If you did shorter posts, maybe people will read them..."
To which I replied "if you did less arrogant responses to long posts, maybe people wouldn't give up on trying to help you."
And of course most of the pathologically terrible bugs I described are still there, a dozen years later. And Jean-Baptiste Kempf still continues to act that way.
HN user KingMob's post perfectly summarized my discouraging experience from a dozen years ago, about a set of bugs and usability problems relating to the horrible "Magnification/Zoom" interface:
>KingMob 5 hours ago | unvote | parent | context | flag | favorite | on: Mpv – A free, open-source, and cross-platform medi...
>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.
Jean-Baptiste Kempf still continues to act that way, and still hasn't even admitted to those bugs and usability problems, let alone fixed them or accepted patches from anyone else who did. He just discourages qualified developers from collaborating, and brushes off legitimate requests from users who can't code but fucking well know other video players don't suffer from those problems.
To be fair, as a maintainer I also dread walls of text from super motivated people about details to which I assign very low priority. I’m never an asshole about it, though.
To also be fair, to "Painstakingly describe the solution first" absolutely requires a wall of text to enumerate all the multiple layers of interacting bugs, and give step-by-step instructions for reproducing them.
At least I put in the effort to search the discussion group for an existing thread about the problems I had, and contributed to that thread by supporting other users and validating their complaints, instead of opening yet another redundant thread.
The reason I went into so much detail was that the VLC developers were ALREADY acting like assholes by brushing off other people's shorter less detailed descriptions of the same problems, with glib quips like "The holy grail already exists... built in to OS X."
The zooming built into OS X definitely doesn't solve the problems that they refuse to admit exist with their astoundingly terrible "Magnification/Zoom" interface, so I described the problems for their benefit in the same detail I would appreciate in bug reports on my own open source software, in response to their rudely and curtly brushing off other users with the same problems, who don't all have a background in user interface design and software development and writing bug reports.
If the holy grail already exists and solves the problem, then they should REMOVE the horrible unusable "Magnification/Zoom" feature that breaks even worse when you dare to rotate or flip the video, or better yet they should have never allowed that broken "feature" to be merged into VLC in the first place, because of its ridiculously poor design and implementation quality (like drawing and tracking the gui with gigantic fat pixels in un-scaled, un-rotated video pixel coordinates, instead of full resolution screen overlay coordinates, and ignoring the flip/rotation for mouse tracking so you can't see what you're pointing at, which is negligent and insane).
Ironically, VLC accepting and distributing features like the "Magnification/Zoom" interface certainly undermines their arguments that they don't want to accept other patches because of quality and reliability and usability issues. If they refuse to fix it, they should remove it instead, it's just so bad.
And if I didn't bother going to the effort of describing the problems in detail with step-by-step instructions to reproduce them, I'm afraid that Jean-Baptiste Kempf is so thin skinned and arrogant that he would have brushed off my bug report for that reason too. Just like he CONTINUES to rudely and passive-aggressively brush off and ignore other people's perfectly valid bug reports to this day, 12 years later. He's not going to suddenly change.
My first programming forays were with the assembler feature of DEBUG.EXE, on an 8088. Extraordinarily cumbersome in retrospect, but it was existing at the time. Definitely a gateway experience.
I would guess that having it drilled in from childhood probably has something to do with it. By taking issue with it, you're going against the flow and people in general seem to be uncomfortable with that sort of thing. It also seems to me, that people tend to associate it with something other than the actual words that are being spoken.
> It's like people forgot that non-web-interface rss readers existed.
I'd wager that a lot of people never even knew these existed. To a lot of people, the browser became (or simply always was) the only real interface to everything internet related (or for some people, just about everything period).
Probably, they are like me, meaning we seem not to be on the same page as you regarding the term 'podcast'. To me, a podcast is just an audio talk session, mastered and distributed as a digital audio file. That's it. Distribution can take many forms, but the podcast is the file. 10 or so minutes of google-based research seems to offer support to this notion.
> universe of media distribution that happens via an open protocol that is not controlled by any one company
What is this protocol that you speak of? Searching "podcast protocol" leads to absolutely no useful links on the subject. Podcasts in my experience are distributed in one of three ways:
* Download links on a web page
* Embedded streaming links on a web page
* An RSS feed
That last (RSS) could be considered a "protocol" of sorts, I suppose. At the very least it's what I would expect a podcast app to support. But you then go on to refer to RSS as a separate entity from your "podcast protocol", so I'm back to being confused as to what you might be talking about. What is this open protocol that is intrinsic to your definition of 'podcast'?
RSS can be considered a syndication protocol, or a 'standard' if you want to be strict with the term protocol, but nothing about those distinctions is pertinent to the point I was making.
Podcast can refer both to individual episodes or to the series of episodes, neither usage is more correct than the other, it's your responsibility to interpret words in good faith in the context in which they're used. And again, nothing about this distinction is pertinent to the point I was making.
RSS is not the same thing as podcasts, because while generally all podcast feeds are distributed via RSS/Atom, they aren't necessarily, and moreover not all RSS feeds are podcasts.
And again, nothing about this distinction is pertinent to the point I was making. To reiterate, Apple, with the iPod, was instrumental in elevating podcasts to a mainstream medium of content distribution. It's by analogy to this that I make the point that Google could have played a similar role in facilitating the mass adoption of RSS.
I'm not interested in any further exploration of the conceptual differences between RSS and podcasts unless you believe it has an upshot that's relevant to the original point I was making.
Well, yeah. Not only is it not the same thing, the concepts aren't related in any way.
A podcast is an audio file. RSS is a format for publishing the information that you've updated your website.
>>> With podcasts, we now have an entire universe of media distribution that happens via an open protocol that is not controlled by any one company, which is a miracle.
We had that before podcasts. You go to a web page, and you download a file. The protocol is called "HTTP", the HyperText Transfer Protocol.
> a podcast is just an audio talk session, mastered and distributed as a digital audio file
Traditional talk radio uploaded to a web page would meet that definition. And that's the stereotypical genre of podcast content but there are others, like narrative fiction (Welcome to Night Vale).
I think "a podcast" is less about the specific genre of the content and more about how it's experienced. It's a podcast if it's time-based media you can subscribe to and experience in a variety of players; otherwise, it's sparkling media.
If you have to use the Spotify app, it's not a podcast. I see "plus" subscription options in the iPhone Podcast app, if you had to use that app, they're not podcasts; if you can use different apps but only on Apple devices, I'd still consider them podcasts.
That may be true, and it may be of personal value to pursue this for yourself. That's different from socially badgering others into it at group events.
I haven't sung a hymn, pledge or anthem since I was 11 or so. I just stand there and watch, be it church, baseball, hockey, whatever. 32 years and nothing bad has happened yet. (Hooray freedom?). I don't believe there is any pressure whatsoever.
So in other words, you disagree with the post I'm replying to?
> I don't believe there is any pressure whatsoever.
You've clearly not been to some of the events that I have. Also, there's the whole matter of various public school systems. Regardless, if there hasn't been any pressure for you, then this is sort of a non-sequitur, as my comment is talking about situations where there is pressure to begin with. Non-pressure situations are out of scope.
> You've clearly not been to some of the events that I have.
Ok, such as?
> Non-pressure situations are out of scope.
I am attempting to say this with respect, believe me: I am saying the pressure is not real. At least in my experience, it's not worth your time. I respect that you may have a different situation than I do, and you may experience pressure of this type differently than I do, but "pressure" strikes me as subjective because in fact there are no real consequences that I'm aware of (as in legal, regulatory, etc). And, without further details, we can freely end here dismissing eachothers' perspectives as irrelevant.
are you willing to take the Pepsi challenge? next event you go to that does the anthem ritual, i challenge you to not participate by sitting down. see what kind of not real pressure you feel then.
> real consequences that I'm aware of (as in legal, regulatory, etc)
So if I understand correctly, the argument is that social pressure isn't real pressure and can be dismissed as inconsequential? If that's the case, then yeah, I think this is played out and we can call it here.
(Not because I strongly agree or disagree with such a notion, I just kind of think it would be getting off into the weeds a bit much to continue at that point.)
This discussion has inflated scope from "I don't like attending events because it's weird we're required to say a hymn or pledge" stated by one person.
With response "well you don't have to say or sing - I don't"
All the way to arguing over whether I really feel social pressure and how Colin Capernick has to stand so obviously I'm wrong.
We're really deep in the weeds looking for a technicality to nitpic my original statement, don't you think?
Your original statement was "I don't believe there is any pressure whatsoever." Maybe you meant that in some limited range, but it's hardly nitpicking to think you meant there was no pressure whatsoever.
If your entire point was that you don't have to sing along, sure. I don't think it's even encouraged in many performances. I had a friend who liked to but always did it under his breath to not disrupt things.
I took the original post to be criticizing forced participation in the ritual.
Someone's not allowed to go to a sporting event because you say so? That's a load of crap. I'll go to whatever event I want. If they have one of these dear leader performances, I just stand there thinking about whatever is on my mind. If you like it, you can sing your little heart out. But I'm not going to not go to something I enjoy because you might get offended at my non-participation in your cult-like ritual
Because the person suggested that I not go to the event.
Also, as "not mandatory", have you ever chosen to remain seated and experienced the reaction from those around you? You'll definitely get the feeling "not mandatory" is a very much incorrect description.
> haven't sung a hymn, pledge or anthem since I was 11 or so. I just stand there and watch, be it church, baseball, hockey, whatever. 32 years and nothing bad has happened yet. (Hooray freedom?). I don't believe there is any pressure whatsoever.
YMMV, but I do just stand up and not sing. It's not the end of the world. And some people always keep their hand down, instead of over heart. Again, I'm really not experiencing difficulties here, but I respect that there might be other factors. Like, do you live in the deep south?
I’m sure your question is rhetorical, but just in case - I think we all know it’s because they want to fit in, or at least… …not get called out for not participating.
Yes, it’s not mandatory and yes you _could_ sit down and not sing, but the consequences are that your fellow spectators will be agitated. They may not show it in any way, or… …they might!
So, on the larger context of the thread, we started by saying it's weird that we're required to say a pledge or sing a national hymn. I'm saying I haven't done that in 30 odd years and have not suffered any negative consequences, so perhaps the requirement was overstated.
The interpretation of my intended message has transformed a bit beyond the original scope to include never standing, not even feeling social pressure of any kind, and a comparison to Colin Capernick who attends sporting events in an entirely different capacity than I do. Those points just sound a lot like trying to win an argument on technicality vs have a discussion about experiences.
All I'm saying is you can feel all the pressure in the world to sing a hymn or say a pledge at events, compromise half way by standing, and not sing any national hymn or pledge and suffer no compromises. It is absolutely not required.
I never said you weren’t allowed. I said if it bothers you so much you can choose not to attend.
My father in law stopped watching sports during the period where it became popular to kneel or not stand during the national anthem to protest or bring to light various social causes. In his view, those things don’t belong in sports. That was his choice, it’s not mine, but he didn’t make a big stink about it, he just chose to stop consuming that form of entertainment.
At some point you either conform, choose not to conform and deal with the consequences, or simply avoid these events. The rest of the populace doesn’t have to change their behavior just because you don’t like it.
Collectively we have become a society of intolerant crybabies. We don’t have to agree with everyone, but we do have to tolerate the common social norms unless we want to be that guy that gets unwanted attention.
In fact, I generally don't. On the other hand, that is not because I am bothered (or not) by such practices.
I'm really not sure what this has to do with the opinions being expressed by myself, parent, and GP here. I can avoid a behaviour and simultaneously have an opinion on the behaviour, which I am expressing here in response to others' opinions on said behaviour.
I very, very strongly disagree. If you hate the country you reside in so much, don’t show up to those events, or better yet, purchase a ticket to go live somewhere else that better suits you. I don’t have even the slightest bit of tolerance for that kind of apathetic, the-world-revolves-around-me attitude.
Sons had their legs blown off so you could be free to whine on an online forum about having to honor them for 60-seconds at sporting events you have the freedom to attend. Truly astounding.
Not following pathological nationalism isn't the same as "hating your country". Saying otherwise is just propagating a false dichotomy.
We can be thankful to live in this country without needing to force others to do so as well. In fact, to borrow from your earlier point, we actually have the freedom to hold a different opinion about nationalism/patriotism, unlike many oppressive countries.
This is the exact reason* I bought a 4090 for my recent rebuild instead of the rDNA card I actually wanted. I really wanted to go with AMD for the driver integration with the Linux graphics stack —- I’m so, so tired of shenanigans when it comes to decades old features of X not working or working poorly due to some nvidia bug/non-integration.
But being able to leverage my graphics card for GPGPU was a top priority for me, and like you, I was appalled with the
ROCm situation. Not necessarily the tech itself (though I did not enjoy the docker approach), but more the developer situation surrounding it.
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"?