←back to thread

1113 points Bluestein | 1 comments | | HN request time: 0s | source
Show context
lairv ◴[] No.41278203[source]
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
replies(19): >>41278382 #>>41278499 #>>41278639 #>>41278719 #>>41279342 #>>41279364 #>>41279561 #>>41279827 #>>41279842 #>>41279920 #>>41280125 #>>41281214 #>>41281733 #>>41282953 #>>41283275 #>>41284169 #>>41287180 #>>41289348 #>>41289743 #
j1elo ◴[] No.41278719[source]
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).

replies(7): >>41279461 #>>41279707 #>>41280296 #>>41280441 #>>41281134 #>>41281153 #>>41284201 #
sebastos ◴[] No.41280296[source]
Disagree!

VLC is what it is today because the authors understood video standards enough to make the _right_ abstractions that could generalize to ~every video format ever. That is no easy task. Video container standards are utterly perverse, and seem to delight in stomping over even the most innocent intuitions about what you would expect to find in a stream of bits that purports to contain "video". They often refuse to make even basic promises, like "the first frame's timestamp starts at 0" or "every parcel of data has a timestamp". Seemingly reasonable ideas that a neophyte might propose, like "suppose we store the video's framerate-" must be immediately interrupted with "you FOOL, there IS no framerate, nothing can be certain, this video might not even have frames, it might in fact be an interactive gift basket experience merely PRETENDING to be an mp4-". That's just the nature of the beast.

A playback architecture that can wrangle all of that cruelty into a consistent experience was hard won. Of course they're not eager to throw new features into the mix that will pollute that mental model, and suddenly introduce thousands of codec-vs-player-feature checks that were heretofore ruled out in principle. At a certain point, the architecture is sacred, and it's the only thing making VLC maintainable. If a feature doesn't work for everything, it doesn't work.

replies(12): >>41280388 #>>41280399 #>>41280530 #>>41280544 #>>41280813 #>>41280857 #>>41280938 #>>41281616 #>>41282720 #>>41282896 #>>41284083 #>>41289506 #
langcss ◴[] No.41280813[source]
If so, how comes you can do the workaround one suggested of entering a time one second ago then going forward a frame at a time?
replies(1): >>41280887 #
martin293 ◴[] No.41280887[source]
You can only do it for certain formats
replies(1): >>41281039 #
1. langcss ◴[] No.41281039{3}[source]
Sure but I thought VLC only supports features that work for all formats, and supporting features that work for only some formats is a no no and for that reason previous frame is not possible. Yet skip to time is allowed.