mtrower

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

Have a go at it in the wilderness and you’ll realize really rather quickly how disconnected modern … durations have become.

But yeah, for some it’s definitely an escape. Particularly at work.

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.

> socially badgering

> pressure is not real.

> 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.)

..."pop off"?

I get the impression that you're inferring things about me that aren't actually real. Such as a lack of respect for the fallen.

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.

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.

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.

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

Honestly I struggle to think of a more complicated program than a modern browser that expects to fully support the existing web.

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.

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.

* well, that and some vague notions about RTX

The letter or the intent though? Because if it’s the letter, we’d better throw in wheel chairs, surfboards etc. as well. The law does not specify motor vehicles, even though I would believe that to be the intent.