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

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.

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.

When I was hired for my first real programming job, my future manager spent a lot of time asking me questions about how I deal with ambiguity. This stuck with me as a really important element to consider in people, but that doesn't seem universal, especially in tech circles.

This is a very broad generalization and not a good one either. Particularly in this context. It's obviously not possible to do it for all video formats in a consistent way. I haven't read through all of it yet I could tell all the proposed solutions are hacky ones. Your scenario doesn't apply here. Businesses are different. This is on open source project. Anyone can work on it.

What are you even saying about the choas of the world?! Every dev knows how work is. You are just describing every other software job. Somehow it sounds like you are boasting how matured you are just because you do what your client asks/needs. Even then, many business/software make a concious choice to support or not support something based on some guidance. The guidance could be some core principles or just some product managers whim.

It's highly likely that VLC developers chose not to support the feature for the very reason(s) that's described in the post. It's a concious choice they made. I don't see anything wrong in that. They definitely are not some school kids with some daddy issues to hide behind some code. They clearly have answered all the questions from a technical stand point.

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?

Outside of those contributing to open source projects professionally, the vast majority of contributors will (naturally) be those with greater technical abilities, which unfortunately impacts the general UX of free/OSS overall in my opinion.

Because it's an open-source project, not commercial software.

In your job, you have to special-case some things because the alternative is not delivering what the boss wants. Regardless of the problems this may cause, or how much tech debt it generates - those are (in the end) business decisions, and while you can make a case to the boss that implementing the special case feature is going to cause huge problems, it's the boss's call as to whether it gets implemented.

In an open-source project the maintainer is the boss. If the maintainer thinks that the feature is going to cause problems, they're totally free to say "no, I'm not going to implement that feature". And, ofc, because it's FOSS, the user is totally free to fork it, or submit a PR for the feature, or whatever.

> just got here from a Google search. I gotta say the replies from Remi sound defensively toxic. I'm not here to program the app, I'm just here to find a simple feature and/or request it.

I think Remi sounds curt rather than toxic. There's no automatic right for anyone to go to a FOSS project and request a feature and have it implemented. The maintainer is perfectly within their rights to just say "no". It's their project, their code, their time, and they're free to do/not do anything they like with it.

But it’s just simple things, like allowing an override of a status field.

Or using a status field to check something is ok or not, instead of always checking the data itself.

People make wrong assumptions, and requirements change. Don’t make it all rigid that you always need to implement every case

If you say "no, we're not pursuing this feature because it's impossible" and users have used other software that implements the feature to a reasonable degree of functionality, you're not doing yourself any favours in terms of shutting down demands. You'd be better off either not giving a reason at all, or giving reasons that are clearer to people who aren't as knowledgable.

Reasons are actually stated, they explained it is not feasible for the general case.

Once the devs have made clear they don’t plan to do exceptions (as other softwares do) then users should accept it and move on instead of keep harassing volunteers.

Everything is a “simple thing” unless you’re the one implementing it. Things that seem simple on the surface rarely are, especially long-term.

But he didn't "just" say no:

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

I'd say that is pretty toxic.

Specifically, that is no way to talk about other volunteer developers that contribute their time. It is precisely the kind of language that keeps people away from contributing to open source. It's the very definition of toxic.

This is taken out of context. He actually respects contributors, including their decision to not implement reverse play.

The meaning here is "if you think the existing contributors are as incompetent and lazy as you are implying, then do better".

I think he got caught up in the argument and that he should have just put the question in a FAQ entry and lock the thread before people start mentioning nazis.

> lock the thread before people start mentioning nazis.

Which will invariably happen. What was that "rule" called again?

It's Godwin's law (of Nazi analogies): https://en.wikipedia.org/wiki/Godwin%27s_law

Quite remarkable that you call the developer toxic when those were his replies paraphrasing what users had said and demanded up-thread.

> that is no way to talk about other volunteer developers that contribute their time.

He is not dissing the other developers. He is one of those developers that had been called lazy and incompetent by the forum posters. For example (from the thread):

> it's mostly an excuse to not implement the feature (and be "cool" about it with one-word answers).

> Please consider implementing this. It's not hard.

> All of the players I've named are open source, so it's easy to check how they are doing it.

> Seriously how hard is it to implement it? All Ive been hearing from the developers are excuses, excuses, excuses. I dont see how other players were able to have it. This is just pure laziness.

> I'm not here to program the app, I'm just here to find a simple feature and/or request it.

Personally, I would hold the people using a free product and begging for features without contributing anything to a higher standard than the developers that donate their time implementing it.

Why is it incumbent on the developers (who know their codebase and its capabilities better than the forum posters) to explain their decision to the forum posters begging for a feature, and not only explain it, but explain the decision and the reasoning behind in such clarity and depth that the forum posters (who might not even be programmers, let alone know the code base) understand it sufficiently well to refrain from begging and insulting?

I’d say it has to do with not willing to duplicate data. On paper forms, it is simple. Why can’t it be in a digital form?

Yes ok, I did read the thread but didn't get the reference. I wouldn't say it's "quite remarkable", more simply that I misunderstood. My apologies.

But I stand by the broader point that I do not think his attitude is at all constructive or helpful, and while I am sure he is fed of up what he views as entitled users this is not a productive way to handle it. The toxicity is that it casts shade on FOSS and pushes people away from the community. And VLC would be half what it is today without it's users. He would do well to remember that, too.

Thanks for this. It seems you got that I misunderstood. I've clarified my point in another reply.

Also agree that if this is a question that keeps coming up a much better response would be to simply explain your reasoning once in an FAQ that carefully presents the argument and point all future discussions to that entry. Done.

To the average user, it's not at all obvious why reverse play is so much harder than it looks. Surely it's possible to understand that users might be confused by this? An well written FAQ on the subject would solve all of this.

The QuickTime API supported reverse play around 1993 or so, when I enjoyed using it for "back and forth" animated sprites, and playing music videos backwards to reveal the satanic messages with demonic backmasking.

Reverse / Backwards Moonwalk - Michael Jackson - Better Than The Original!!!

https://www.youtube.com/watch?v=IT_Aq2FjJo0

Here's the documentation and code I wrote when working at Kaleida Labs (a joint venture of Apple and IBM) on a ScriptX animation library that used QuickTime and other renderers, and depended on QuickTime's support for playing videos backwards, and single stepping forward and backwards of course:

ScriptX Animation Library:

https://www.donhopkins.com/home/catalog/lang/scriptx/anim.ht...

ScriptX Animation Implementation Module:

https://donhopkins.com/home/archive/scriptx/animimp.sx

ScriptX's QuickTime renderer would even play audio backwards and at whatever speed, too. ScriptX had excellent multimedia clock synchronization, and we would have considered it a terrible bug if ScriptX was not able to seamlessly and transparently synchronize video and audio with any arbitrary clock, time offset, and time scale, no matter what the speed and direction.

https://en.wikipedia.org/wiki/ScriptX

I'm sad that 31 years later, web browser video and audio players (not to mention VLC) don't support hierarchical clocks like ScriptX did for multimedia synchronization. (Each child clock can have a time offset and time scale relative to its parent, and everything's automatically kept in sync, from the simulation to the renderer.)

Here is Kaleida's (then Apple's) 1993 patent on "Synchronized clocks and media players", which has long since expired in 2013:

https://patents.google.com/patent/US5452435A/en

>Abstract: A media player and the clock which controls it are integrated into a single object. This integration may be achieved by the construct of inheritance between objects in an object oriented programming environment. A software class for player objects is established which inherits from a software class for clock objects. In this way, a player "is a" clock. This integration provides improved synchronization among different media, and simplifies design of applications which employ player objects and clock objects. Each object is synchronized to a RootClock object which operates at the speed of the fastest media player in the system. The RootClock may be separated into "low" order and "high" order components and a compare register in order to reduce interrupt overhead.

>[...] QuickTime essentially allows a multimedia player to process timebased data. Since the data are time based, QuickTime provides for the description of "time" (called time basis) for the data as well as a definition of the context for evaluating that "time." In QuickTime, a movie's or media's time basis is called its "timebase."

>A timebase is essentially a vector that defines the direction and velocity of time for a movie or media. The context for a timebase is called its time coordinate system. Conceptually, a time coordinate system provides an axis for measuring time. The time coordinate system, like a geometrical axis, is divided into units of measurement by a measurement system, called a time scale. [...]

https://news.ycombinator.com/item?id=18781950

DonHopkins on Dec 29, 2018 | parent | context | favorite | on: Steve Jobs hired a career juggler to teach program...

Oh, of course I wish Apple and IBM had made it free! But it included Apple's "crown jewels", the QuickTime player source code, and they were't going to give that away in 1995. Apple were even trepidatious about IBM having access to that source code.

Besides having proprietary decoders, it could also do some things you can't even do well with the Flash player or html video component today: like smoothly playing videos and music backwards!

Ever since the music industry switched from vinyl to CD, listening to demonic backmasking in Devil Music like the Beatles and Led Zeppelin's promotion of Satanism became much less convenient. ScriptX solved that important problem elegantly with its synchronized clock system, but today's HTML video player still hasn't, alas.

https://en.wikipedia.org/wiki/Backmasking

https://www.youtube.com/watch?v=5BDh_j5qAJ4

Here's a description of ScriptX's clock system:

https://news.ycombinator.com/item?id=18350511

>Kaleida Lab's ScriptX (a multimedia programing language kinda like Dylan with classes) had built-in support for hierarchal clocks within the container (in the sense of "window" not "vm") hierarchy. The same way every window or node has a 2D or 3D transformation matrix, each clock has a time scale and offset relative to its parent, so anything that consumes time (like a QuickTime player, or a simulation) runs at the scaled and offset time that it inherits through its parent container. And you can move and scale each container around in time as necessary, to pause movies or simulations.) You could even set the scale to a negative number, and it played QuickTime movies backwards! (That was pretty cool in 1995 -- try playing a movie backwards in the web browser today!)

Is it possible to play HTML5 video in reverse?

https://stackoverflow.com/questions/5277293/is-it-possible-t...

Kinda, but it's not smooth enough to sing along while dancing backwards and worshiping Satan to:

https://codepen.io/adrianparr/pen/qmCek

kragen on Dec 29, 2018 [–]

Yeah, I remember het AVI porn in the early 1990s where time alternated between forward and backward, thus providing an infinite video in only a few frames. (Probably it would have been more realistic with a sinusoidal rather than triangle-wave temporal waveform.)

I think there's a lot of space for experimentation here, generating video as an arbitrary three-dimensional slice of a potentially higher-dimensional space — like how horse-race photo-finish cameras map one vertical spatial dimension and one temporal dimension into two spatial dimensions for the photo, or how Julia-set animations map two of the dimensions of the four-dimensional Julibrot onto screen space while mapping a smooth path through the other two dimensions onto time. I've gotten some stunning still images by taking even fixed horizontal or vertical slices through video, but you could also do things like delay one side of the picture more than the other, or foreshadow future action by curving part of the frame into a timelike angle through the source material. It might be difficult to record a source video with more than one temporal dimension with a camera, but you can certainly do it with ray-tracing or other rendering techniques.

Presumably if you want to play a video backward with a modern codec, you need to buffer up decoded P-frames in memory from at least the previous I-frame — much like iterating backwards over the lines in a file, except that each "character" is a megabyte or two of YUV pixels. Should be totally feasible on a modern cellphone, even for aggressive modern formats that only have I-frames every few seconds… but it would be nothing short of a miracle in 1995! I guess MPEG-2 didn't exist yet, so maybe MPEG-1 with N=18, M=2 was the worst case you'd need to handle at that point? That should only require a 10-P-and-I-frame buffer.

But the hacky solutions actually get done what people want the software to do. The point between me and the parent poster is that a solution necessarily being hacky is not a good reason to not implement a feature.

And TBH the VLC example hardly even seems hacky. If you have a stream that can be seeked backwards in, then find the previous I-frame and internally run the video forward to the frame the user wants to see. That is exactly what the user is forced to do manually anyway.

As far as it sounding like I'm boasting, all I can really do is assure you that was not the point. I was contrasting my experiences with how people tend to write about software development in blog posts and in comments on places like here. I do not think I'm better than them simply because I am ok with implementing hacky solutions where I think they make sense. But I am annoyed when useful features are denied because it would require a hacky solution. For FOSS, it's entirely within the devs rights to operate that way, but to me that's one way FOSS software can sometimes fall short of commercial software.

Because - and more so for the maintainers/managers of those projects - being able to communicate effectively is part of what it means to run a successful project?

That may even mean that you have to hold yourself to a higher standard than some low-effort post on the part of some casual user. Especially if you're the boss, the maintainer, the leader. And if that's asymmetric then yes it is - but to be a maintainer/manager of a project is also asymmetric. Good managers might also promote that culture more widely across all the project's contributors and so yes it may apply to all developers, too.

Not everyone that engages with your project is going to be perfect, some may even be rude. But as a representative of that project it's a skill to be able to cope with that, on behalf of the project (not you). I think one of the most underrated skills of a FOSS maintainer is a degree of fault-tolerance, to use a systems analogy.

Or, you could argue that no, it's not incumbent on a maintainer to be anything, even to be kind. But then don't expect your users to come back.

Ah, fair enough. I think we agree mostly then - he is fed up, he is justified in it, yet it is not very productive. (I wouldn't call it toxic, though.)

> And VLC would be half what it is today without it's users. He would do well to remember that, too.

I disagree. It would be exactly the same as it is now without the users. The users have not contributed anything to the project. Popularity doesn't write code, it just creates communication overhead.

Again, this is not commercial software. Commercial software needs popularity. For FOSS projects, popularity is cool and can be an ego-boost for the maintainers, even open some doors and get some funding, but it's not the point of thing (and never covers costs anyway). The point is to write some good code that scratches some itch the maintainers have.

That whole point of view from the users, of "you owe us because your thing is popular now" is toxic entitlement. If you didn't contribute to the project, you didn't affect it, and you're owed nothing, absolutely nothing, by the maintainers. Everyone would do well to remember that.

The whole point that Remi was making is that doing this for one format is probably easy. Doing this for all formats in a consistent manner with a consistent experience is not easy, verging on impossible. Other players only support a limited set of formats, so can do this easily. VLC supports everything, so therefore has to handle all the bizarre quirks that make this a very difficult task.

... except VLC implements time-based seeking which has pretty much the same requirements and is consequently not possible with literally all files either. But both are possible with 99.99% of video files you will come accross.

VLC developers are of course free to reject any feature request but if they do it by bullshitting their users (and that includes tacking on additional requirements that no user actually needs like perfect support for all formats under the sun) then they will be rightfully called out for it. Then throwing a tantrum and citing CoC violations is not going to improve things.

It's their project so ultimately they get to choose to run it into the ground but this kind of behavior is not something I want to support as a user os I will stay away from VLC which includes not making helpful bug reports and not donating.

That article means: inexperience and unprofessional. Sounds about right.

If you’ve never written software that needed to be used by tens of thousands or hundreds of thousands of people, then sure, it could seem that way.

It may be slightly rude but it's also correct and it's something that not enough people realize, so they need ot be told. If you want something done, you can ask, but if the answer is no, you have to do it yourself. That's reality in FOSS.