[HN Gopher] Mpv - A free, open-source, and cross-platform media ...
___________________________________________________________________
Mpv - A free, open-source, and cross-platform media player
Author : Bluestein
Score : 1041 points
Date : 2024-08-17 18:56 UTC (2 days ago)
(HTM) web link (mpv.io)
(TXT) w3m dump (mpv.io)
| mathfailure wrote:
| The best media player available on linux. The worst GUI (none)
| out of the box. Bearable after tinkering a bit with configs.
| Bluestein wrote:
| > The best media player available on linux
|
| Strong clam, this ...
|
| PS. For the controversy: Please note I am not disputing the
| claim - particularly when many claim this is the best player
| _on any platform_ , not just Linux.-
| pengaru wrote:
| > Strong clam, this ...
|
| What's better?
| lottin wrote:
| mplayer
| prurigro wrote:
| Isn't mpv a more modern and maintained mplayer fork?
| Mplayer was my go-to for many many years, starting in the
| early 2000s, but I switched at one point and can't
| remember why. What do you prefer about mplayer?
| lottin wrote:
| If I recall correctly, for a brief time mplayer
| disappeared from Debian. At the time I evaluated various
| alternatives and mpv was one of them, but I switched back
| to mplayer as soon as it made its way back to the
| distribution. For me, mplayer is the standard media
| player. I guess I just don't see any reason to switch to
| mpv or to any other player.
| pengaru wrote:
| I see no reason to cling to mplayer/mplayer2, mpv has
| pushed things forward from there.
|
| mplayer is what I used to use ages ago, can't think of a
| single thing I miss that it did which mpv doesn't. Like
| you, I was introduced to mpv through the debian
| disappearance, and it's been fine. Forks can be necessary
| to keep development active; it's one of the core features
| of FOSS.
| chungy wrote:
| mplayer has DVD menu support, mpv doesn't. I use Kodi if
| I need to navigate DVD menus these days, which is rare
| but it happens...
| chgs wrote:
| I used played for 20+ years but moved to mpv recently as
| I ran into a couple of things player won't work with.
|
| Struggling to see the benefit of mplayer over mpv today.
| loeg wrote:
| mpv is an active mplayer fork.
| vocx2tx wrote:
| > The worst GUI (none) out of the box.
|
| That's funny, for me that's exactly the _best_ GUI out of the
| box. I actually did some tinkering to reduce the GUI parts even
| more, and added more keyboard shortcuts.
| sgc wrote:
| I use SMPlayer as a front end for mpv (you can select mplayer
| or mpv as backend). Not sure if that is common or even a good
| idea. But I am generally happy with it.
| Glyptodon wrote:
| That's funny. SMPlayer was my preferred MPlayer front end
| before I switched to MPV years ago. And I've never really
| felt like I needed more GUI for MPV.
| quohort wrote:
| try celluloid https://github.com/celluloid-player/celluloid
| globular-toast wrote:
| It does have a GUI in the form of video overlays. For me it's
| perfect. By default it just shows the video which is both
| necessary and sufficient.
| w4rh4wk5 wrote:
| Is this worth a look when you are pretty happy with VLC already?
| baal80spam wrote:
| Yes, it is. I don't understand the cult of VLC to be honest.
| There are better media players, at least on Windows.
| djbusby wrote:
| We love VLC because it plays anything, everytime.
|
| And has done this, for a long time, since times when other
| players struggled.
|
| Maybe it's not the "Best" - it is still the goodest.
| literallycancer wrote:
| VLC doesn't play everything though. mpv plays stuff that
| VLC can't play. I never have to worry about codecs or
| installing anything.
| djbusby wrote:
| Sure. My point is that VLC gets a special place. It "just
| works" for a decade before MPV, still does and across 3+
| platforms!
|
| MPV is great too! I think it's important to also
| recognize how rad VLC was and continues to be.
| blooalien wrote:
| VLC plays pretty much any media file from pretty much
| anywhere it can be stored, and it's got a pretty standard
| interface, so folks find it easy to understand how to operate
| it. That's it. No real "cult" situation there. Just an app
| that does it's job well. Same is true of mpv, but some people
| will prefer it (as I do) because it's lightweight and clean
| and quick (and all the stuff people also like about VLC).
| w4rh4wk5 wrote:
| I do use MPC-HC on Windows, but it's no longer under
| development :'( IIRC it can't do AV1.
| ivann wrote:
| There is a fork that's still under development [1], or you
| can use mpc-be [2].
|
| [1] https://github.com/clsid2/mpc-hc/ [2]
| https://github.com/Aleksoid1978/MPC-BE
| zeppelin101 wrote:
| I'd say there are a few aspects that make VLC an easy, common
| choice: 1) it has incredibly extensive functionality (even if
| MPV has more capabilities, with VLC, it's all available
| through menus/GUI - no need to memorize any commands) 2)
| handles any files you throw at it EVERY time - out of the
| box. Throughout the years, VLC has been the only player which
| didn't choke on ANY file I threw at it. 3) It's multiplatform
| and works (in my experience) equally well on Windows, Linux,
| and MacOS - OUT OF THE BOX! Even on Android, where I normally
| prefer using MX Player Pro (bc it has a slightly nicer
| UI/UX), it was able to handle video files where the audio was
| in the DTS format. MX Player Pro required the installation of
| codecs to make the audio work. 4) It's been around forever,
| so if you want to look up any info related to it, you're sure
| to find it more easily than for any other player.
|
| All that said, VLC is not always my video player of choice.
| On Windows, I typically prefer PotPlayer and MPC-BE. On MacOS
| - IINA. On Android - MX Player Pro. But I always keep it
| installed on all those platforms because I know that I can
| fall back to it reliably at a moment's notice and it will
| simply work.
|
| Additionally, with regard to MPV, where I think it makes the
| most sense is for the highly discerning user who wants to
| tweak the rendering of video in a specific way. I think anime
| fans really like it a lot (I'd imagine they upscale or
| improve the image quality in very subjective, specific ways,
| though I didn't investigate this in detail). The other good
| use case is when you have somewhat limited hardware and you
| want the most efficient video player application. That is
| perfectly valid, I suppose, but I think for most people,
| whatever hardware they're playing a video file on is likely
| more than capable of running with a more 'unoptimized' video
| player app such as VLC.
| wwalexander wrote:
| mpv has less UI affordances than VLC, but it's very full-
| featured and configurable. It's kind of like the ffmpeg to
| VLC's Handbrake.
|
| Of course, if you really want to be a purist you could use
| ffplay.
| whyoh wrote:
| I switched from VLC to mpv. Mpv loads quicker and is more (CPU)
| efficient. Besides that, I like the minimalist UI.
|
| I think it's worth it, but to get the most out of it, you'll
| need to customize it to your liking (tweaking the OSC, the
| keyboard shortcuts... you can do many things, but it requires
| some reading/searching).
| heraldgeezer wrote:
| The famous VLC seeking corruption still happens to me. Happened
| on an i3 NUC HTPC recently. So using MPC-HC or MPV now
| depending.
| daneel_w wrote:
| In my opinion, yes. It's smaller, simpler, snappier, yet has
| everything and then some under the hood if one really needs
| this or that function.
| miyuru wrote:
| I have a 4k SDR display and 4k HDR content on VLC looks washed
| out.
|
| Mpv does not have that issue and converts 4k HDR to SDR in
| real-time and shows a colorful image.
| jwells89 wrote:
| This has always worked well for me, handling anything that's
| thrown at it with ease.
|
| Things may have changed since then, but when I first encountered
| the project several years ago it seemed like the thing that made
| this project stand out compared to other player projects was a
| big emphasis on correctness and accurate playback. There have
| files I've encountered that for example VLC will play with quirks
| (color reproduction is not quite right, etc) that mpv plays
| perfectly.
| Bluestein wrote:
| > There have files I've encountered that for example VLC will
| play with quirks (color reproduction is not quite right, etc)
| that mpv plays perfectly.
|
| Given how VLC is basically bulletproof and will play absolutely
| anything thrown at it - it's great to hear that mpv is up there
| ...
| mixmastamyk wrote:
| While great in general, vlc has many small seek/sync issues,
| and also seems to be in maintenance mode.
| Bluestein wrote:
| > to be in maintenance mode.
|
| Sad to hear.-
|
| PS. On a tangent, rethorically - baring bugs and security -
| at one point is (if ever) software "finished"?
|
| "We built this search engine. It works. The infrastructure
| has team enough to run it. _But_ we have this huge payroll
| of people. "
|
| So "improvements" and "features" (and constant UI and UX
| changes) ...
|
| ... "enshittification" ensues.-
|
| When is "good enough" ... good enough?
| nine_k wrote:
| A web search engine is never done because spammers never
| cease attempts to.game it in new ways, and because new
| phenomena keep appearing on the web, from presidents
| posting official news on twitter to the proliferation of
| AI-generated texts with subtly incorrect information.
|
| A media player, though, has fewer challenges.
| hollerith wrote:
| Media player projects are in an arms race with exploit
| devs, though, especially since Google keeps introducing
| and popularizing new media formats.
|
| Speaking of which: which project tkaes security more
| seriously, vlc or mpv?
| latexr wrote:
| > PS. On a tangent, rethorically - baring bugs and
| security - at one point is (if ever) software "finished"?
|
| "PS" originates from "post scriptum", meaning "written
| after". It doesn't make sense to have it at the start of
| the text.
|
| But to answer your question, yes, it is definitely
| possible for software to be done and finished. I've done
| it multiple times, where I have built something that does
| _exactly_ what I set it out to do, it does it fast and
| without bugs and has been doing so for years and years
| with zero maintenance needs.
|
| The general obsession with the idea that "software is
| never done, only abandoned" needs to end, it's harmful to
| good software and its users.
|
| Here's millions more examples of finished software, in a
| single word: games.
| Bluestein wrote:
| > The general obsession with the idea that "software is
| never done, only abandoned" needs to end,
|
| My thinking was along those lines. Or at least along the
| lines of "engineering and/or organizational processes
| should exist to know when to stop".-
|
| PS. Thanks for your attention to detail. It was a "PS" to
| an otherwise one-sentence comment.-
| 0cf8612b2e1e wrote:
| What non-maintenance work needs doing? From the outside, it
| plays basically all the formats. There is always the
| potential for improving algorithms, but it strikes me as
| pretty feature complete.
| mixmastamyk wrote:
| > has many small seek/sync issues
|
| Playback issues... scrub problems mentioned elsewhere,
| audio/video get out of sync when seeking a lot; need to
| hit left arrow to reset, speed changes lag when changed a
| lot, when there's a short clip it can end audio early,
| etc, etc.
|
| Not a huge deal, but if you use it every day for video
| and audio file testing/lyric transcribing these little
| bugs get old. The playback core needs a rewrite to be
| "preemptive" I'd guess.
| mixmastamyk wrote:
| Also, https://news.ycombinator.com/item?id=41278499
| d110af5ccf wrote:
| > audio/video get out of sync when seeking a lot
|
| I have a very similar issue with subtitles in MPV
| sometimes. Some unknown (at least to me) combination of
| codec, encoding settings, subtitle format, switching
| subtitle tracks, and seeking will utterly break it to the
| point that I have to exit and reopen the file. I can't be
| bothered to debug the issue (so far).
|
| In general I don't understand the negative comments I see
| VLC get. I've never encountered major problems with
| either piece of software. I've encountered minor bugs and
| annoyances with both.
| mixmastamyk wrote:
| Lots more folks use vlc I'd guess.
|
| The media players we have on mobile don't suffer from
| these issues, so they must be solvable.
| arp242 wrote:
| > There have files I've encountered that for example VLC will
| play with quirks (color reproduction is not quite right, etc)
| that mpv plays perfectly.
|
| This has long since been the case, even back in the MPlayer
| days in the early 2000s.
|
| I'm not really sure why this is the case though, because I
| believe both largely rely on the same libraries for many
| codecs.
| jwells89 wrote:
| The explanation I've read in the past is that the difference
| lies in how VLC was initially focused on playback of video
| streamed over a network (hence the name _Video LAN Client_ ),
| which was generally more rocky a couple decades ago when the
| quality and bandwidth of the average connection was lower and
| the only routes between the client and server could be highly
| indirect or routed through weak nodes.
|
| In that environment, playing at all without constantly
| dropping out or buffering is the goal, which is more
| achievable when fudging accuracy/correctness (which wouldn't
| have been possible anyway).
|
| Not sure how true that is though, it's not something I've
| ever verified.
| loeg wrote:
| Hm, I've had (significant) issues with color representation
| playing back "HDR" media in mpv.
| jwells89 wrote:
| Not something I have experience with so can't speak to that.
| SSLy wrote:
| was the material purple-green by chance?
| loeg wrote:
| Yeah. I did try playing around with some of the colorspace
| options you can find googling, but nothing seemed to work.
| SSLy wrote:
| That's a Dolby Vision Profile 5 file. A format that's
| very very proprietary. The only PC apps that can play
| them at all are
| https://apps.microsoft.com/detail/9p9zh5fl1bfk?hl=en-
| ms&gl=M... and https://firecore.com/infuse
| talliedthoughts wrote:
| Is there a way to use Infuse on PC? The only links I see
| are to the App Store
| SSLy wrote:
| Macs are PC's, you can also make a hackintosh.
|
| EDIT2: if you consider an ARM board that you can install
| custom OS on as a PC - admittedly, bit of a stretch -
| then you can grab UGOOS AM6B plus / AM6 plus / Minix
| u22x-j max
|
| install CoreELEC on it and enjoy DV.
|
| https://github.com/CoreELEC/CoreELEC/releases
| https://discourse.coreelec.org/t/dolby-vision-for-
| minix-u22x... Recommended settings:
| https://justpaste.it/divn9 Installation instructions 1:
| https://discourse.coreelec.org/t/guide-s922x-j-ugoos-
| am6b-co... Installation instructions 2: https://www.reddi
| t.com/r/PleX/comments/1ajszn9/remux_lovers_...
|
| EDIT: I forgot that for Windows playback, you also need
| the HEVC and DoVi codec packages.
|
| https://apps.microsoft.com/detail/9P9ZH5FL1BFK
| https://apps.microsoft.com/detail/9PLTG1LWPHLF
| https://apps.microsoft.com/detail/9nmzlz57r3t7
| literallycancer wrote:
| You can play it with mpv, it depends on the
| hardware/drivers. It worked fine on a random Ryzen Lenovo
| laptop with Linux even though MacOS version of mpv
| couldn't play it correctly on M2 (even though Apple
| claims that M2 is compatible with the format).
| SSLy wrote:
| And you're sure it was a Profile 5, not 7/8 file?
| daneel_w wrote:
| It depends on what format/decoder support went into your
| particular build of mpv. It offloads almost all of its
| capabilities onto ffmpeg and its supporting libraries,
| which in turn won't necessarily be built with exactly
| everything enabled.
| FabHK wrote:
| Infuse is great. I use it to play stuff (in basically any
| format) from the NAS through the Apple TV on a dumb TV.
| adrian_b wrote:
| Nowadays mpv is able to decode it correctly, but it
| usually requires for that the command-line option "--
| vo=gpu-next".
|
| A couple of years ago, mpv was unable to handle it.
| emestifs wrote:
| Try this in your mpv.conf file no-
| config target-trc=pq target-prim=bt.2020
| vo=gpu-next
|
| Wont be 100% accurate, but hopefully somewhat watchable
|
| See also https://github.com/mpv-player/mpv/issues/10122
| loeg wrote:
| Still very green/purple. It's fine, I was able to find a
| non-HDR version.
| adrian_b wrote:
| Then you probably have either a very old mpv or one that
| was compiled without including the "gpu-next" video
| output driver.
|
| Or else the GPU drivers for your GPU card have not been
| updated for a very long time.
|
| A recent mpv and recent GPU drivers should solve this
| problem, because it was frequently encountered only up to
| a couple of years ago.
| loeg wrote:
| mpv 0.36.0 from July 2023, nvidia 555.58.02 drivers from
| August 2024 (Fedora 39).
| Narushia wrote:
| I would try updating to 0.37.0 or 0.38.0, IIRC it only
| started to work for me after I updated to one of those (I
| always build mpv from the latest commit myself, so I'm
| not sure which release version exactly has the crucial
| fixes).
| adrian_b wrote:
| My output of "mpv --version": mpv 0.38.0
| Copyright (c) 2000-2024 mpv/MPlayer/mplayer2 projects
| libplacebo version: v6.338.2 FFmpeg version: 6.1.1
|
| I do not remember which was the first version that worked
| fine. For some time, "gpu-next" was not included by
| default in the releases, but you had to compile a custom
| variant to include it.
|
| Pay attention that "libplacebo" is required. If
| libplacebo is absent, then the Dolby Vision conversion
| will not work. This could be the reason of your problem,
| if your Linux distribution does not have libplacebo as an
| automatic dependence of mpv, or if mpv has been compiled
| without support for libplacebo.
| adrian_b wrote:
| I believe that the target primaries must be those of your
| monitor.
|
| BT.2020 are the primaries used to encode the HDR movie.
|
| Monitors with such primaries are rare and extremely
| expensive. For most good monitors "--target-prim=dci-p3"
| should be appropriate, if DCI-P3 has already been
| selected from the on-screen monitor configuration menu,
| because most monitors come configured by default to use
| the ugly sRGB color space, so you must change the
| defaults to be able to display content with bigger color
| spaces.
|
| Some monitors might have the option to use the BT.2020
| color space, when they would still not be able to display
| all of it, but they would do internally the conversion
| between the BT.2020 used to encode the movie and whatever
| color space the monitor can actually display.
| adrian_b wrote:
| Then you must have not used "mpv --vo=gpu-next".
|
| Playing HDR and Dolby Vision encoded movies has been solved a
| long time ago in mpv, but they usually need the option shown
| above, which may not be the default on your system.
|
| There are plenty of additional options in mpv that provide a
| finer control of how HDR colors are handled.
|
| While playing a movie with mpv, press "I", so that mpv will
| display the information it has about the color space
| supported by your display and the color space used in the
| movie, which will allow you to verify if they are correct.
| loeg wrote:
| I have used vo=gpu-next, actually. Still green/purple.
|
| "I" shows: Primaries: bt.2020. Colormatrix: bt.2020-ncl.
| Levels: full. If that means anything.
| adrian_b wrote:
| "I" must show two sets of "Format: Levels: Colormatrix:
| Primaries: Transfer:", one set for "Display:" and one set
| for "Video:".
|
| "mpv" or any other player must make a conversion from the
| color space used for encoding the video file to the color
| space supported by the monitor. A monitor that has not
| been reconfigured after the initial installation is
| likely to use the sRGB color space. Any good monitor
| should have a configuration menu that allows the
| selection of a better color space, but mpv can convert
| BT.2020 to sRGB, if necessary (which will reduce the
| saturation of many colors).
|
| Did mpv print after being launched a line starting with
| "VO: [gpu-next]"?
|
| Where "gpu-next" is not available, mpv will start anyway,
| but it will use one of the other video drivers, none of
| which convert correctly Dolby-encoded video.
|
| On the computer where I normally play HDR/Dolby Vision
| movies, I use an NVIDIA GPU, so I know for sure that gpu-
| next works fine with it.
|
| I do not remember whether I have played any HDR/Dolby
| Vision movie with an AMD or Intel GPU, but I doubt that
| any of those is incompatible with gpu-next.
|
| In any case, if mpv prints "VO: [gpu-next]" without any
| error message and if "I" shows for "Display:" the correct
| color space supported by your monitor, e.g. sRGB or
| DCI-P3, then you should try to upgrade the GPU driver,
| which could be too old. Like I have said, IIRC this
| problem has been solved in 2022 and since then I have
| never encountered again color conversion errors, so you
| must have some software component that is older than
| 2022.
|
| Because my monitor is configured to use the color space
| DCI-P3 (with 10-bit colors), I alias "mpv" to "mpv='mpv
| --vo=gpu-next --target-prim=dci-p3'", and it has been
| working fine for the last two years, including with any
| HDR and/or Dolby Vision movie.
| ailurooo wrote:
| i used to be able to go frame by frame with quicktime.. is there
| any modern video player that can actually do this?
| thegeomaster wrote:
| mpv does it! Period key (.) for next frame, comma (,) for
| previous. Super handy.
| amlib wrote:
| You can also hold those keys to play normally at the speed
| set with [ and ], so you can actually play the video in
| reverse and slow motion or whatever. Be aware that it's
| usually very intensive on cpu time (and maybe gpu decoding if
| applicable) since it has to usually go back a whole keyframe
| and compute all frames between while doing that, which may
| result in less than smooth playback on some videos.
| chungy wrote:
| Reverse usually works significantly worse, at least with
| common video codecs that work on key frames and
| intraframes. Depending on your work flow, codecs that don't
| operate on keyframes/intraframes will actually provide mpv
| the capability of playing backwards at full speed (eg:
| rawvideo, ffv1, magicyuv...).
| entropie wrote:
| This is a build in feature that mplayer had and mpv has aswell
|
| . and , on keyboard go frame-to-frame, you can also up and
| downspeed with [ and ]
| righthand wrote:
| Offtopic: vlc too
| pferdone wrote:
| only next frame
| entropie wrote:
| I started to use it on linux a few years ago.
|
| Now its on every device, even on my android tablet. Its perfect.
| Minimalistic, sane defaults, fast and just works.
|
| It can even play natively over ssh. Its awesome
|
| > mpv sftp://mit@nyx/home/mit/Work/merged.mp4
|
| Recently I needed a hotkey to rotate a video (which seems not
| like any player can _easily_ do this; for mpv it was a 'r
| cycle_values video-rotate "90" "180" "270" "0"' in the in
| input.conf)
| ivanjermakov wrote:
| You can also play videos over http, many websites are
| supported, even YouTube: mpv <yt link>
| vocx2tx wrote:
| It uses yt-dlp as the download backend, so it works with
| anything that yt-dlp handles.
| nagisa wrote:
| I have found this not to be as straightforward as this. In
| particular:
|
| 1. Although `yt-dlp` consistently is able to download
| videos at link speed (even when the said link is in multi-
| gig range!), streaming the video through `mpv` will not
| work as well and some videos would buffer every couple
| chunks. But that was in the past...
|
| 2. With recent changes to how videos are served and
| "protected", I'm still able to download them with recent
| versions of `yt-dlp`, but streaming a `yt-dlp` generated
| playlist will reliably fail to work (this is true for the
| newpipe android app too.)
|
| 3. Even back when streaming youtube worked, closed captions
| and other such features would not work by default.
|
| I download videos first, nowadays. And then play them with
| mpv anyway.
| mtlmtlmtlmtl wrote:
| For 1, there might be settings that can help.
|
| I used to use mplayer(of which mpv is a fork) to watch
| pirate streams of premier league games several years ago,
| via acestream. Since this was live, lag was a real issue;
| you can't buffer ahead when there's nothing to buffer
| yet. Eventually I figured out that mplayer had settings
| to do things like buffer for 2 minutes at the beginning
| of the stream before playing. You could also configure it
| by megabytes pre-buffered. This solved my lag issues very
| neatly. I can't remember what the settings were, it's
| been a long time and I don't have those config files
| anymore. But it should all be in the docs somewhere.
| stebalien wrote:
| Try setting `ytdl-format=ytdl` in `mpv.conf`, that fixed
| it for me.
| account42 wrote:
| > 1. Although `yt-dlp` consistently is able to download
| videos at link speed (even when the said link is in
| multi-gig range!), streaming the video through `mpv` will
| not work as well and some videos would buffer every
| couple chunks. But that was in the past...
|
| I still get this with YouTube from time to time. Works
| with some videos, others are unwatchable. Seeking also
| generally seems broke and is often slower than
| downloading even the whole video.
| EffrafaxOfWug wrote:
| I think the issue with buffering on some videos is
| because of bad DASH support https://github.com/mpv-
| player/mpv/issues/7033
| account42 wrote:
| I wish seeking word work better in this mode though. There is
| no reason seecon should freeze the player for minutes or
| indefinitely if the whole video can be downloaded from start
| to finish in seconds.
| ivanjermakov wrote:
| I agree. With decent bandwidth it's more convenient to
| first download video with yt-dlp and then play it with mpv
| coppsilgold wrote:
| MPV has versatile scripts. For example you can cut and crop a
| video you are watching[1].
|
| You can also introduce hotkeys for functionalities I have never
| seen in another player.
|
| I use this (input.conf) sometimes to normalize the brightness and
| colors of a scene I'm watching (may not work when using hardware
| decoding): n vf toggle normalize=smoothing=100
|
| Or rotate a video: Ctrl+r no-osd cycle-values
| video-rotate "90" "180" "270" "0"
|
| [1] <https://github.com/occivink/mpv-scripts>
| sweeter wrote:
| it also has a robust Lua scripting interface. I made a tool in
| Golang and Lua that allows Mpv to treat torrent files and
| magnet links as if they were http links. You can then stream a
| torrent directly.
|
| People also don't realize that mpv not only has the ability to
| stream youtube videos but you can also search youtube on the
| CLI using mpv `mpv ytdl://ytsearch:query`
|
| it can also play videos directly in the terminal using ascii,
| sixel or kitty image protocol (which is by far the highest
| quality)
| abhishekjha wrote:
| Do you have an example?
| ftk_ wrote:
| Not OP but also wrote a similar thing for mpv.
|
| https://github.com/ftk/mpv-confluence/tree/torrserver
| Bluestein wrote:
| > I made a tool in Golang and Lua that allows Mpv to treat
| torrent files and magnet links as if they were http links.
| You can then stream a torrent directly.
|
| Increible. Consider putting this up somewhere folks can find
| it.-
|
| > it can also play videos directly in the terminal using
| ascii
|
| Beats Star Wars over telnet :)
| 369548684892826 wrote:
| There are lua hooks for play/pause/stop which is great for
| dimming room lights when the video starts.
| tvshtr wrote:
| it's crazy what you can do with its plugin scripts. MPV
| Android also supports them. I wrote one which turns off
| keyboard backlight and maxes brightness for HDR.
|
| Also I'm using it to stream from Gerbera and to sync progress
| seamlessly between phone and PC.
| Madeindjs wrote:
| I personally use MPV to play my music libraries containing
| mainly FLAC file and I wrote a plugin [1] using JS to send my
| listens to listenbrainz.org . It's damn simple, but it worked
| for the past few months!
|
| [1]:
| https://gist.github.com/madeindjs/f33225cf4d8fdc9f61e0fe3ebe...
| blfr wrote:
| The best media player in existence: superb minimalist UI, makes
| use of hardware accelaration, and just plays videos.
|
| Its continued excellence is one of the reasons why I will
| probably remain a pirate for life. Streaming services spend
| millions on their players and don't come close.
| FabHK wrote:
| It seems to me that YouTube cripples their web player on
| purpose to "entice" you to download their app and upgrade to
| premium.
| kjkjadksj wrote:
| All it does is entice me to avoid that and go to mpv
| blfr wrote:
| I have YouTube ReVanced, which is better than premium, which
| is still not as good as mpv.
|
| Other services are strictly premium, paid affairs. Still not
| as good as mpv.
| factorialboy wrote:
| Goat
| etra0 wrote:
| A fantastic mediaplayer, quite minimalistic and performant; it
| does what it's supposed to do!
|
| Also has a fantastic commit where the author rants about locales:
| https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
| worth a read for some chuckles.
| beagle3 wrote:
| A long, informative read, with some profanities. Highly
| recommended!
|
| 25 years ago, Spolsky wrote an article called "everything you
| wanted to know about Unicode and character sets". Those of you
| who only lived in the post Unicode/UTF world might find that
| one informative as wel.
| josephg wrote:
| As strange as it is to say, I think avoiding problems like this
| might be one of the biggest productivity boosts from new
| languages like Go, Rust, Swift, etc. New ecosystems get a
| chance to "do over" the standard library and flush all the
| horrible legacy choices made before we knew better (locales,
| UTF16, etc).
|
| The standard library in Zig, Go, Rust, and many others is miles
| ahead of the C standard library or posix api. That is reason
| enough to use them.
| bbarnett wrote:
| I'm skeptical that rust magically deals with, for example,
| character sets in 30 year old subtitle files, in a way that
| makes C seem inadequate.
|
| Legacy compatibility has value.
| Dylan16807 wrote:
| The correct place to handle character sets is when you're
| reading the file, not to sprinkle it all throughout your
| program.
| josephg wrote:
| Right. And the rust standard library provides (in my
| mind) the right API for this. Strings are always
| internally utf8. But they have constructor methods to
| create strings from UTF16 bytes, or utf32 or whatever.
|
| Rust isn't unique. Swift, Go and Python3 all expose more
| or less the same api. C's standard library, with the
| benefit of hindsight, is uniquely terrible here.
| nine_k wrote:
| Locales are so much more than character sets. E.g. an
| Arabic locale changes the direction of writing, it also
| changes the characters used for numbers, and completely
| changes the way numbers and dates are formatted. This is
| where the C locale functions are problematic.
|
| Character encoding is the easy and safe part.
| Dylan16807 wrote:
| Locales _are_ much more than character sets, but the
| question was about character sets.
|
| Also for most of those things, you want to be explicit
| about when to use the locale and when to not.
| josephg wrote:
| > Also for most of those things, you want to be explicit
| about when to use the locale and when to not.
|
| Right. And that's where the POSIX C API falls down. The
| locale isn't named explicitly. Its not a function
| parameter. Its specified via a global variable that gets
| shared between all your threads.
|
| You might think you can use scanf to parse a string in a
| JSON file. It might appear to work fine on your local
| computer. But scanf behaves differently depending on the
| system locale. You can wrap scanf with a helper function
| which sets the locale to something sensible, calls scanf,
| and restores the locale. But because the locale is shared
| with other threads, which might be depending on the
| locale in other ways. So this can introduce race
| conditions.
|
| The whole thing is horribly designed - and it leads to
| buggy, unreliable code that is hard to reason about. Even
| in the best case, introducing thread syncronization into
| a function like sscanf will lead to a dramatic decrease
| in performance.
|
| Its horrible. Just horrible.
| duskwuff wrote:
| > I'm skeptical that rust magically deals with, for
| example, character sets in 30 year old subtitle files, in a
| way that makes C seem inadequate.
|
| It's not just that C is "inadequate" - C and its standard
| library provide no assistance in that task. As the mpv
| author explains in profane detail in the linked commit
| message, POSIX locales are an active hindrance, not a
| useful form of "legacy compatibility".
| commodoreboxer wrote:
| Not "magically", but more reasonably and without forcing
| your entire program into a different state, breaking any
| ability for libraries to work with a huge range of
| functionality consistently. C locale handling is basically
| impossible to work with robustly, even before you get into
| how it can't be effectively used at all in a thread safe
| way.
| account42 wrote:
| You can create/use a different string processing library
| without jumping to a completely different language.
| efilife wrote:
| > All in all, I believe this proves that software developers as
| a whole and as a culture produce worse results than drug
| addicted butt fucked monkeys randomly hacking on typewriters
| while inhaling the fumes of a radioactive dumpster fire fueled
| by chinese platsic toys for children and Elton John/Justin
| Bieber crossover CDs for all eternity.
|
| This was a great read
| telegtron wrote:
| Loved the last paragraph of the long, justified rant.
| Hilarious:
|
| "All in all, I believe this proves that software developers as
| a whole and as a culture produce worse results than drug
| addicted butt fucked monkeys randomly hacking on typewriters
| while inhaling the fumes of a radioactive dumpster fire fueled
| by chinese platsic toys for children and Elton John/Justin
| Bieber crossover CDs for all eternity."
| racked wrote:
| I actually thought that last paragraph really undermined his
| case, because rather than substantiating like he did before,
| here he goes all out and just insults whoever he can think
| of; people who take it in the ass, greybeards, the Chinese,
| listeners of bland music...
|
| I get him though. It's one of those writings from a foul
| mood. There was probably more going on in his life than some
| trouble dealing with locales.
| simoncion wrote:
| > ...here he goes all out and just insults whoever he can
| think of...
|
| No, he observes that software devs as a group, and as a
| culture tend to produce worse results than incredibly-
| distracted and certainly-fatally-intoxicated simians
| banging on typewriters.
|
| It's a bit of hyperbole, but the overall state of software
| is absolutely dire.
|
| > ...the Chinese, listeners of bland music...
|
| In some-to-much of the world, it's pretty well-known that a
| lot of cheap crap (much of which has historically been made
| in China) is very shoddily made and fairly quickly finds
| its way to the landfill. One shouldn't confuse criticism of
| shoddily-made products for criticism of the citizens of the
| country of origin of said products.
|
| I'd also expect the referenced (certainly entirely-
| hypothetical) CD to be something that ends up getting
| thrown into the dumpster in huge numbers because store
| inventory managers expect it to be WAY more popular than it
| actually ends up being. Also, see above about not getting
| confused about what the target of the insult is. ;)
|
| > There was probably more going on in his life than some
| trouble dealing with locales.
|
| _shrug_ Not everyone chooses to write in sterile $DAYJOB-
| approved language when explaining in detail the root of
| their frustration with the absolutely bullshit garbage pile
| they have to build upon for their non-corporate side
| project.
| racked wrote:
| > No, he observes that software devs as a group, and as a
| culture tend to produce worse results than (...)
|
| Yeah, to that I say "meh". Maybe. In my view, on a
| different day he would have hacked in a workaround,
| explained quickly that it is because of the illogical
| locale system, cited a few sources and moved on with his
| life. Sure, man-made stuff is a mess. Nothing's ever
| perfect. But stuff's particularly not perfect when you're
| in an absolutely foul mood.
|
| It's unconstructive to entertain the thought that
| software in general is awful. A waste of energy. Reading
| his rant, I just think "improve it and move on"!
|
| > One shouldn't confuse criticism of shoddily-made
| products for criticism of the citizens of the country of
| origin of said products.
|
| Yeah, fair enough. There's different ways to interpret
| it. Maybe a proud modern Chinese person would be mildly
| offended by it. No biggie, the point was: in the last
| paragraph, he's firing a machine gun. A full release of
| rage.
|
| > Not everyone chooses to write in sterile $DAYJOB-
| approved language
|
| Of course. It feels great to talk bad when you're in a
| shit mood. I don't know about you though, but the next
| day I usually wish I'd just kept my cool. :-)
| stavros wrote:
| > much of which has historically been made in China
|
| The "Chinese crap" argument fails to realize that yes,
| all cheap crap is made in China, because _everything is
| made in China_.
|
| Nobody looks at an iPhone and says "ugh, Chinese crap".
| thayne wrote:
| > Imagine they had done this for certain other things. Like
| errno, with all the brokenness of the locale API.
|
| They did. See for example time functions like localtime (and
| localtime_r) and tzset. It is admittedly locale adjacent, since
| it depends on the locale. But the time zone is _also_ global
| state, so it is impossible to get the time in a different
| timezone with standard apis in multi-threaded portable (for
| posix) c code.
| ptdorf wrote:
| Oh man! This was GOLD. Thanks.
| yard2010 wrote:
| > Both C locales and wchar_t are shitfucked retarded legacy
| braindeath. If the C/POSIX standard committee had actually
| competent members, these would have been deprecated or removed
| long ago. (I mean, they managed to remove gets().) To justify
| this emotional outbreak potentially insulting to unknown
| persons, I will write a lot of text. Those not comfortable with
| toxic language should pretend this is a religious text.
|
| What a legend.
| codedokode wrote:
| Wow that comment is so educating. I guess I'll pay more
| attention now to standard functions I use in C code.
|
| As for weirdness of C standard, I guess it is because they
| wanted to make it compatible with obscure proprietary platforms
| which might not even exist anymore.
| Narushia wrote:
| Worth noting that the author of that commit has not been
| associated with mpv development in years.
| account42 wrote:
| Which is a shame because he's highly techinally competent.
| thegeomaster wrote:
| Joining the praise in this thread. Extremely reliable, fast,
| versatile, plays anything.
|
| What I haven't seen mentioned is that it has 1- or 2-key keyboard
| shortcuts for almost everything, down to adjusting audio/video
| delay, subtitle size and offset, etc etc.
|
| Once you've had the experience of adjusting the video just how
| you like it in 5 seconds with a series of keypresses without
| having to pause or disrupt the playback, you'll never want to go
| back.
| Bluestein wrote:
| It feels like the "Vim" of video players.-
| palata wrote:
| I have been using mpv on Linux for like 10 years, it's simply
| amazing. No complaint, it just works.
|
| Highly recommended.
| iLemming wrote:
| What's cool that you can control it from your editor. It feels so
| nice managing YouTube video playback from Emacs, makes the note-
| taking so easy. elfeed-tube/elfeed-tube-fetch command lets you
| follow the transcript, while ignoring commercial bits. You can
| basically search through the text and play it from that point.
| Agingcoder wrote:
| I didn't know mplayer had been forked - this looks good to me.
| The primary reason why I used mplayer in the early 2000s was
| performance, both in terms of cpu and for lack of a better word '
| smoothness '.
|
| Basically all other players seemed to produce choppy videos (
| including regular dvd players ) but mplayer didn't ( and there
| was no motion interpolation). A friend of mine told me that
| mplayer was very accurate ( ie each frame lasted exactly the same
| duration), unlike most players on the market at the time and this
| explained the 'smooth' feeling.
|
| Is this smoothness advantage still the case ? Would anyone know
| why it felt like that years ago ?
| jcelerier wrote:
| It's impossible for video players to be exactly accurate on
| normal monitors as most computer monitors don't handle movie
| frame rates. Either a frame gets skipped or elongated here and
| there, audio get resampled while video speed changes, etc. but
| there's definitely no silver bullet due to imperfect hardware
| not matching movie data formats
| globular-toast wrote:
| A lot of monitors these days support a kind of variable
| refresh rate like Freesync, so this should be possible. I've
| never actually got it to work with AMD, Linux and mpv,
| though.
| loeg wrote:
| It's relatively easy to get 100us level precision in CPU wait
| and mpv has 42ms (42,000us) to emit each frame (at 24fps).
| Nevermind that the monitor refresh is likely 60fps or better
| so each frame lasts for two+ monitor frames anyway. As long
| as it is consistent with each frame timing it should be very
| rare that a video frame is skipped or doubled up.
| globular-toast wrote:
| Frames shouldn't be skipped but if the monitor is at 60Hz
| and the video is at 24 then many frames will have to come
| early or late. That's what causes the stutter that is most
| apparent on slow planning scenes. It's like the reel in the
| projector is being fed through in a jerky manner so each
| from lines up with one of the monitor frames rather than
| going through at constant speed like it's supposed to.
| There's no way around this. However with 120Hz monitors you
| just display one frame every 5 frames and no jerky motion
| is required (except the fact that US releases are at
| 23.976fps, not 24, so a frame will have to be doubled every
| now and then I guess, or maybe the soundtrack is just
| pitched up to 24? Don't know).
| loeg wrote:
| I don't think frames coming at most 8.3ms early/late are
| perceptible, much less "jerky."
| globular-toast wrote:
| It is perceptible and it is jerky.
| jcelerier wrote:
| I concur, it's definitely noticeable
| jcelerier wrote:
| The CPU computation time is definitely not a problem, the
| fact that 60/24 (or sometimes 23.97) is not an integer is
| ac29 wrote:
| 48hz support seems pretty common.
| jcelerier wrote:
| Is it ? I had dozens of monitors and never saw it
| namibj wrote:
| Just set it, it works.
| Dylan16807 wrote:
| 120Hz screens are good enough here that I'd call them a
| silver bullet.
| Dylan16807 wrote:
| That can't be it. The circuit outputting video onto the wire
| triggers every 1/60th of a second, always the same duration.
|
| There are situations where a player could time things so badly
| an entire frame has to be skipped, but that shouldn't happen
| often. And it should basically never happen on a regular DVD
| player. Any variations smaller than that disappear; whether a
| frame is ready 15ms before the deadline or 1ms before the
| deadline has no impact on the output.
| lysace wrote:
| The primary reason that many of us still used MPlayer 20 years
| ago was that it did keyboard-based seeking really well. Nothing
| fancy, just look for the closest I-frame from the target time
| and move exactly there.
|
| This art of quick seeking sort of got lost in time as the
| distance between UX people and people who understand
| H.264/265/etc in detail grew.
|
| On Apple TV: At best it takes like 500 ms. At worst (the Max
| app), like 6000 ms.
|
| MPlayer 20 years ago: 17 ms.
| t-3 wrote:
| My favorite thing about mpv is that it works under the console
| using framebuffer or drm. This can be used with configuration or
| scripting for image viewing, reading pdfs, and more without
| needing needing a lot of specialized tools, especially on non-
| linux platforms where graphical framebuffer tools aren't
| available. Tmux +(e)links + mpv can nearly completely obviate the
| need for a graphical environment and removes a lot of distracting
| things from view.
| HPsquared wrote:
| Can it do smooth scrubbing (i.e. scrolling the progress bar)?
|
| So many media players only show the key frames when scrubbing,
| making it a much less pleasant experience. Some mobile phones
| (Apple, Samsung) built-in media players seem to do it nicely, but
| I've never found a desktop media player that does it (VLC can't).
|
| Probably would require a lot of extra decoding behind the scenes
| to extract all the frames, but worth it on a modern machine.
| arp242 wrote:
| I don't really know what "scrubbing" is, but If you add "exact"
| to seek then it will use exact (non-keyframe) seeks. I think
| that's what you want? For example from my input.conf:
| Right seek 5 # In seconds; these
| are limited by keyframes Left seek -5
| Shift+Right seek 2 exact # Smaller non-
| keyframe-limited, seeks with shift Shift+Left seek
| -2 exact
|
| Obviously, this is slower. Sometimes much slower (depending on
| the file).
| latexr wrote:
| > Obviously, this is slower. Sometimes much slower (depending
| on the file).
|
| Anecdotally, I'd change that "sometimes" to "often". After
| years of using `exact` I finally stopped. It always felt that
| the wait was longer than going to the previous keyframe and
| rewatching the bit. Now if I could only find the perfect
| timing to go back, though.
| arp242 wrote:
| A lot of stuff I watch is 720p, and it's okay with that.
| But with some types of higher quality files it can be
| (very) slow.
|
| That said, I have replaced most of my "exact seeks" with
| "sub-seek"; in input.conf: Alt+Right
| sub-seek 1 # Go to next/previous sub (within demuxer-
| readahead-secs) Alt+d sub-seek 1
| Alt+Left sub-seek -1 Alt+a sub-
| seek -1
|
| And then in mpv.conf: demuxer-readahead-
| secs=120 # sub-seek only works within this cache
| demuxer-hysteresis-secs=60 # Fill cache only if lower
| than this; saves battery
|
| This allows me to fairly quickly skip past stuff that's not
| too interesting, while still actually following the gist of
| what's going on.
|
| I think it's also bound by default, but I'm not sure what
| that is from the top of my head. You'll definitely need to
| set that cache as it's only 2 seconds or so by default.
| Tmpod wrote:
| I don't believe the scrollwheel works to seek video, not sure,
| but MPV can go frame by frame. It's bound to the keyboard by
| default, but you can tweak your config and bind it to the
| scrollwheel.
| LukeShu wrote:
| By default, mpv has vertical-scroll bound to volume and
| horizontal-scroll bound to scrubbing.
| loeg wrote:
| Outside of low bitrate streaming (youtube), most media has
| sufficient keyframes (I frames) that this distinction really
| doesn't matter. I don't know what mpv does, though.
| Numerlor wrote:
| Yes, you have to turn it on through hr-seek=yes but then you
| can seek arbitrarily; great when I have to quickly step through
| something but not actually miss anything.
|
| For the scrolling you can bind smoething like a .1s seek to the
| wheel
|
| https://mpv.io/manual/master/#options-hr-seek
| zamubafoo wrote:
| Yes, though you do have to enable that. For me I tend to have
| it buffer the video. That way I can even seek backwards of web
| streams.
| gioo wrote:
| mpv is awesome. Shout-out, in no particular order, to:
|
| - Seeds of Might/JySzE's base `mpv.conf`[1]
|
| - uosc, a feature-rich but still minimalist UI[2]
|
| - thumbfast, a fast thumbnailer to be used with uosc or another
| custom UI[3]
|
| - Eisa01's SmartSkip, which allows to skip intros & more (audio-
| based)[4]
|
| [1] Windows:
| https://gist.github.com/JySzE/db4149cad726b3b6955dca8d47a197...,
| macOS:
| https://gist.github.com/JySzE/34ee131da3974811a9469e1e3b7d4d...
| [2] https://github.com/tomasklaen/uosc [3]
| https://github.com/po5/thumbfast [4]
| https://github.com/Eisa01/mpv-scripts#smartskip
| Cyph0n wrote:
| Not to take away from the work done on the plugin, but that's a
| "basic" skip intro implementation.
|
| To reliably be able to find intros/credits, you need to some
| non-local analysis - basically, you need to look for common
| chunks of audio across episodes in a season or entire show.
|
| I wrote a CLI tool that can do this, albeit it's not really
| "finished" and probably will never be. My initial goal was to
| use it to develop a Jellyfin plugin, but then I discovered that
| there was already such a plugin :)
|
| https://github.com/aksiksi/needle
| tbeseda wrote:
| If anyone is looking for the mpv core with a GUI on macOS, take a
| look at IINA https://github.com/iina/iina
| radicality wrote:
| It's also the only way I can play HDR on macOS that looks
| decent (besides the native players like
| QuickLook/Quicktime/Photos).
|
| I went into a rabbit hole recently playing iPhone-recorded
| Dolby hdr videos and tweaking all the various mpv settings but
| nothing really looked the same as in Photos. Iina is closer but
| also not exactly the same as the native players.
| SSLy wrote:
| infuse will also do good job, but it's using apple engine
| instead of ffmpeg, and it's paid for the good stuff
| https://apps.apple.com/us/app/infuse-video-
| player/id11362209...
| galad87 wrote:
| iPhone-recorded Dolby Vision videos uses an additional
| metadata called "Ambient Viewing Environment", and I don't
| think any third-party player supports it at the moment.
|
| https://developer.apple.com/documentation/technotes/tn3145-h.
| ..
| arch1t3cht wrote:
| IINA has issues with color space conversions. I've heard that
| the specific issue is that it always (incorrectly) assumes a
| BT601 matrix for all videos, though I haven't verified it
| myself and cannot really right now. (I did verify its colors
| differing from stock mpv before writing this comment, though.)
| Various mpv wrappers exists, but for reasons like these stock
| mpv is the only fully reliable version.
| yborg wrote:
| Huh, that explains it, I was wondering why I was having
| problems with some video that VLC would even playback
| correctly, I didn't think to try the stock mpv.
| ksec wrote:
| Have you filled a bug report about this?
| latexr wrote:
| I'm not the person you asked, and I don't have that issue,
| but this common trend of replying to any criticism with
| "have you filed a bug report?" rubs me the wrong way.
|
| I have opened detailed issues on IINA which describe a bug,
| how to reproduce, and the correct behaviour (according to
| their own docs), and they've just sat there unacknowledged
| for years.
|
| IINA's issue count is _twice as big_ as mpv's, despite
| being a UI covering a single OS. Personally I don't think
| it's worth it over vanilla mpv, which I've recommended even
| to non-technical users who like it.
| ksec wrote:
| I fully understand your frustration, as this is what I
| felt about many other projects.
|
| But surprisingly it was only IINA that got my problem
| fixed when I reported it with how to reproduce and
| correct behaviour. Hence why I asked if he had filed any
| bug report.
| arch1t3cht wrote:
| Admittedly I have not, but I did search for and find
| similar issues on their github before making this comment,
| and I do plan to investigate this more one day and possibly
| make a proper issue. There are indeed a lot of "X tool is
| broken because of Y" statements of varying credibility
| floating around in the multimedia community where it's
| unclear if they were actually ever reported upstream or
| even double-checked recently (people still claim that VLC
| uses nearest-neighbour chroma scaling, for example, but
| that's no longer true (except for screenshots, it's still a
| problem there)), and that is something I'm trying to work
| against by investigating and reporting this when I can. But
| since I don't use IINA myself and since, as another
| commenter pointed out, IINA bug reports don't seem to get a
| lot of responses on average, it hasn't been the highest
| priority for me.
| morphle wrote:
| mpv is always faster than IINA, especially with 4K playback on
| older MacOS. mpv is near perfect
| matricaria wrote:
| On macOS there is IINA which uses mpv under the hood but with a
| more native GUI.
| Venn1 wrote:
| If you're on Linux, don't forget to enable hardware acceleration
| by adding hwdec=auto to mpv.conf. Works with AMD/Intel/NVIDIA.
|
| https://interfacinglinux.com/2024/01/10/hardware-acceleratio...
| synergy20 wrote:
| great to know this. thanks!
| NavinF wrote:
| Why would that be disabled by default?
| diggan wrote:
| Doesn't work on all systems, I presume. Better to default to
| something that definitely works everywhere.
|
| https://github.com/mpv-
| player/mpv/blob/a3baf94ab9f3b43a8027d...
|
| Would be appropriate to have true/false/auto instead of
| auto==true though, so auto wouldn't use it unless it
| confirmed to be working.
| crossroadsguy wrote:
| Because if you don't have to enable a flag or two in a text
| config file what's the fun of using Linux after all :)
| brettermeier wrote:
| Hahaha yeah, that's why I don't like it.
| varenc wrote:
| In addition to what others have said, hardware decoding comes
| with other drawbacks. There's occasionally decoding
| inaccuracies and there's no support for most video filters
| (unless you're using `auto-copy`)
| tvshtr wrote:
| Try watching UHD HDR on intel iGPU without accel, or AV1.
| MPV also supports vulkan decoders.
| radicality wrote:
| Do you know if/why on apple silicon Macs there's a
| difference between videotoolbox and videotoolbox-copy ? I
| thought the SoC memory is shared and that there wouldn't be
| a need for copying data from VRAM to RAM.
| krzys wrote:
| If you autodetect hw accel, even the slowest underpowered gpu
| might get returned, which could result in worstened user
| experience compared to just using cpu.
| IshKebab wrote:
| Just do a quick automatic benchmark surely?
| mzajc wrote:
| It breaks on suspend-to-memory for my system with a nVIDIA
| GPU. I assume that's a driver problem, though.
| shmerl wrote:
| I do it like this: vo=gpu-next gpu-
| api=vulkan hwdec=vulkan gpu-context=waylandvk
|
| You can replace hwdec=vulkan with hwdec=vaapi if Vulkan video
| doesn't work.
| vladvasiliu wrote:
| Is there a reason why one would prefer vulkan over vaapi, or
| the other way round?
| shmerl wrote:
| Vulkan in theory should be more flexible, but in practice
| VAAPI still has some advantages when it comes to power
| efficiency due to Vulkan path lacking some needed features
| (I think something to do with color space conversions which
| in Vulkan now have to happen using regular GPU compute
| units which is inefficient). In the longer term, Vulkan
| should be preferable in all scenarios.
|
| See also some details here: https://github.com/mpv-
| player/mpv/discussions/13909
| troad wrote:
| Huh. Apparently I've been watching videos on mpv for years
| without HW acceleration. Good thing I read this; thanks!
| nijave wrote:
| Not sure why but I've had lots of issues with worse performance
| (lagging/stuttering) on Fedora (I think kernel 6.10) with a
| Vega 64. Every year or so I'll give it a try and it just won't
| work well and I give up again.
| steelframe wrote:
| Yeah, I just pacman-installed mpv and tried running it on a 4k
| video. My CPU fan immediately kicked on, and top showed
| multiple cores getting involved. Kept scrolling this HN post to
| learn about hwdec=auto. Coming from mplayer and vlc my
| immediate question is, "What tradeoffs are the maintainers
| trying to make by not making this the default?"
| adamomada wrote:
| Mac users can get a very nice front end to mpv with
| https://iina.io
|
| Bonus trivia: Plex Media Player uses mpv as the video player
| causality0 wrote:
| That is... not a glowing endorsement. I've had more bugs and
| player failures from Plex than any other media software I've
| ever used.
| Larrikin wrote:
| Streaming or player errors? Plex has basically never failed
| to play any video I've ever given it, but a bad connection
| can totally ruin streaming. I wish they would implement pause
| and allow to buffer.
| causality0 wrote:
| In my experience Plex has a serious problem with
| determining whether or not it's capable of playing a file
| back directly without converting. I regularly have to
| switch it to "convert automatically" to make a file play.
| Hamuko wrote:
| What can be directly played and not directly played are
| just lists of formats that Plex bakes into the app, and
| not really anything to do with mpv, right?
|
| https://github.com/ambroisemaupate/plex-
| profiles/blob/master...
| SSLy wrote:
| plex uses terribly old build of mpv with questionable config
| arch1t3cht wrote:
| IINA has various issues that mpv does not have, in particular
| with color space conversions (see
| https://news.ycombinator.com/item?id=41278331 for a few more
| details)
| darthShadow wrote:
| Adding onto this is Outplayer, which similarly uses MPV for its
| backend, for iOS & iPadOS.
| tvshtr wrote:
| MPV is slowly becoming the major embedable media player on the
| PC side. It's in a bunch of stuff and that's great.
| pentagrama wrote:
| Happy VLC user here, but might give this a try, I want to find a
| better UX with the player controls, like a way to pin the
| controls bar when full screen (it disappears after some seconds),
| a 10s forward/backwards control, bigger buttons, less bloated
| settings, less features that I don't use like radio and other
| stuff.
|
| But one thing that confused me seeing that homepage is that it
| shows a player UI screenshot, but it says " mpv is a free (as in
| freedom) media player for the command line", isn't just for the
| command line right? I assume you can install it as an app and it
| has an UI like VLC. (I'm on the phone rn will check it on my PC
| later).
| arp242 wrote:
| mpv has a UI for things like seeking forward and backward,
| displaying info, etc. But you typically start it like:
| % mpv file.mp4
|
| That's what they mean.
|
| It doesn't really have things such as "File - Open" like VLC
| has. At least not out of the box, but it's scriptable with Lua
| and there are scripts and even entire "alternative frontends"
| that can do this.
|
| It can also be remote controlled via a socket; I built an audio
| player like this; works pretty well.
|
| In general, if you want a "Windows-like" or "macOS-like"
| experience then VLC is pretty good. If you want a more "unix-
| beardy" experience then mpv is pretty good.
| pentagrama wrote:
| Thanks for your response. Understand. So MPV may not be for
| me, I don't know how to use a command line app, I remember
| have to use to fix an Ubuntu issue and the UX was painful to
| me.
| dsissitka wrote:
| You don't need to use the command line.
|
| If you set it as your default video player it will work as
| you expect.
|
| If you don't want to set it as your default video player
| you can probably do something like "Right Click -> Open
| with..." and choose MPV.
| pikelet wrote:
| There are graphical frontends like Celluloid.
|
| https://celluloid-player.github.io/
| rafaelgoncalves wrote:
| mpv tries to be pretty minimalist (and does this well), you
| could try a frontend (Celluloid, Haruna, etc.). And for the
| commandline, when you install the mpv package, depending on
| the distro, the package creates a default shortcut/desktop
| file, so you can open videos on your WM without hitches, on
| the menu bar. You can associate the shortcut to mime/file
| types and set as default player too. You can create
| yourself a desktop file too if necessary on your profile
| (eg: $HOME/.local/share/applications/mpv.desktop) with this
| file/content [1]
|
| [1]: https://github.com/mpv-
| player/mpv/blob/master/etc/mpv.deskto...
| btdmaster wrote:
| It does have a drag-and-drop window if you start it with `mpv
| --profile=pseudo-gui` (I think the same as its .desktop file)
| anta40 wrote:
| Ahhh.... sounds like tweaking vim/nvim (which is one of my
| daily tools).
|
| Sure the possibility to tweak the UI is limitless, but at
| least there are minimum usable UI, like gvim (Windows, Linux)
| or macvim (macOS) which are easy to install.
| SSLy wrote:
| you can just drag-n-drop a file on top of the window and it'll
| promptly get played
| foresto wrote:
| It's excellent with companion tools as well. For example...
|
| Streamlink, for watching live streams without a web browser:
|
| https://streamlink.github.io/
|
| Syncplay, for remote movie parties:
|
| https://syncplay.pl/about/syncplay/
| amlib wrote:
| My favorite feature of mpv so far is being able to apply CRT
| shaders in real time to content. This solution also handles
| properly downscaling HD videos into actual 240p buffers that then
| gets upscaled to your screen resolution by the shader.
|
| https://i.imgur.com/akmgzxX.png
|
| https://github.com/hhirtz/mpv-retro-shaders
| shpx wrote:
| On my Macbook Air, mpv adds an orange tint to videos so I hate
| when I have to use it because it's the only player that can play
| a file I downloaded.
| literallycancer wrote:
| Do you have the Apple silicon version? The brew package is
| messed up somehow IIRC a the up to date version for Apple
| silicon doesn't have the graphical shortcuts (I don't remember
| what brew calls these), but the one that does is for the Intel
| CPUs.
| lairv wrote:
| 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
| sergiotapia wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Dylan16807 wrote:
| I don't misunderstand. The program already has seeking
| code, and if it needs to aim back slightly so that it can
| be more precise that's not a massive change to how it
| already works.
|
| Efficiency is not as important as having the feature at
| all. "Go back 5 seconds and then run forward to the right
| frame" is a sufficient algorithm, as long as it can track
| and combine multiple presses of the previous-frame key.
| Improvements can come later. Maybe buffering, maybe
| tracking keyframes, maybe other things. But this is a big
| case of letting the perfect be the enemy of the good.
|
| If it fails to find a keyframe, that sucks, but 99% of
| the time it'll work.
| throwaway22032 wrote:
| The strange thing is that the same argument is true for
| seeking in general.
|
| Going back from frame 500000 to frame 499999 is in the
| limiting case as complex as seeking from 1 to 499999, and
| in most cases far better.
|
| I think the forum thread would be better answered "you do
| it, I don't need this feature" which is basically the
| gist of it and is a completely fair answer.
| a1o wrote:
| It's not even about doing it, once added you have to
| maintain it, and then tomorrow a new format arises that
| makes this more a hassle, or some memory issue in an
| existing format is fixed in a way that changes it's
| memory profile and now VLC will crash with an out of
| memory.
|
| Seriously, I don't get these people that have infinite
| demands from open source developers and contribute zero.
| armada651 wrote:
| You already have to maintain seeking code, stepping back
| one frame is just a specialized case for your seeking
| code.
| mrob wrote:
| You already have to maintain code for seeking by time.
| There's not necessarily any easy way to convert between
| time and frame count.
| _flux wrote:
| VLC knows the timestamp of the current frame. From that
| information it can seek to a frame that is before the
| current frame, possibly by just subtracting the inverse
| of frame rate from the current frame's timestamp and if
| seeking to that time results in seeking to the same
| frame, try again a bit older.
|
| I'm relatively sure this can be implemented in terms of
| timestamp-based seeking. Quite possibly the metadata of
| the frames is already in the memory, further simplifying
| the process.
| lupusreal wrote:
| > _just subtracting the inverse of frame rate from the
| current frame 's timestamp_
|
| Variable frame rate (VFR) videos break this approach. It
| might seem like an esoteric edge case, TV and movies
| aren't VFR after all, but VFR is extremely common in
| videos from smartphones.
| _flux wrote:
| This is why I also suggested a fallback in case it lands
| up in the same frame, but yes, it also needs checking
| that the next frame is indeed the original frame.
|
| I expect it to work unless the frame rate is _wildly_
| varying, e.g. 60 fps and 60 spf in the same video. I
| guess one reasonable use case would be video that 's
| triggered by motion, though. It would still work for
| almost every video.
| account42 wrote:
| > TV and movies aren't VFR after all
|
| There are TV shows that have telecined film segments and
| also interlaced VFX sections. While this wasn't broadcast
| as VFR the best way (as in highest quality result) to
| convert to a fully progressive frame sequence for display
| on modern displays would end up recombining the two
| fields for telecined segments (keeping the framerate)
| while doubling the framerate during deinterlacing for the
| VFX segments.
|
| But VFR is also irrelevant to the problem at hand since
| it doesn't make it harder to find the next keyframe
| before the current frame - you need an index for that
| anyway.
| KingMob wrote:
| 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.
| a1o wrote:
| If someone really wanted to do it they will be
| contributing already continually and at some point start
| working on this with the expectation that they are the
| one maintaining it. And it would be fine because by then
| developers would already trust that person since they've
| been reliable.
|
| It's not about "technical chops", it's about being
| constantly available, reliable person that shows to
| contribute day after day. If you don't do that why should
| a dev make the scope of their work bigger if they won't
| be able to keep putting the same quality of work?
| KingMob wrote:
| > why should a dev make the scope of their work bigger if
| they won't be able to keep putting the same quality of
| work?
|
| They shouldn't...but that's not at all what the primary
| developer said.
|
| The issue is the primary dev seems to require reverse
| seek functionality to work with all codecs, and since
| some obscure codecs can't efficiently support it, they're
| not interested. Their challenge to others to submit a PR
| is counteracted by all the signs that they might provide
| a high-to-impossible barrier to approval.
|
| It's not clear that even a trusted contributor would be
| able to sway this person's mind. Most likely,
| contributors either agree, or keep quiet on the issue if
| they disagree.
| account42 wrote:
| It's telling that there is no other VLC developer
| commenting in that thread - neither to support the
| decision and calm things down nor to go agains Remi's
| decree.
| seanthemon wrote:
| Just a ridiculous idea, could a reversed version of the
| video be kept around so that if you hit frame backwards
| it's frame forwards operation on the reversed video so you
| can show that frame, if you continue playback the head goes
| to the closest second of the forward video
| armada651 wrote:
| This would require completely re-encoding the video or
| keeping all decoded frames around. This is what he
| referred to as the "unbounded memory" solutions.
| seanthemon wrote:
| That makes sense, thank you!
| DonHopkins wrote:
| Again: There is no reason to start caching previous frames
| until AFTER the user has paused and pressed the "back
| frame" key. Only THEN does it need to rewind to the
| previous i-frame and re-render and cache frames. And there
| is no measurable cost to remembering the timestamp of the
| last i-frame, so you know where to rewind to.
| variadix wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.)
| skydhash wrote:
| > Caring about the user's requirements is part of the
| dev's job description.
|
| For OSS project, it's better to assume that the user
| persona for the software is the devs or the maintainers.
| The dev-user relationship you expect is actually the
| vendor-client in commercial software.
| makeitdouble wrote:
| > job description
|
| Money getting involved would indeed simplify the
| question.
|
| Here no money is changing hand, so coming up with an
| angle that's motivating enough for the devs is IMHO the
| only option. Either bring up an aspect they're not
| considering that changes the equation for them, or come
| up with a solution that isn't plaggued by the issues they
| are afraid to deal with.
|
| That's where I see listening to the devs and caring about
| their issues to be the only path forward, short of
| contributing as a dev oneself..
| NavinF wrote:
| > video with only a single key frame at the beginning
|
| I've literally never seen a video like that in my life, but
| I'd still expect it to work. Just decode everything
| starting from frame 1. My desktop can decode H265 at 1,666
| fps. I can wait.
|
| https://docs.nvidia.com/video-technologies/video-codec-
| sdk/1...
| Panzer04 wrote:
| That blows up pretty quickly though? Even a 10 minute
| video will take in the worst case ~20 seconds to decode
| at that rate.
|
| Not really an excuse not to have it (since most video
| wont be encoded in such an insane way), but the
| developers owe no obligation to users to implement it.
| Hendrikto wrote:
| Theoretically. Practically, 10+ minute videos with just a
| single i frame at the beginning do not exist.
| hsbauauvhabzb wrote:
| Wouldn't creating in-memory key frames for every nth frame
| resolve substantial computations on a frame-by-frame basis?
| infofarmer wrote:
| you'd have to "rebase" all the other frames to be derived
| from those
| coryrc wrote:
| You wouldn't have to any more than you need 0 through N
| frames in memory to calculate frame N+1. Whatever your
| decoding state completes at frame N can be considered a
| key frame.
| infofarmer wrote:
| decoding state can be bulkier than a key frame and opaque
| to the CPU if hardware acceleration is used
|
| I wonder if caching semi-compressed frames would be more
| efficient in either case (CPU or GPU)
| DonHopkins wrote:
| There is no reason to start caching previous frames until
| AFTER the user has paused and pressed the "back frame"
| key. Only THEN does it need to rewind to the previous
| i-frame and re-render and cache frames. And there is no
| measurable cost to remembering the timestamp of the last
| i-frame, so you know where to rewind to.
| scottlamb wrote:
| > If you have a long video with only a single key frame at
| the beginning then
|
| ...you can't support the scrub bar efficiently either, so
| no one encodes video that way.
|
| Typically to go to a frame you find the last IDR frame
| before it (and in reasonable encodings those are frequent
| enough) and decode forward until you get to the frame of
| interest. Doing that every time the user presses the single
| frame back button really doesn't seem that bad, and neither
| does holding onto some extra reference images for at least
| like 1080p frames. (8k video and such starts getting more
| expensive but maybe even then start doing all some
| references after the first press of the frame back button
| in this GOP or some such.)
|
| 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 and maintained indefinitely, but what folks
| are asking for is technically possible.
|
| > 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.
|
| Yeah, this. That's likely more or less what they already do
| with the scrub bar.
| mtrower wrote:
| > 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".
| mdf wrote:
| 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.
| DonHopkins wrote:
| Oh, I already tried that, and it didn't work.
|
| https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=
| 407...
|
| 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.
|
| More details:
|
| https://news.ycombinator.com/item?id=41281153
|
| 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:
|
| https://news.ycombinator.com/item?id=41280375
|
| >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.
| oefrha wrote:
| 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.
| DonHopkins wrote:
| 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.
| ruszki wrote:
| I learned this the hard way.
|
| 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.
| fragmede wrote:
| all that's correct, but it's besides the point since _other
| players are able to do this_.
| FabHK wrote:
| As outlined in some other thread, mpv is not able to
| stream eg to ChromeCast, unlike VLC. Maybe VLC supports
| certain things that make the previous-frame thing harder.
| I suspect it is so, but I don't have insight into the
| detailed architecture of VLC, unlike I assume the VLC
| developers. Do you?
| fragmede wrote:
| Why is their architecture making it harder on them
| relevant to the question if it's possible? Because the
| root question is if it's possible, and there's multiple
| existence proofs that it's possible. Maybe the VLC
| developers are just tired. I don't blame them. They had
| to do a whole refactor to get Chromecast support working,
| and they got no thanks for that. Or maybe it just wasn't
| enough thanks and they don't feel like doing another
| refactor. Chromecast support is quite tricky, I've dug
| into the protocol.
|
| Anyway, I'm not in control of their development, I'm just
| pointing out that seeking backwards is possible.
| FabHK wrote:
| And Teslas should have an 800 mile range. The Ford F-150
| with the 36 gallon optional tank proves that it's
| possible. Tesla's architecture making it harder is not
| relevant. /s
| oefrha wrote:
| > I think technically he's correct (I haven't worked on
| media decoding code, but I understand how common video
| encoding formats work).
|
| He's technically simply wrong (I have worked on media
| decoding code, hell I'm working on a related project
| today). His player supports seeking back by 10 seconds or
| whatnot, but he insists that somehow to implement precise
| seeking to the previous frame, you need to seek from the
| very beginning of the video, no two ways about it:
|
| > There is not a slight technical difficulty. On a logical
| level, this feature is algorithmically impossible, except
| for the extreme: You can decode all frames up to the
| previous one. But this would be far too slow for anything
| except really short videos.
|
| It's obvious bullshit, if you encounter one of those
| pathological videos (that don't really exist except in his
| mind or in some test suites) you just give up after a
| reasonable amount of time, same as how you give up if you
| can't seek back ~10s in a reasonable amount of time.
|
| And players do give up seeking all the time already, not
| just on these hypothetical one-I-frame-per-hour videos, but
| real world videos with messed up pts/dts with no reasonable
| way to go back a short interval.
| eviks wrote:
| Or in the less-than-worst case you could cache the created
| full frame if no native full frame is encountered for X
| seconds and then in the worst case you don't have to go to
| the beginning of the video, but to that cached intermediate
| full frame?
| F3nd0 wrote:
| 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.
| efilife wrote:
| VLC is pretty bad and it shows the more you use it.
|
| It doesn't let the audio clip/exceed safe volumes and always
| applies some sort of a limiter, even if it's disabled
| everywhere in the settings. Try using an EQ on a bass-heavy
| track and see that it's limited.
|
| Try jumping back multiple times in a song at its beginning, and
| it will play in lower pitch.
| darby_nine wrote:
| > VLC is pretty bad and it shows the more you use it.
|
| Compared to what? Such a statement is meaningless without
| comparison.
| opan wrote:
| Compared to mpv. Some would also say compared to mpc-hc.
| hollerith wrote:
| The first sentence on https://mpc-hc.org/ is, "MPC-HC is
| not under development since 2017. Please switch to
| something else."
| infofarmer wrote:
| search engines and wikipedia point to actively maintained
| versions
| defrost wrote:
| Instead of MPC-HC v1.7.13 (2017) maybe try MPC-HC v2.3.4
| (2024)
|
| https://github.com/clsid2/mpc-hc
|
| In many ways it's a display wrapper about codec
| components, the display part is in active maintainance
| and bug fix mode (last update two weeks ago) and the
| codecs are constantly being improved (and expanded as new
| ones emerge).
|
| https://www.codecguide.com/
|
| There are two or three MPC-HC spin offs that are tweaking
| the core to do new things.
| rocketvole wrote:
| it's annoying that the clsid fork isn't associated with
| the website- it adds a lot of confusion to what is
| probably the video player that compromises between user
| friendliness and customizability. It's usually the video
| player that I recommend to people because it seems beter
| than vlc and has a GUI for settings as opposed to mpv.
| account42 wrote:
| This is one of the many reasons why forks should use a
| distinctive name to differentiate themselves. Just
| realeasing new versions with the same name as the
| upstream project is generally a dick move.
| SirMaster wrote:
| I am pretty sure the dev (clsid2) worked on mpc-hc
| originally as well before.
| vharish wrote:
| I don't think the target audience are the same. Not so
| sure about this. Just my impression.
| darby_nine wrote:
| > mpv
|
| can you please explain what you mean with this acronym?
|
| EDIT: this seems to correspond to
| https://en.wikipedia.org/wiki/MPlayer
| user3939382 wrote:
| That strikes me as such a strange statement, I've always
| considered it to be among the most impressive OSS projects
| out there. It tackles enormous complexity, works everywhere,
| and has a trove of a million hidden features. For example, I
| use it to headless play streams from CLI.
| opan wrote:
| If you enter video-related enthusiast scenes, such as
| fansubbed anime releases, mpv is recommended over anything
| else across the board. There are releases that break in
| VLC, and mpv is usually first to support new features. It
| also has particularly good defaults in terms of good and
| accurate playback, so where you might see some people say
| "install mpc-hc and these scripts and change these
| settings", with mpv it's just "use mpv". mpv _is_ extremely
| configurable on top of great defaults also. Setting default
| audio and sub languages in order of your preference (such
| as enm before eng and en if you prefer honorifics tracks)
| is a common tweak.
|
| I thought VLC was awesome while growing up, and at the time
| it probably was compared to Windows Media Player and such.
| I remember a common bit of praise was that it supported
| more types of video files. I haven't really run into
| anything mpv won't play (I even use it when an image I
| saved ends up as .html for some reason and then use the
| info screen to determine the real extension it should be so
| I can rename it), but also I'm guessing we've standardized
| more on codecs and containers these days which doesn't
| hurt.
| latexr wrote:
| > I even use it when an image I saved ends up as .html
| for some reason and then use the info screen to determine
| the real extension it should be so I can rename it
|
| If you're on Linux on macOS, you'll have access to the
| `file` command-line tool which can do it effectively. In
| a couple of lines of shell scripting you can even have it
| auto-change the extension.
|
| https://en.wikipedia.org/wiki/File_(command)
| opan wrote:
| I had someone try to tell me this or some similar
| alternative method once, but for this particular use-case
| my method seemed faster. Usually I'm viewing the dir with
| the file in ranger, hit r (shortcut for :open_with ),
| type mpv, enter, I in mpv for info, q to quit, a in
| ranger to rename the file with old name pretyped in. It's
| a pretty smooth workflow. Assuming I start from the same
| place in ranger I have to press colon and type `shell -w
| file %s` and hit enter which may or may not be faster but
| I think is more keystrokes. I could bind it to a key in
| ranger if I found an open one and then that might be
| better. It's sometimes weeks between instances of the
| mis-saved images or else I might've tried harder to
| optimize this. The shell script idea is neat.
| latexr wrote:
| > The shell script idea is neat.
|
| Could be something as simple as:
| file_path="${1}" mime="$(file --mime-type --brief
| "${file_path}")" ext="${mime#image/}" mv
| "${file_path}" "${file_path%.*}.${ext}"
|
| That does no checks (e.g. is the file an image) and may
| not work on something on something like a video, but
| it'll do for common image types such as png, jpeg, webp,
| heic, gif...
| amiga386 wrote:
| Personally I use a shell script to do it automatically
| for me... with "file": #!/bin/bash
| # Usage: fix-extensions <media file(s)> # Renames
| the files to consistent file extensions based on content
| for file in "$@"; do [ -f "$file" ] ||
| continue dir=$(dirname "$file")
| name=$(basename "$file") prefix="${name%.*}"
| ext="${name##*.}" magic=$(file -b
| "$file") newext="" case "$magic"
| in *"Apple QuickTime movie"*)
| newext=mov;; "ISO Media, Apple iTunes
| Video"*) newext=mp4;; "ISO Media, MP4"*)
| newext=mp4;; "ISO Media, MPEG-4 (.MP4)"*)
| newext=mp4;; "Macromedia Flash data"*)
| newext=swf;; "Macromedia Flash Video")
| newext=flv;; "Matroska data")
| newext=mkv;; "Microsoft ASF"*)
| newext=wmv;; "MPEG sequence"*)
| newext=mpeg;; "Ogg data, OGM video"*)
| newext=ogm;; "RealMedia file")
| newext=rm;; "RIFF "*" data, AVI,"*)
| newext=avi;; "WebM")
| newext=webm;; esac if [ -z
| "$newext" ]; then echo >&2 "$file: not
| renaming, unknown extension for type '$magic'"
| elif [ "$ext" != "$newext" ]; then mv -v
| "$file" "$dir/$prefix.$newext" fi
| done
| BoingBoomTschak wrote:
| As someone who went MPC-HC + MadVR + ReClock -> mpv years
| ago (well, I also switched to Gentoo, to be fair). This
| is completely right.
|
| BUT mpv still isn't perfect. The script in
| https://github.com/mpv-player/mpv/issues/8463 is really
| needed to handle some stuff (mainly clandestine anime)
| and the libplacebo/gpu-next transition wasn't exactly the
| smoothest (my config still has hotfixes for
| https://github.com/mpv-player/mpv/issues/10716 and
| https://github.com/mpv-player/mpv/issues/14474).
|
| Nitpicking aside, it really is the new gold standard
| these days, and for good reasons.
| bananamerica wrote:
| VLC makes video choppy on my low-end Debian machine. MPV
| plays them perfectly.
| ruszki wrote:
| > works everywhere
|
| No, it doesn't. I had problems with it, which was tackled
| by basically every other players easily (e.g. seeking or
| simply playing anything).
| cypress66 wrote:
| VLC is only praised in "normie" places. It is hated in
| places like anime forums, 4chan, etc.
| exhilaration wrote:
| TIL I'm a normie. And I thought I was a hotshot tech guy.
| mardifoufs wrote:
| Maybe not hated but yeah I think the memes about the
| first memes I've seen about artifacts/stuttering in VLC
| are basically as old as VLC itself. And new ones keep
| getting made
| sph wrote:
| > has a trove of a million hidden features
|
| No software person would find this praiseworthy. A million
| features = two million bugs, and indeed it shows.
| Asraelite wrote:
| Speak for yourself. I would much rather have a buggy
| feature than no feature at all.
| FabHK wrote:
| I guess I don't want my video player to let audio exceed safe
| volumes...
| Always42 wrote:
| I have ran into this issue as well. I believe my solution was
| to use pot player but i am not sure if its open source
| j1elo wrote:
| 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).
| ziml77 wrote:
| 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.
| jbverschoor wrote:
| 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.
| vharish wrote:
| 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?
| jbverschoor wrote:
| 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
| borski wrote:
| Everything is a "simple thing" unless you're the one
| implementing it. Things that seem simple on the surface
| rarely are, especially long-term.
| jbverschoor wrote:
| 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?
| borski wrote:
| https://www.quora.com/Why-are-software-development-task-
| esti...
| jbverschoor wrote:
| That article means: inexperience and unprofessional.
| Sounds about right.
| borski wrote:
| 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.
| zerkten wrote:
| 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.
| vharish wrote:
| 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.
| ziml77 wrote:
| 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.
| admdly wrote:
| 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.
| marcus_holmes wrote:
| 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.
| somnic wrote:
| 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.
| tuxone wrote:
| 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.
| account42 wrote:
| ... 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.
| FabHK wrote:
| 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?
| wrasee wrote:
| 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.
| wrasee wrote:
| 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.
| GuB-42 wrote:
| 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.
| Bluestein wrote:
| > lock the thread before people start mentioning nazis.
|
| Which will invariably happen. What was that "rule" called
| again?
| gioo wrote:
| It's Godwin's law (of Nazi analogies):
| https://en.wikipedia.org/wiki/Godwin%27s_law
| wrasee wrote:
| 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.
| DonHopkins wrote:
| 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.
| marcus_holmes wrote:
| 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.
| FabHK wrote:
| 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.
| wrasee wrote:
| 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.
| FabHK wrote:
| 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.)
| marcus_holmes wrote:
| > 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.
| upon_drumhead wrote:
| > 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.
|
| It's also not consistently applied. VLC will happily let you
| jump around in the videos, so his claim that the only way to
| do it is to play the video as fast as possible from the start
| of the video just doesn't jive with what is already there.
| sebastos wrote:
| 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.
| tumult wrote:
| VLC doesn't have perfect compatibility. I think it worked
| correctly on random video files less frequently than mpv
| the last time I tried it. And mpv can actually step forward
| and back frame by frame.
| 77pt77 wrote:
| So can mplayer and did that way before mpv could.
| dikei wrote:
| mplayer was forked into mplayer2, which in turn was
| forked into mpv
|
| Though AFAIK, most of the rendering code behind mpv has
| been entirely rewritten.
| throwaway2037 wrote:
| What was the cause of the fork? An unresolvable internal
| debate? I am curious to know more about the history.
| dikei wrote:
| I'll refer you to the MPV FAQ for historical context.
|
| https://github.com/mpv-player/mpv/wiki/FAQ#how-is-mpv-
| relate...
|
| There were lots of drama in the media player scene. Even
| "wm4" the original maintainer, who forked mplayer2 into
| mpv, is no longer with the project: he deleted his Github
| account and disappeared.
| ruszki wrote:
| I found MPV because VLC was unreliable. Seeking was
| especially crazy sometimes, and not that I couldn't seek
| to the exact moment, but I couldn't seek at all. Even
| displaying was broken sometimes regardless of file types.
| I had none of these issues with MPV for the same files.
| neckro23 wrote:
| VLC is sometimes so unreliable for me, especially when
| seeking or frame-stepping, that it stops responding to
| playback commands entirely (although it pretends to still
| work) and I have to kill the zombie process before I can
| even re-open the file and try again.
| JTyQZSnP3cQGa8B wrote:
| I know the devs are good and they want the feature to be
| perfect, but it reminds me that they removed the ability to
| browse files on the iPhone which is unexplainable, or show
| that they are a bit in denial of what users need, which is
| confirmed by this thread.
| borski wrote:
| Wait, what? You can browse files on the iPhone just fine.
| kstenerud wrote:
| > A playback architecture that can wrangle all of that
| cruelty into a consistent experience was hard won.
|
| No, it hasn't. The only reason I use mpv instead of VLC is
| because of the frame step feature. Everyone else has proven
| that it is possible and practical to do.
|
| Never let the perfect be the enemy of the good. If people
| don't use your product, it doesn't matter how right and
| pure of vision you are.
| MattDaEskimo wrote:
| The developers had a philosophy and they stuck to it.
| It's an open source project, not a profitable service.
| namdnay wrote:
| > No, it hasn't. The only reason I use mpv instead of VLC
| is because of the frame step feature
|
| You realise your requirement is important for less than
| 0.01% of users? For every requirement you have to balance
| future maintainability and the impact it has on the code
| base against potential revenue
| topato wrote:
| Not sure VLC is balancing anything against "potential
| revenue"...
| Sophira wrote:
| I assure you the figure is much, much greater than 0.01%.
|
| Even outside of specialist uses (and not just in the
| field of video, either), most people like being able to
| pause a video on a specific frame to be able to study it
| more closely. Often that requires (or at least the task
| is made much simpler by) being able to step forwards and
| back frame-by-frame.
| namdnay wrote:
| > most people like being able to pause a video on a
| specific frame to be able to study it more closely
|
| I think the vast majority of people just want to be able
| to watch the film they downloaded.
| zem wrote:
| > The only reason I use mpv instead of VLC is because of
| the frame step feature.
|
| so from VLC's point of view your problem is solved - you
| have a good, open source video player that lets you step
| back a frame and you are happy to use it. they don't need
| to be all things to all people.
| sebastos wrote:
| I'll admit I can't weigh on whether there's a plausible
| strategy for implementing backwards frame step in VLC
| without violating any of their sacred invariants. Maybe
| the existence of other players with that feature implies
| that the VLC devs just aren't seeing it. But without that
| knowledge, I'm left to trust the developer's presumably
| deep knowledge of their own architecture when they say
| that it just doesn't 'fit'. It seems more likely that the
| other players can do it because they're architected
| differently, or they make a different (smaller) set of
| guarantees about which formats they will play back in
| which scenarios.
|
| >Never let the perfect be the enemy of the good. If
| people don't use your product, it doesn't matter how
| right and pure of vision you are.
|
| This is great advice... for a business. VLC isn't a
| business, it's a useful thing that exists. It gives
| people fulfillment to donate their time to keep it useful
| and relevant. That fulfillment is going to be directly
| proportional to how elegant the design is and how much
| leverage they have, i.e. small amount of good code
| provides wide amount of functionality for many happy
| users. The more that maintenance of VLC degrades towards
| "brutal hand-crafted specialization of huge switch
| cases", the less well-maintained it's going to be. This
| is not an excuse, it's a statement about human nature,
| something akin to economics.
|
| It's possible that mpv picked a better abstraction and
| they can provide a strictly better application for the
| same or less software maintenance cost. But I tend to
| suspect that the differences arise from levels of
| support, not better design. That's just a spider sense
| though.
| throwaway2037 wrote:
| > VLC isn't a business
|
| On the surface this is true, but my guess: The core team
| work as consultants. See "Consulting services" ->
| https://www.videolan.org/videolan/partners.html
|
| I assume this means you can hire lead devs to fix bugs
| and add features.
| somnic wrote:
| The choice not to implement it for architectural reasons is
| entirely up to the devs, is likely justified, and in most
| cases users acting entitled to support and feature
| additions from OSS developers who are volunteering their
| time is something I side against. But the devs also should
| be able to talk to people who aren't marinated in that same
| viewpoint, for their own sake if nothing else. The leap
| from "there exist cases where implementing this feature in
| a performant manner wouldn't be feasible" to "we shouldn't
| implement this feature even for the many cases that would
| support it" isn't going to be obvious to everyone.
|
| VLC's poor performance in seeking backwards in general, not
| just by frame, is a big part of why it's no longer my media
| player of choice. Which is fine! As an OSS project there's
| no real reason to care about the number of users as long as
| enough people are involved to sustain the project, and
| making the developer experience pleasant is more important
| than making the user experience pleasant on that front. It
| just means it's not as good a tool for some users as
| others, like mpv.
| langcss wrote:
| 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?
| martin293 wrote:
| You can only do it for certain formats
| langcss wrote:
| 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.
| sph wrote:
| You speak as if VLC is the pinnacle of video player
| technology. I know it is an open source darling, but it's
| been a buggy, overengineered mess since forever, which is
| why many use alternatives as mpv, IINA when I used macOS,
| SMplayer, etc.
|
| On fact, with all due respect, I never understood why VLC
| was so widely praised. It is the only player to stutter for
| me on Windows, to get lost in its settings page, to have a
| terrible playlist implementation that's forced upon you,
| doesn't handle corrupted media as well as others, etc. mpv
| on the other hand does one thing and does it very well.
|
| I'll skip ranting about VLC for Android TV this time
| RulerOf wrote:
| > On fact, with all due respect, I never understood why
| VLC was so widely praised.
|
| It's praised because it "plays everything."
|
| It developed this reputation in an era when even average
| people were installing numerous DirectShow "codec packs"
| (often of dubious pedigree) in an often futile effort to
| "play that thing I just downloaded" from the P2P file
| sharing network du jour.
|
| For a number of reasons, installing a bunch of these
| codec packs would often leave video playback broken
| globally[1]. Since VLC is cross-platform, it does not use
| DirectShow, and would "fix" a system that had been
| "broken" by other software.
|
| [1]: most of these issues could be fixed with the
| GraphEdit utility, which offered a simple but powerful UI
| for configuring and testing every codec in the system.
| GraphEdit should have been included with Windows, and be
| something you could invoke from within Control Panel.
| Refusing23 wrote:
| VLC even plays incomplete files which i've found useful
| every now and again.
| account42 wrote:
| Literally every FFMPEG-based player will play whatever
| you throw at it. While it may be an advantage over basic
| bith OS-provided players it hasn't been a unique selling
| point for VLC for a long long time.
| badsectoracula wrote:
| > On fact, with all due respect, I never understood why
| VLC was so widely praised.
|
| For me the alternatives back when i first wanted a video
| player that could play various file formats were Media
| Player Classic (which worked only on Windows and relied
| on external codecs that sometimes didn't fully work),
| mplayer (which had annoying arcane commandline switches
| and weird shortcut keys), Totem (which used gstreamer
| which 90% of the time either didn't had the codecs i
| wanted or they were very buggy). More recently the only
| alternative seems to be mpv (which seems to be a mplayer
| fork that persists with the arcane switches and apparent
| hate of anything resembling a discoverable GUI).
|
| VLC on the other hand is available on anything that has a
| display (or at least anything that has a display and i'd
| want to play videos on it - that is currently Linux and
| Android and sometimes Windows) and has a GUI that while
| might be a bit on the overloadedly bloated side, at least
| it shows everything you may (and often you may not) want
| to configure, with actual menus, categories, tooltips,
| etc. And when it comes to the most common aspect,
| playback of videos, it shows a simple and to the point UI
| with the play, seek, volume, etc buttons that you'd need
| 99% of the time (that admittedly most other players do
| too, except they don't do the 99% rest of the GUI that
| VLC does).
|
| So, basically VLC is my preferred video player largely
| because 20 years ago i didn't had to read a tutorial on
| how to select the subtitle language (or something along
| these lines) and was able to play pretty much any video i
| threw at it without any extra fuss.
| metroholografix wrote:
| I always saw VLC as subpar. A typical case of software
| that's just trying to copy what the pioneers do. As we
| all know, mediocrity it not antithetical to popularity,
| and VLC has become very popular indeed.
|
| However, it never pushed the envelope in terms of codecs,
| features and performance and as a result was never at the
| forefront of opensource video playing: mplayer got the
| ball rolling with rapid breakthroughs including hardware
| acceleration (e.g. /dev/mga_vid) before standards such as
| xvideo even existed and that spirit of technical
| excellence has been passed on to Mpv which remains at the
| pinnacle.
| diggan wrote:
| > I always saw VLC as subpar. A typical case of software
| that's just trying to copy what the pioneers do.
|
| What pioneer is/was VLC trying to copy? Media Player
| Classic? Windows Media Player? Before VLC, the ecosystem
| of video players was a mess, and if you came across a
| format you didn't already had installed codecs for,
| chances were you couldn't play that file. But VLC always
| could play it, no matter what file, as long as it said it
| was a video file.
|
| > However, it never pushed the envelope in terms of
| codecs
|
| VLC literally took over the world because you could
| install VLC and VLC only, and stop having to care about
| codecs at all, at the time at least. Maybe today it's
| different, because the ideas of VLC already spread, but
| at the time, things were different.
|
| I personally use mpv most of the times today, but when I
| got started with computers and didn't understand as much
| as I do now, installing codecs to be able to view some
| video I just downloaded was a pretty confusing task. CCCP
| (Combined Community Codec Pack) for MPC helped a lot, but
| to even get to that point took some time.
| nubinetwork wrote:
| Wasn't CCCP bundled with malware or something back in the
| day?
| diggan wrote:
| Not that I'm aware of, nor can I find any sources talking
| about it. Maybe you're confusing it with DivX that did
| something like that
| (https://news.ycombinator.com/item?id=6409888)? Both were
| popular during the same timeframe, so not impossible
| you're confusing the two.
| nubinetwork wrote:
| Hmm... possibly. Funny how my memory works sometimes. ;)
| lupusreal wrote:
| > _I never understood why VLC was so widely praised._
|
| Because it's the one you can reasonably suggest to all
| your utterly nontechnical friends and relatives to get
| them to stop downloading random sketchy exe's from the
| internet to install codecs.
|
| mpv, and mplayer before it, has always been better _for
| me_ and I find VLC to be pretty shoddy. But when it comes
| to people like my mom, I don 't hesitate to sing praise
| for VLC. _In that context_ , VLC is the greatest thing
| since sliced bread and I don't muddy the waters by even
| mentioning mpv.
| Bluestein wrote:
| > Because it's the one you can reasonably suggest to all
| your utterly nontechnical friends and relatives
|
| I concurr.-
|
| PS. On a related tangent the amount of _unpaid_ "support"
| tech knowledgeable individuals are doing for
| (particularly) FAANG is enormous.-
| diggan wrote:
| > PS. On a related tangent the amount of unpaid "support"
| tech knowledgeable individuals are doing for
| (particularly) FAANG is enormous.-
|
| Which is exactly the same for every profession. If you
| have a plumber friend and have issues with plumbing, who
| you call first, a random contractor or your friend?
| Replace "plumber/plumbing" with any profession and the
| answer is usually the same, you call your friend first,
| at least to get some more understanding before reaching
| out to a contractor.
| Bluestein wrote:
| Sure. I understand, and agree.-
|
| I was just wondering about what the sum total of the
| (otherwise) "billable" hours might amount to, were they
| to be accounted for as a cost of business for FAANG.-
| account42 wrote:
| The difference is that if your plumber friend helps you
| out with your toilet, Big Plumbing Inc does not get your
| business.
|
| If however your tech friends help you with
| Windows/Android/Apple issues, MS/Google/etc. still get
| paid and save up on support costs.
|
| These two situations aren't even remotely comparable.
| Bluestein wrote:
| > Windows/Android/Apple issues, MS/Google/etc. still get
| paid and save up on support costs.
|
| This was kind of like what I was getting at: Kind of
| wondering what the total savings for FAANG on support
| costs would amount to, factoring in all this "offloaded"
| support that they hand off to their own customers (or,
| affiliated tech-savvy individuals).-
| soderfoo wrote:
| Well stated.
|
| VLC has a few nits, e.g. common settings and useful
| functionality buried somewhere. Like mouse gestures for
| instance, you have to go out of your way to enable them
| and cannot customize the mapping.
|
| mpv on the other hand, I have multiple config profiles
| different viewing purposes. It introduced me to ffmpeg,
| which as someone who became a dev later in life, made me
| more comfortable with using cli tools and diving in to
| documentation. Being able to tinker made me feel like
| hackerman.gif and is one of the things that things that
| helped my career transition.
|
| But yeah, not for my mom or wife, VLC is best for them.
| immibis wrote:
| I see VLC as the swiss army knife that can play anything
| you throw at it, no matter how weird. I see mpv as a more
| streamlined, less abstract implementation that supports
| many fewer options, but can contain special-case code
| paths for hardware acceleration, for example. Hardware-
| accelerated playback on my Raspberry Pi 3 works out of
| the box with mpv but requires some special trick or
| doesn't work at all in vlc. I assume mpv's design allows
| it to contain a special-case code path when you happen to
| be playing something compatible with a Raspberry Pi's GPU
| on a Raspberry Pi.
| account42 wrote:
| What files can your VLC play that MPV can't? Both get
| almost all of their codec support from FFMPEG.
| maeln wrote:
| VLC is *amazing* at its design purpose: being a rock
| solid video player. The GUI, the UX, and other things can
| be criticized, but I dare you to find another video
| player that will play just about *anything*, and without
| having to install external codec separately with weird
| licence.
|
| You can throw at it a broken mp4 file, a https url with
| basic auth, a weirdly encoded video, a DVD full of
| scratches, etc, chances are VLC will manage to play it
| (at least what is playable). There is just no other video
| player in the world that achieve that.
|
| A lot of other video player might beat it at other
| features, but just straight video playing, VLC is just
| the best.
| eviks wrote:
| > without having to install external codec separately
| with weird licence.
|
| What's up with this artificial limitation? I'd take frame
| back function over not having to install some codec pack
| once any time
|
| And 99.99% of the time you don't play "everything, with
| scratches", so UX issues are much more consequential than
| that
| hiptobecubic wrote:
| It's not artificial at all. It's a real limitation that
| was so outrageously annoying for the reasons mentioned
| above that VLC was able to "win" by tackling this one
| issue alone.
|
| The success of vlc is all the proof you need. As you say,
| why else would it be so popular?
| sangnoir wrote:
| > What's up with this artificial limitation? I'd take
| frame back function over not having to install some codec
| pack once any time
|
| Then VLC is not for you - and there's nothing wrong with
| _it_ or _you_ - you just happen to have differing
| priorities. Back when the Internet was more p2p, the
| ability to play uncommon media formats and containers was
| crucial. Even today, VLC offers a lot of value to anyone
| who has to playback media whose encoding they have no
| control over.
|
| VLC has other useful features as well (like streaming
| while playing back, allowing for multicomputer watch
| parties on the same network)
| account42 wrote:
| > VLC is _amazing_ at its design purpose: being a rock
| solid video player. The GUI, the UX, and other things can
| be criticized, but I dare you to find another video
| player that will play just about _anything_ , and without
| having to install external codec separately with weird
| licence.
|
| MPV? You know, the subject of this post we are commenting
| on?
|
| Or literally any FFMPEG-based player.
| nubinetwork wrote:
| AFAIK, VLC was the one of the first players that was able
| to read all sorts of formats... back in the day, you were
| lucky if you could play mp2 and mp4, let alone
| mkv/avi/etc...
|
| Sadly VLC devs have let their software deteriorate to the
| point where VAAPI hw decoding doesn't even work anymore,
| they think it's ffmpeg's fault... except ffmpeg supports
| it just fine, VLC is just too lazy to update their ffmpeg
| calls to use the api correctly.
| pxc wrote:
| > many use alternatives as mpv, IINA when I used macOS,
| SMplayer, etc.
|
| Those are all basically the same alternative in terms of
| backend. They're all based on ffmpeg and of mplayer
| lineage. I don't think there are many (any??k others
| comparable to VLC in terms of covering so many formats
| that are independent of FFMPEG. Maybe GStreamer?
| littlestymaar wrote:
| > 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.
|
| VLC used to be the dominant video player for this reason,
| but then everything has crystallized around h.264 (and
| h.265) which made the breadth of codec support not as
| important anymore, making VLC slowly losing relevance
| because they aren't focused on user experience enough.
| badsectoracula wrote:
| > h.264 (and h.265) which made the breadth of codec
| support not as important anymore
|
| You say that but just yesterday i used VLC to play some
| old videos i had which AFAICT were in RealVideo format or
| something like that.
|
| And i transcode everything i want to watch in my Android
| tablet (where i also use VLC) to mpeg2 because the tablet
| is ancient (10+ years old) and can't handle anything
| newer, so i am glad that VLC a) still works on the
| ancient Android OS it has and b) still supports an old
| outdated but CPU light video format :-P.
| littlestymaar wrote:
| I'm not saying it's useless. But now it's situational,
| which wasn't the case in the 2000s.
| mijamo wrote:
| One could argue video players in general just lose
| relevance in an age of streaming ... And everything has
| definitely not crystallized around h.264. plenty of
| sources will give you widely different things, for
| instance digital cameras, webcam, even screen recorders.
| Basically most of the input is in completely different
| formats. If you were thinking about pirated movies then
| it is of course more the case, but I wouldn't think it is
| the biggest use case of VLC. I for one appreciate being
| able to read both Mac screen recordings and clips from my
| DSLR with the same software without installing a bunch of
| weird stuff.
| throwaway2037 wrote:
| > slowly losing relevance
|
| I love this type of editorializing language. Ok, if VLC
| is "slowly losing relevance" (a claim for which you
| provide no evidence), what player is "slowly gaining
| relevance"?
| littlestymaar wrote:
| Everything that is provided by default by the OS.
|
| Installing VLC used to be one of the first things people
| did on a new computer, including many non tech-savy
| people, along with a web browser that isn't IE/Edge.
|
| Now the fraction who bother installing it is much
| smaller. The default video player is good enough for most
| usage (overall usage has declined anyway because of
| streaming).
| hollerith wrote:
| I wonder: Is this why vlc delays for 5 to 10 seconds every
| time I use the "skip backward" functionality on my iPad,
| where other players don't have that delay?
| ryukoposting wrote:
| > VLC is what it is today
|
| VLC is the least common denominator of video players. Its
| UI is asinine and the two primary reasons for its
| popularity are its iconic logo and multi-OS compatibility.
|
| I admit you're probably right on the topic of stepping
| backwards by one frame, but I wouldn't be so quick to
| shower VLC with broad praise like that.
| throwaway2037 wrote:
| > Its UI is asinine
|
| Well, that's not a very nice thing to say. And, it isn't
| productive to the conversation.
|
| What is it about end-user software with a GUI that seems
| to trigger such heated, emotional responses on HN? Each
| time that I read discussions like these, everyone and
| there uncle pops into the conversation to add the "one
| thing" they don't like about it. Or "I'll never use it
| again after that UI bug from 2004." It is exhausting. One
| thing that I have learned over the years: Never ask a dev
| their opinion about a UI. Or, if you do, make sure to
| ignore whatever they say. It is mostly complaining about
| "hang-nails".
| quotemstr wrote:
| Yet the bumblebee flies. mpv does, in fact, have a working
| "go back one frame" button, so VLC protestations that such
| a thing is infeasible look silly now. Great example of "red
| pen" versus "blue pen" thinking: we should spend less time
| decrying things as wrong or impossible and more time
| looking for approaches that we might have overlooked. Less
| "no", more "yes, if".
| aoeusnth1 wrote:
| Going back one frame is about as hard as going back one
| second. VLC allows you to click on the bar to go back to a
| time, which doesn't work in all video formats (as mentioned
| by the dev). Going back one frame would not be any harder
| or more variable across formats than going to a specific
| time.
| account42 wrote:
| Which is why VLC doesn't implement seeking because that
| only works for indexed formats? No of course not, that
| would be ridiculous, right? And if you can seek somewhat
| accurately you can then skip to a specific frame with
| bounded time. If your idea of supporting a multitude of
| formats is to only support the lowest common denominator
| then your software is not going to be very useful.
|
| It's also not like only some very nieche professional-only
| formats will have the required indexes. No, 99.99% of
| videos support accurate-enough seeking because that's
| something most people expect to be able to do with their
| video files.
|
| You are also making it sound like VLC is the _only_ player
| that has managed to support a wide range of formats when
| there are countless of ffmpeg-based players that manage to
| do that, like the subject of this post.
| Dalewyn wrote:
| >Sometimes we forget that software ought to be useful, not
| hypothetical ideals of truth.
|
| I've long since come to the understanding that if I want
| software that are _useful_ , I must go and pay for it.
| Commercial software exist to make money, and to make money
| they must be useful.
|
| If I want software that are _hypothetical ideals of truth_ ,
| I go and shitpost at the nearest neckbeard communion. Free-
| beer software exist to satisfy a man's desire to display his
| voluminous beard, everything else is tertiary.
| fragmede wrote:
| > I've long since come to the understanding that if I want
| software that are useful, I must go and pay for it.
| Commercial software exist to make money, and to make money
| they must be useful.
|
| Even if it were free, wouldn't you want to do something
| nice (like give them money) for the person(s) who made the
| useful thing for you?
| usr1106 wrote:
| This might be true in some application areas, but certainly
| not generally.
|
| Where is that commercial kernel that works over a wide
| spectrum of architectures and system sizes?
|
| Where is that commercial compiler that works on many
| architectures?
|
| Where is that commercial packet capture software that
| people a paying for to get work done?
|
| Where is that commercial emulator that can run your
| operating system on a very different machine in countless
| combinations.
|
| The list could go on and on...
| lupusreal wrote:
| What commercial video player do you use which is better
| than both mpv and VLC?
| account42 wrote:
| It's the opposite in my experience. Commercial software
| only cares at most about what is useful to the average user
| while anything for power users is written off as too
| expensive to maintain. And these days even if you pay you
| are often not the main customer since your data and
| attention is sold to someone else anyway, in which case
| what is useful to you matters even less.
| DonHopkins wrote:
| "I'll be waiting for your patch. Surely you're not as lazy
| and incompetent as the existing volunteer developers."- Remi
| Denis-Courmont
|
| I see Remi Denis-Courmont's arrogant attitude and disrespect
| for users and developers hasn't improved in all these years.
| And neither has VLC's spectacularly awful UI. Coincidence, or
| cause and effect?
|
| https://news.ycombinator.com/item?id=13573499
|
| DonHopkins on Feb 5, 2017 | parent | context | favorite | on:
| Nullsoft: The death of the last maverick tech comp...
|
| VLC's UI sucks so terribly, it's like they went WAY out of
| their way to make it sucks on purpose, and stubbornly refuse
| to acknowledge that there are any problems or ever consider
| fixing them. One example of many [1]:
|
| Type CMD-E (on Mac, or whatever the equivalent is on Windows)
| to get the video effects window.
|
| Select "Geometry". Now check "Magnification/Zoom".
|
| Notice how you get a picture-in-picture in the upper left
| corner, with a white rectangle showing the zoomed area, that
| you can move around by clicking. But if you press and hold,
| it also drags the entire windows (on a Mac -- I haven't tried
| on Windows -- VLC's UI and behavior on Mac and Windows
| diverges widely so I won't try to predict what happens).
|
| Now look underneath the picture-in-picture and notices some
| ugly upper case pixelated text that says "VLC ZOOM HIDE". See
| how it's jaggy and rendered at the resolution of the movie
| you're playing itself, not at screen in a full resolution
| overlay with readable text?
|
| Now look at the triangle with a jaggy curved hypotenuse below
| the jaggy words. That is the zoom "slider" (which also drags
| the window when you drag the mouse, so it's more like a
| clicker than a slider). See how it gets narrower and narrower
| in a succession of jaggy stair-step chunks, until it's merely
| one jaggy pixel wide? Well guess what: the TARGET AREA also
| gets narrow to match the width of the slider, so it's almost
| impossible to click on the bottom of the slider, to select
| the larger zoom sizes! Since the zoom slider is not very tall
| and its pixels fat and jaggy, you don't have fine grained
| access to very many zoom sizes at all, either. The zoom pixel
| steps are much bigger than screen pixels, depending on the
| video resolution!
|
| What possible purpose could that serve? Why would any user
| guess that the lower narrow part of the slider represents a
| wider zoom showing a bigger rectangle over the picture-in-
| picture, while the top wider part of the slider represents a
| tighter zoom showing a smaller rectangle over the picture-in-
| picture? And what slider have you ever used that gets
| narrower from top to bottom, with a jaggy curve, and an
| impossibly narrow hard to click target area at the bottom?
|
| This single facet of VLC's terrible UI deserves to be front
| and center in the User Interface Hall of Shame [2] -- it's
| even worse than Apple's infamous schizophrenically
| skeuomorphic QuickTime 4.0 player [3], from 1999! The latest
| version of VLC in 2017 is still much worse than the shameful
| QuickTime player was 18 years ago!
|
| Who could have possibly gone so far out of their way to
| design and implement such a terrible user interface on
| purpose, then smugly brushed off and ignored 16 years of bug
| reports and cries for help on the VLC message boards, without
| harboring a malicious contempt for their users?
|
| That's not even the worst of it. Now check "Transform" and
| pick one of the transforms like "Rotate by 90 degrees". Guess
| what? The magnification interface itself is rotated 90
| degrees, because it's drawn on the video before it's rotated,
| so now it appears at the top right of the screen, rotated 90
| degrees itself.
|
| And guess what else? The mouse clicks are not even
| transformed properly, so clicking on the magnification
| interfaces does NOTHING, rendering it completely useless!
| Depending on the aspect ratio of the video, you can't even
| click in the upper left corner where it USED to be and SHOULD
| still be to operate it, because it is clipped off the right
| edge of the window.
|
| Are those ugly cosmetic and impossible usability problems not
| bad enough for you? Then make a playlist with one item.
| Select "Repeat" mode. Play the movie. Now go to the finder
| and remove, rename or move the movie you're playing, or just
| unplug the USB stick containing the video. Not an uncommon
| occurrence, right? Now VLC will hang up, consuming 100% of
| the CPU time, often times seizing up the entire Mac, turning
| on the fan, locking out all user input, and forcing you to
| reboot! This happens to me all the time.
|
| These bugs have been around for years. The more you fiddle
| around with it, testing out the edge cases and trying to
| combine various poorly designed and implemented features, the
| more bugs you find.
|
| File a bug report, they say. People report these problems
| again and again. The developers just ignore them and brush
| them off. I've tried reporting these and other bugs,
| describing them in meticulous detail, which is frustrating
| because once I start writing step-by-step instructions to
| reproduce one problem, I keep finding more and more problems,
| each worse than the last, and then they just brush me off and
| ignore my bug reports too.
|
| VLC's user interface is maliciously terrible in so many ways,
| the developers are careless and arrogant towards their users,
| and there's no hope of the developers ever changing their
| ways, acknowledging the problems, and improving it. Instead
| of improving usability for everyone, they're more interested
| in adding yet another obscure anime decoder feature so they
| can watch their AMV cartoon porn [4] [5].
|
| [1] http://imgur.com/gallery/g0acV
|
| [2] http://hallofshame.gp.co.at/index.php
|
| [3] http://hallofshame.gp.co.at/qtime.htm
|
| [4] https://www.videolan.org/vlc/releases/2.1.5.html
|
| FOR ANIME FANS
|
| New 6.1 downmixer to 5.1 and Stereo from MKV/Flac 6.1.
| Correct YUV->RGB color matrix in the OpenGL shaders. Improved
| MKV support for seeking, and resiliancy. Editions support in
| MKV. Better subtitles and metadata support from MKV. Various
| ASS subtitles improvements.
|
| [5] https://myanimelist.net/forum/?topicid=208770
|
| Now, if you are an AMV (Anime Music Video) creator and want
| to edit the video directly, the MKV is your best friend since
| it's a lossless video-content container due to the fact that
| you will find yourself adding effects to the video
| frames/audio. In this case you will want to lose as little as
| possible in your video, so MKV compression best suits.
|
| TOPIC ANSWER: The reason why MKV is popular for anime is
| because of it's noted lossless compression. Anime show
| creators most likely notice this fact and use it to contain
| their video frames and audio tracks for maximum quality. - it
| has nothing to do with HD.
|
| derefr on Feb 5, 2017 [-]
|
| > Instead of improving usability for everyone, they're more
| interested in adding yet another obscure anime decoder
| feature so they can watch their AMV cartoon porn Mind you,
| FOSS is contributed to by people scratching their own itch.
| It's not so much that VLC has a lot of otaku developers; it's
| that a lot of people who watch (or subtitle) "AMV cartoon
| porn" see a problem with, or missing feature in, VLC, and
| think "I'm a programmer; I can fix that", and dash off one-
| off patches.
|
| DonHopkins on Feb 6, 2017 | parent | next [-]
|
| It just puzzles me that out of eight bullet points
| summarizing the new features in VLC 2.1.5, one of them was
| "FOR ANIME FANS" and none of them were "FOR USABILITY". It's
| the contempt and dismissal that the developers show to
| usability bug reports when they brush them off and ignore
| them, which bewilders and frustrates me. Go read some of the
| discussion group postings and bug reports over the many
| years, and you will see what I mean. It's a deeply entrenched
| pattern of behavior.
|
| majkinetor on Feb 6, 2017 | parent | prev [-]
|
| Its very hard to contribute patch to foss tool in general.
| There is no substitution for agile development team.
|
| DonHopkins on Feb 6, 2017 | root | parent [-]
|
| Oh I certainly wanted to contribute to the VLC project and
| integrate it into my own projects, but after having my
| concerns that I wrote up in great detail flippantly dismissed
| with such contempt, and seeing how the exact same thing
| happened to other users reporting legitimate longstanding
| bugs who were brushed off and ignored over so many years, I
| had no interest in contributing after that. It's fortunate
| that not every open source project suffers from such arrogant
| developers as VLC.
| lupusreal wrote:
| You've got some very confused beliefs about what mkv is and
| why it's used. Mkv is a container, not a codec, which is
| most often used to store lossy video and audio tracks. It
| can store lossless tracks too, but that is uncommon in
| practice. Other popular containers, such as mp4 (e.g.
| MPEG-4 Part 14), can also store lossless tracks.
|
| The biggest reason anime people prefer mkv to mp4 is
| because mkv supports the ASS/SSA subtitle format, which is
| favored by the anime subbing community for its extremely
| versatile formatting options. For instance, it is common
| for subbers to cover up signs containing Japanese text with
| translated subtitle text, tracked to the video, styled and
| transformed to appear virtually seamless. Less relevant but
| still important to some people, mkv supports a plethera of
| old (and very lossy) video codecs, which is sometimes
| relevant when it comes to repackaging old encodes of hard
| to find media. Being able to copy in the old video codec
| without transcoding preserves what little quality there is
| while allowing you to package it with modern subtitles. Mkv
| also has superior support for chapters, metadata, etc.
|
| But I get it, you hate anime and think weebs are pervs. I
| thought you were a man who values tolerance highly, but
| whatever man. It has little bearing on technical matters.
| Incidentally, anime people generally favor mpv above VLC,
| because the ASS/SSA support is a lot better in mpv (mpv
| uses it for rendering the psuedo-GUI.)
|
| As for the bugs and UX issues in VLC, I assume that your
| claims are more accurate than your understanding of media
| containers, but VLC is nevertheless the best video player
| to recommend to nontechnical users you might find yourself
| playing tech support for. They won't tinker with it and
| therefore won't discover most of the issues you're talking
| about. What they'll get out of it is a media player that
| plays whatever file they throw at it, without feeling the
| need to run sketchy "codec packs" they found god knows
| where on the internet.
| DonHopkins wrote:
| Those aren't my confused beliefs, I was literally quoting
| the text at the links.
|
| And you don't have to be so defensive by jumping to
| conclusions that I hate "weebs" and think they're all
| pervs (although the ones obsessed with sexualizing little
| girls are certainly misogynistic pervs). What I hate is
| spending precious time and effort catering to small
| groups of people obsessed with particular fetishes
| (perverted and misogynistic or not), at the expense of
| prioritizing solving the real problems of large groups of
| people suffering from particular egregious bugs and
| usability issues.
|
| Remember: it's been A DOZEN YEARS since I reported the
| problems in great detail with step-by-step instructions
| to reproduce them, and they STILL haven't fixed those
| problems that I and other people reported. Maybe refusing
| to ever acknowledge or fix those horrible bugs is Remi
| Denis-Courmont's way of getting revenge on me for hurting
| his feelings by posting a wall of text he claims he
| didn't bother to read, at the expense of all of his other
| users and the quality and usability of VLC, so now I'm
| sorry I ever took the time to try to help by reporting
| and documenting the bug, and I'll never do that again,
| but he still seems pretty arrogant and thin skinned to
| me, even quite recently. And VLC's user interface STILL
| sucks.
|
| Edit: The link I'm quoting is myself, quoting the text in
| another link written by SOMEONE ELSE. Literally, the VLC
| release notes, and an anime discussion about MKV which I
| read before I quoted it, so I already fully understand
| what you're mansplaining to me, and I'm not complaining
| about cartoon porn or MKV, I'm complaining about idiotic
| priorities. I'm sorry I touched a nerve that triggered
| you, but I don't hate "weebs" or porn, just misogyny and
| child abuse and terrible user interfaces. If you want to
| argue in favor of those things, go back to 4chan.
| lupusreal wrote:
| The link you're quoting is _yourself_ , complaining about
| anime porn and asserting that mkv is popular because it's
| lossless.
|
| Mkv really has nothing to do with VLCs usability
| problems. You're just grinding an axe against it because
| it's not a feature you value (or seem to even understand)
| but is valued by people you have evident disdain for (why
| even bring pornography into the discussion?)
| danadam wrote:
| > "I'll be waiting for your patch. Surely you're not as
| lazy and incompetent as the existing volunteer
| developers."- Remi Denis-Courmont
|
| > I see Remi Denis-Courmont's arrogant attitude and
| disrespect for users and developers hasn't improved in all
| these years.
|
| That's out of context quote:
| https://news.ycombinator.com/item?id=41282178
| hatsunearu wrote:
| Wonder how mpv deals with backwards step in infinite GOP/long
| GOP situations.
| darby_nine wrote:
| > Like said earlier codec frame access is very problematic
|
| Wow. Talk about not understanding the user.
| justin66 wrote:
| The developer responds to a comment:
|
| _But many players are able to do it for years._
|
| with:
|
| _If it 's so easy, why are you not doing it?_
|
| He's not just a butthole, he's a stereotypical open source
| developer butthole. On the other hand, if he worked for
| Microsoft, he'd be claiming that it takes a PhD to do it...
| Levitating wrote:
| In his defense, some commenters had a pretty rude attitude.
| You cannot demand developers to implement a feature or call
| them out on being lazy.
|
| Nobody even offered to research how other players accomplish
| this. They just expect that because they believe it can be
| done someome should do the work for them.
|
| At least Remi was actually andering questions on the forums.
|
| This attitude towards open source maintainers is what's
| getting them all burned out.
| KingMob wrote:
| As a FOSS maintainer, I have sympathy for him, but as a
| communicator, I see he really failed to address multiple
| commenters pointing out that several other FOSS video
| projects had the feature. (At least in the first page of
| comments.)
| IshKebab wrote:
| I don't think the other people commenting were being at all
| rude. They asked nicely if a feature would be possible. He
| replied with a blank "No" and from then on it was pretty
| much "but other players can do it so it must be possible"
| and him rudely and incorrectly asserting that it isn't and
| that anyway if it was why don't they do it if they want it
| so much.
|
| The _correct_ response would have been something like
| "it's more difficult to do and in some circumstances it
| will have very bad performance so we haven't done it yet".
|
| This is classic "It's hard and I can't be bothered so I'll
| make up some technical reason why it's impossible".
| Programmers do this _all the time_ and it 's kind of
| annoying.
|
| (And yes I understand video coding and I know why it's more
| difficult in some cases.)
| hobofan wrote:
| I think the answer (read from between the lines) is more:
| "There is no way to make it work for the general case of
| all video formats, and we don't implement a feature
| unless it works for the general case, so we choose not to
| implement it at all. If that means that we don't have
| that feature for the file formats where it would works,
| that's a sacrifice that we are willing to take."
| IshKebab wrote:
| Agreed, and this is actually a really good point:
|
| > we don't implement a feature unless it works for the
| general cas
|
| I used to make that mistake a lot. My boss would say "can
| we do _this_ ", for example report memory usage per
| operation. And I would say "no because sometimes memory
| is shared between operations so it would be meaningless".
| In other words I couldn't do it perfectly so I said we
| couldn't do it at all.
|
| That's what the VLC guy is doing and I didn't realise
| until I worked with that boss that it is COMPLETELY
| WRONG!
|
| Just because you can't do it perfectly doesn't mean
| giving up entirely is the best you can do. In cases like
| this you can _absolutely_ do something that works
| sometimes but not in _every_ case and that is way better
| for users than just giving up.
|
| Lots of programmers fall into that trap though.
| Levitating wrote:
| VLC is able to abstract over a ton of extremely
| complicated codecs by providing some common tools that
| work for all of them.
|
| I guess if VLC has a feature, you can always expect it to
| work. That's their design choice. There's nothing
| "COMPLETELY WRONG" about that.
| spoaceman7777 wrote:
| The most entertaining part of this thread is that VLC is
| actually in the process of replacing its backend with the
| mpv-derived libplacebo.
|
| In the end, VLC has admitted defeat
| account42 wrote:
| Both use FFMPEG anyway so it's not like VLC's codec
| abstraction was really something that sets it apart.
| account42 wrote:
| Exactly an in this case it even works 99.99% and VLC
| already has a related feature (seeking to a specific
| time) that has pretty much the same codec requirements.
| account42 wrote:
| Except even that answer makes no sense since VLC
| implements time-based seeking which has the same
| requirements as seeking to a specific frame number. The
| only additional part to implement is automatically
| skipping forward a number of frames after the closest
| preceeding seek point.
|
| Adding a requirement of supporting this perfectly with
| literally all formats you can think of is not reasonable
| at all since a video player that stuck to that principle
| would not be able to support any controls at all. It's
| the kind of bullshit excuse developers or corporations
| like to give when they don't _want_ to implement
| something but also don 't want to be honest about that.
| brettermeier wrote:
| He really sounds like an asshole :D sorry for this stupid
| comment, but i had to tell.
| The_Colonel wrote:
| The dev said they are happy to accept patch for this feature.
| Remember that you're not entitled to demand new features, as
| a (non-paying) user, you can't allocate dev's time to work on
| what you want.
| imiric wrote:
| This card is played too often by developers who only want
| to work on features they personally find interesting or
| worthwhile.
|
| Yes, you realistically cannot implement everything every
| user wants, but at the same time your software is meant to
| solve problems. Keeping direct communication with your
| users, and understanding what they find useful or not,
| should be the driving force of the design and features of
| your app.
|
| FWIW, I've been on both sides of this discussion, as an OSS
| maintainer and user, and have experience with demanding
| users and arrogant and, yes, _lazy_ developers alike. Let's
| stop the narrative that users don't have the right to
| request features because they're not paying customers, and
| that this is driving developers to burn out. Communication
| is key to producing useful software regardless of its
| license. OSS development in particular is not just about
| throwing some code online and forgetting about it.
| mnsc wrote:
| You have been a maintainer and yet you said "your
| software" instead of "the software you are maintaining".
| When you maintained an OSS project, did you accept pull
| requests from lots of contributors or was it a solo show?
| If so, did you get burned out?
| umbra07 wrote:
| A FOSS project can be FOSS and refuse all other
| contributions. FOSS does not make any requirements
| towards how the creator/main contributor handles and
| treats users, submitted patches, and feature requests. So
| no, FOSS users have zero inherent right to request
| _anything_ - until the creator allows for it.
|
| I agree that taking that kind of "closed" approach is not
| helpful.
| imiric wrote:
| > A FOSS project can be FOSS and refuse all other
| contributions.
|
| It can, yes. There's nothing preventing it, except that
| it's a shitty way to work in the open, and you may as
| well make the project proprietary or source available.
| The maintainers might have their own vision of the
| project direction, and they may reject contributions, but
| refusing contributions outright is how forks are made.
| Nothing wrong with that either, but usually the projects
| that are more receptive and responsive to user feedback
| are the ones that users and developers gravitate towards.
| zem wrote:
| > developers who only want to work on features they
| personally find interesting or worthwhile.
|
| you say that like it's a bad or even a surprising thing.
| for a lot of people that's the entire point of open
| source development - in their day jobs they do what they
| are required to do for the company that pays them, and
| then in their own open source projects they can do what
| genuinely interests them.
| imiric wrote:
| Why bother releasing OSS at all then? What do developers
| who don't want to listen to their users honestly gain
| from this? Padding on their resume?
|
| If you just wish to solve your own problems, build things
| for yourself and keep it private. If, on the other hand,
| you want to help others and make your software public,
| then do right by the people who decided to try your
| software and listen to what they have to say.
|
| How anyone can defend the attitude of the VLC developer
| in the thread linked above is beyond me.
| BeFlatXIII wrote:
| You release it to the public so other developers can
| stand on the shoulders of giants when it's time to
| scratch their itch, instead of wasting time re-
| implementing the basics. Why did this need explained?
| commodoreboxer wrote:
| Imagine finding a piece of art you like, but finding a
| minor anatomy flaw. When you point it out, the artist
| says they aren't going to fix it, because the piece is
| finished, and it would be impossible for them to do it,
| you point out that other artists have touched up their
| finished pieces, and they tell you to do it yourself,
| then.
|
| Why is the artist obligated to do the work you think they
| should do? Why, if they don't do this work, should they
| be obligated to not release their work publicly?
|
| FOSS is not an obligation to do everything that every
| user wants you to do. It's not an obligation to even
| communicate with those users. In fact, it comes
| explicitly with no warranty, even for fitness for any
| purpose.
|
| The developer is a poor communicator, but how anybody can
| be defending those annoying, entitled, lazy users is
| beyond me.
| boomlinde wrote:
| _> Yes, you realistically cannot implement everything
| every user wants, but at the same time your software is
| meant to solve problems._
|
| It's a question of whose problems. It's highly unlikely
| that we perceive the same problems in the same order of
| priority, so why should I donate my time to _your_
| problems when I am already wishing for more time to
| implement the solutions to _my own_? In commercial
| software there 's an obvious incentive to work on
| features that are in demand by people who will pay for
| them. Expecting people to act like that incentive still
| exists even when it doesn't is insane.
|
| _> I 've been on both sides of this discussion, as an
| OSS maintainer and user, and have experience with
| demanding users and arrogant and, yes, _lazy_ developers
| alike._
|
| The gall to call someone who doesn't want to work on your
| problems for free "lazy"... Now imagine that you
| voluntarily participate in a very active OSS project and
| there are tens of people like you who extend that massive
| middle finger over and over whenever they can't convince
| you to donate a work week to their esoteric dream
| feature.
|
| _> Let 's stop the narrative that users don't have the
| right to request features because they're not paying
| customers, and that this is driving developers to burn
| out._
|
| The "narrative", again, is "that you're not entitled to
| demand new features, as a (non-paying) user, you can't
| allocate dev's time to work on what you want." This is
| the card you insist is played too often, not that "users
| don't have the right to request features". I don't see
| how you could honestly get these two things mixed up.
|
| _> Keeping direct communication with your users, and
| understanding what they find useful or not, should be the
| driving force of the design and features of your app._
|
| Who are you to decide what should motivate me?
| account42 wrote:
| Users _don 't_ have a right to requrest features but as a
| maintainer you are shooting yourself in the foot if you
| act like Remi here.
| latexr wrote:
| > The dev said they are happy to accept patch for this
| feature.
|
| Did they? Because I read a bunch of the thread and "happy"
| is he last word I'd use to describe the developer's
| sentiment. All I see is "let's see you provide a patch, and
| I don't believe you will".
|
| Everything about it screams that if a patch were provided,
| they'd do anything in their power to find reasons for
| refusal.
|
| Even if I cared about VLC, reading those replies guarantees
| I would never attempt to submit the patch.
| thiht wrote:
| > The dev said they are happy to accept patch
|
| No he didn't.
| thrdbndndn wrote:
| You need to send an email to the admin and ask for approval
| in order to register an account on VLC website to report
| bugs.
|
| This says it all.
| fragmede wrote:
| It says it's a project on the Internet that has to deal
| with spam. Are you reading more into it than that?
| usr1106 wrote:
| That's the result of being successful for wide non-
| technical audience. The signal over noise would approach
| zero if everybody could create a bug report when something
| does not work as they wanted.
|
| Have you tried to create a meaningful bug report (not
| feature request) that has not been previously reported and
| were rejected? If so your complaint is valid. I haven't so
| I don't know.
| thrdbndndn wrote:
| > The signal over noise would approach zero if everybody
| could create a bug report when something does not work as
| they wanted.
|
| I hear you, but it could be something not so extreme.
| Lots of even more popular projects work fine with bug
| reporting system on GitHub, which everyone has access to.
|
| > Have you tried to create a meaningful bug report (not
| feature request) that has not been previously reported
| and were rejected?
|
| No I don't, I just want to subscribe to the issues I
| care, which you can't do without having an account..
| anigbrowl wrote:
| I'll be happy to switch over to MPV for this alone. VLC is
| great in general, but lacking some basic features. This sort of
| 'not possible' nonsense from developers is always a sign of a
| project's long-term decline.
| mnsc wrote:
| "not possible" is as much nonsense as "everything is
| possible". Is it possible for vlc to implement support for
| rendering and editing common 3d object models? Yes! But is it
| possible given what vlc was set out to do? No!
|
| I think another sign of a projects long term decline is
| developers that are all too happy to expand the scope of the
| project. If that happens I just know that down the line the
| feature I started using the software because of is down
| prioritized due to the "need of supporting markdown in the
| email editor" when the software started as a MSN chat
| archiver.
| thiht wrote:
| So you're saying going forward 1 frame in a video is in the
| scope, but going back 1 frame is out of scope. Weird
| stance.
| mnsc wrote:
| If that feature would introduce a need to reactor or re-
| architect major parts of the the logic since everything
| has been built with the purpose of the playing video
| forwards supporting as many codecs as possible. Then,
| yes. And as a long time user of vlc video playback (and
| transcoding) I have never wanted to go back one frame. I
| always wanted to go back like 15 seconds, and that has
| worked forever.
| thiht wrote:
| > I have never wanted to go back one frame
|
| Good for you I guess? I have never wanted to go forward
| one frame so let's remove that too
| mardifoufs wrote:
| Sure but that's completely different than claiming that
| it's out of scope or technically impossible. And that's
| completely different than your earlier example of
| implementing 3d rendering or something like that. They
| could just say that they don't want to do the feature, I
| think the pain point here is the claim that it is not
| possible.
| mnsc wrote:
| Of course it's possible, that's my point. Both the
| maintainer and the requestors should avoid that word. The
| real questions are. Is it reasonable? Is it worth it? Is
| it along the lines of the problems the software set out
| to solve?
| account42 wrote:
| VLC supports seeking to arbitraty time points (as long as
| the codec provides the neccassry data). Adding seeking to
| specific frames on top of that is hardly scope bloat.
| anigbrowl wrote:
| I see your point, but frame advance/rewind is very very
| basic stuff, a feature that has been around since VCRs went
| on sale to consumers in the 1980s. Doing it on digital
| videos with intraframe compression obviously requires some
| memory tradeoffs, but it's inarguably core functionality
| for a video playback application.
| varenc wrote:
| Slightly related: mpv also has excellent backward playing
| capability! Of course video encodings aren't optimized for this
| so it does some work to make the performance reasonable.
| ThrowawayTestr wrote:
| You can press e to frame advance. Can't go back though.
| romanows wrote:
| I was hoping that mpv would work a bit better than vlc for
| sending video to chromecast, but unfortunately, another
| similarly amusing thread: https://github.com/mpv-
| player/mpv/issues/177
| latexr wrote:
| Far from me to defend the whole mpv team[1], but the dev in
| that thread is a ghost (deleted user). I remember them, they
| were always rude and eventually got kicked out of the project
| and loudly complained about "being removed from the project
| [they] created". I never found the exact reason why, though I
| can't help but think the attitude had something to do with
| it.
|
| [1] Some are quite nice and competent. Others are exceedingly
| rude and will e.g. jump on an issue that had thus far been
| entirely cordial just to, without provocation, insult users
| for using whatever OS they don't like.
| throwaway11747 wrote:
| The last issue that caused them to leave was their desire
| to move mpv to their own build system, which they believed
| they could write in a weekend. Other mpv developers thought
| that was a stupid idea and argued in favor of something
| more standard, such as meson. That was the last straw for
| both sides.
| latexr wrote:
| > their own build system, which they believed they could
| write in a weekend.
|
| That doesn't seem right:
|
| > (...) I started this over a year ago (...)
|
| https://github.com/mpv-
| player/mpv/pull/7801#issuecomment-641...
|
| > Other mpv developers thought that was a stupid idea and
| argued in favor of something more standard
|
| That doesn't seem right either. I just read the whole PR
| thread and I see a bunch of _users_ arguing for it, not
| other maintainers.
|
| The maintainer was certainly controversial and I found
| several commits and bad decisions which look to be almost
| universally hated, but it's not clear to me this specific
| problem was what caused them to quit or that it was
| motivated by other maintainers.
|
| If you could provide a source for your claim, it would be
| appreciated.
| sureIy wrote:
| Ghost is my soulmate. As a OSS maintainer, I feel that.
|
| Not a week goes by without some random dude coming to my
| repos _expecting_ I implement whatever they ask, or else be
| called a dick.
|
| Particularly: you don't have to use mpv if it doesn't do what
| you want it to do, and don't bust my ** because of it.
| latexr wrote:
| > Ghost is my soulmate. As a OSS maintainer, I feel that.
|
| You also close issues without even trying to understand
| what they're about?
|
| https://github.com/mpv-
| player/mpv/issues/177#issuecomment-29...
|
| https://github.com/mpv-
| player/mpv/issues/177#issuecomment-62...
|
| > some random dude coming to my repos expecting I implement
| whatever they ask, or else be called a dick.
|
| If that's what you took from that discussion, I sincerely
| recommend you take a break. You may be experiencing
| burnout. It's of course your choice to not implement
| something you don't want in your project, but let's not
| pretend everyone making a request, _especially people who
| have shown research_ are dicks out to get you.
|
| I tell you this as fellow open-source maintainer. I've
| learned over the years that if people opening issues are a
| frequent source of frustration, the first step is to
| investigate how I can make that less of an issue (e.g.
| using a GitHub template that forces a specific kind of
| action) and secondly realise that I need some distance and
| to relax. When you feel like everyone is an asshole, it's
| probably just you.
|
| By the way, that maintainer in particularly was known for
| lashing out at the smallest things and being rude
| unprovoked. Perhaps consider reading more of the history
| before calling them your soulmate.
| sureIy wrote:
| No man, you don't understand. I take every step possible
| to avoid people opening issues, they just either
| disregard the 4 steps between the problem and the GitHub
| issue, or just come out swinging saying I should just
| implement it "because many people want it" or I should
| suggest an alternative. My issue template specifically
| says "do not request this feature" and they still delete
| it and request it.
|
| I have no patience for people who are assholes and you
| shouldn't either. They're blocked on sight and that's how
| I deal with them.
|
| You say "unprovoked", I see people completely
| disregarding _my_ wellbeing by telling me how to spend my
| free time and how to design my product.
|
| > Perhaps consider reading more of the history before
| calling them your soulmate.
|
| I don't need to judge a person by his whole life, I'm
| just talking about that specific issue as it matches my
| experience as described above.
| latexr wrote:
| > My issue template specifically says "do not request
| this feature" and they still delete it and request it.
|
| If they can delete it, that's the first problem you
| should fix. Don't use the old style of GitHub templates
| where it just dumps a bunch of prewritten text. Use the
| modern style with the YAML template that makes a GUI
| form.
|
| You can have mandatory checkboxes which say "I am not
| requesting [feature]", with a link to some other document
| explaining why something won't be implemented. Add
| another with "I understand my issue will be closed
| without review and I will be blocked if I don't follow
| this guide". Finally, disable free-form issues. Only
| allow people to go through the templates.
|
| > You say "unprovoked", I see people completely
| disregarding _my_ wellbeing
|
| I thought it was pretty clear I was talking about the
| maintainer from the issue, not you. I don't know if you
| were unprovoked or not, I know this maintainer wasn't.
|
| > I don't need to judge a person by his whole life
|
| In general, sure. But when calling someone a soulmate...
| That implies a deep level of connection, not one event.
|
| Anyway, could you clarify exactly in which way you see
| the people in this issue being assholes, particularly
| before the maintainer arrived and closed the issue
| without even beginning to understand the request?
|
| > No man, you don't understand.
|
| I maintained large open-source projects you definitely
| heard of, and today continue to have to deal with these
| kinds of requests daily. If you think the initial
| requests in this issue are enough to call these people
| "assholes" and that they're being disrespectful to the
| maintainer's well being, I maintain you should take a
| break. One of the signs of burnout is seeing every little
| comment as a personal attack. I know, I've been there.
| Stop accepting requests and take a vacation from it. Or
| even stop entirely. Have empathy for yourself and regain
| empathy for others. I wish you the best.
| sureIy wrote:
| > that's the first problem you should fix.
|
| But you see how this is a battle against stupid people? I
| also had checkboxes before for other issues, people still
| blindly check them.
|
| There is no winning. If people insist that they're right
| and that I'm rude for closing the 25th issue that, ahem,
| _reading 5 words_ would have avoided, I just block them
| and move forward.
|
| > seeing every little comment as a personal attack
|
| I'm patient when people open duplicate issues because
| they couldn't find them, but this is different.
|
| Imagine you're talking to someone in person and you tell
| them "please don't eat the cake" straight to their face,
| 4 times on the way to the kitchen. Then 5 minutes later
| they yell at me asking why the cake tastes like cardboard
| and glue.
|
| Is that not completely disrespectful? I very much doubt
| you'll think of them highly after that accident, unless
| they're 5 year olds.
|
| > in which way you see the people in this issue being
| assholes, particularly before the maintainer arrived and
| closed the issue without even beginning to understand the
| request?
|
| I was talking about my own experience. As for him, it's
| clear that he did understand the issue and he did not
| agree that it should be part of the player, for several
| reasons he then went on to explain.
|
| I also get why one would want a player to also be able to
| cast videos, but then his suggestion to just use libmpv
| in a caster app made complete sense.
| sureIy wrote:
| For entertainment purposes, I'll give you another example
| of someone I encountered on my repos.
|
| One guy opens 2 extremely long and conversational issues
| describing how my software is really ugly and it should
| be more like other software. Then went ahead suggesting
| that the other developer hasn't updated his software for
| a while because _he got lazy_ (their words), so I should
| just rip his code and improve it, disregarding mine.
|
| This went back and forth for a while, eventually arriving
| at the solution they wanted: that miraculous feature I
| don't want to implement and that they knew I didn't want
| to implement. Closed and locked both issues, so they
| opened another one.
|
| What am I supposed to do? I said no and you keep saying
| you know better.
|
| Is it because I'm burned out or because they're the usual
| OSS user who has nothing to offer and a lot to expect?
| throwaway11747 wrote:
| It's a former developer that's no longer affiliated with the
| project since 2021 or thereabouts. They did not part on good
| terms because he behaved in the same way towards other mpv
| developers, "my way or the highway".
|
| So you probably shouldn't let anything that old sour your
| opinion on the current mpv.
|
| (I don't belong to either side, just have been using the
| player since its inception.)
| account42 wrote:
| This isn't remotely similar. Nowhere is the MPV developer (
| wm4) being unreasonable in that thread. And while wm4 was not
| exactly known for interpersonal skills, he was rarely wrong
| unlike Remi in this case in claiming things to be impossbile
| when they are not.
| a-dub wrote:
| i can imagine how it would be annoying in a system that is
| designed to process live streams as opposed to one that is
| designed to have random access to the stream via persistent
| storage.
|
| if the target frame were not an i frame, you'd have to dig up
| the preceding i frame and replay everything up to the target
| frame. pretty easy for random access, not so much for a
| monotonic stream of frames.
| plq wrote:
| Quote from that thread:
|
| > It can be added in theory, but there would be certain
| problems. Like said earlier codec frame access is very
| problematic (I, P and B frames), because in worst case scenario
| you have to decode about 248 sequential Full HD H.264 frames
| before you can get previous image (so there will be major LAG).
|
| Having used the 'previous frame' feature in mpv, I suspect this
| is exactly how it's implemented.
| breck wrote:
| This thread is amazing. Thanks for pointing it out.
|
| What's lovely is that it is indeed possible, but not trivial,
| and you can see Remi is sort of baiting to catch smart talented
| programmers to the project.
|
| You can see the patience and long term horizon needed to lead a
| volunteer open source project. Time to study VLC more.
|
| Thanks!
| thiht wrote:
| Yeah he's probably playing 5d chess, not just being an ass
| account42 wrote:
| I don't see Remi's behavior in that thread attracting more
| developers than it pushes away.
| PUSH_AX wrote:
| That guy sounds like a nightmare to work with.
| IndySun wrote:
| That is one funny, informative read! Although, the first
| response, I feel, aught to have been 'non'. I can hear it now.
| hatsunearu wrote:
| What really sucks ass is mpv doesn't have features to show what
| the frame count of the frame you're looking at is.
| throwaway2037 wrote:
| Wow, reading this now very old discussion makes me cringe a
| little bit when I see dingers like these: >
| If you think it is easy, VLC is open-source: you are welcome to
| provide the easy patch. Somehow, I won't be holding my breath.
| > 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.
| > And I don't take moral lesson from an hypocrit who feels like
| they can demand work from "toxic" volunteers and even state
| that they are not there to do any actual work.
|
| There are so many (passive-)aggressive comments in that
| discussion. This is the primary reason why I never get involved
| with open source projects any more. The discussions are so
| toxic. I always wind up feeling terrible about myself after
| "trying to help" an open source project by reporting bugs or
| submitting patches to fix bugs.
| account42 wrote:
| That was an interesting read.
|
| - Great example of letting perfect be the enemy of good.
|
| - Hilarious example of a developer making claims of what users
| want while ignoring the users in front of him.
|
| - Shows how CoCs can be and often end up being used in toxic
| ways.
|
| Is Remi the sole active developer or why did no other dev chime
| in to defuse the discussion?
|
| I'm all for open source projects sticking to their vision and
| standing up to unreasonable user demands but it really is in
| your own best interest as a developer to learn to communicate
| effectively - and keep an open mind for feature requests that
| sound unreasonable to you and first make sure if you understand
| what is being asked for.
| lights0123 wrote:
| libmpv is also amazing. It's a simple C API that allows you to
| render each frame into an OpenGL framebuffer or pixel array,
| using a fully hardware-accelerated path for the former.
| preisschild wrote:
| Love the use of one of the best Kubrick scenes IMO on the main
| site
| YuccaGloriosa wrote:
| I added a hotkeys for change subtitles scale...well worth it
| xwall wrote:
| Does anyone here know more features that MPV offers that VLC and
| MPC don't, considering they are all free and open-source?
| rafaelgoncalves wrote:
| Like anothers comments said, mpv has some awesome native hw
| decoding and you can play frame by frame, previous and next,
| vlc you can only do next [1] (awesome thread btw). :) And
| mpc/mpc-hc is discontinued [2].
|
| [1] https://news.ycombinator.com/item?id=41278203 [2]
| https://news.ycombinator.com/item?id=41277818
| SirMaster wrote:
| mpc-hc is not discontinued.
|
| https://github.com/clsid2/mpc-hc
|
| Plus there is also mpc-be which is actively developed and
| pretty much the same.
|
| https://github.com/Aleksoid1978/MPC-BE
| dither8 wrote:
| In my input.conf file I've created filter keyboard shortcuts:
| F1 af toggle "acompressor=ratio=4,loudnorm" F2 vf toggle
| "bwdif"
|
| First one is an alright dynamic range compressor (makes the loud
| parts quieter and quieter parts loud). Second is a deinterlace at
| default settings. These are standard ffmpeg filters and mpv let's
| you turn these on in real time.
| azizLIGHT- wrote:
| I amalgamated some audio filters to cycle through on a F1 press
|
| - Loudness Normalization:
| "lavfi=[loudnorm=i=-14.0:lra=13.0:tp=-1.0]"
|
| - Loudness Normalization + Mild Tinnitus Filter: "lavfi=[loudno
| rm=i=-14.0:lra=13.0:tp=-1.0,equalizer=f=6000:width_type=o:w=2:g
| =-20]"
|
| - Mild Tinnitus Filter:
| "equalizer=f=6000:width_type=o:w=2:g=-20"
|
| - Aggressive Tinnitus Filter: "equalizer=f=4000:width_type=q:w=
| 1:g=-30,equalizer=f=6000:width_type=q:w=1:g=-30,equalizer=f=800
| 0:width_type=q:w=1:g=-30"
|
| - Bass Reduction: "bass=f=210:g=-17.7"
|
| - Alternative Loudness Normalization: "loudnorm=linear=no"
|
| - Dynamic Audio Normalization: "dynaudnorm=s=0"
|
| - None: ""
|
| F1 cycle-values af "lavfi=[loudnorm=i=-14.0:lra=13.0:tp=-1.0]"
| "lavfi=[loudnorm=i=-14.0:lra=13.0:tp=-1.0,equalizer=f=6000:widt
| h_type=o:w=2:g=-20]" "equalizer=f=6000:width_type=o:w=2:g=-20"
| "equalizer=f=4000:width_type=q:w=1:g=-30,equalizer=f=6000:width
| _type=q:w=1:g=-30,equalizer=f=8000:width_type=q:w=1:g=-30"
| "bass=f=210:g=-17.7" "loudnorm=linear=no" "dynaudnorm=s=0" ""
|
| https://reddit.com/r/mpv/comments/xf8p9t/movie_volume_compre...
|
| https://pastebin.pl/view/2f48e64c
| Klover wrote:
| Instead of using 2 compressors in tandem, it might be better to
| set the very good one to your preference: F1 af
| toggle "loudnorm=I=-14:LRA=1:tp=-1:linear=false:dual_mono=true"
|
| The I=-14 is the target 'volume', which makes it as loud as
| YouTube and Spotify, setting it to -23 will be much quieter,
| but gives you more dynamic range. LRA=1 goes from 1-50, with 1
| being the most compressing which is probably what you want in
| this case. TP=-1 sets the limiter to -1dB, which is plenty of
| clipping threshold because loudnorm calls the resampler for
| 192kHz before working in dynamic mode. Linear=false because we
| use dynamic mode here and cannot even use linear mode.
| Dual_mono=true makes -14 as loud for mono as stereo sources.
|
| Since loudnorm adjusts volumes and sets limits for you, you can
| forego mpv's audio downmixing _if your target is stereo_ and
| simply put all your channels together before bringing them to
| loudnorm: F1 af toggle "pan=stereo|c0=FC+LFE+FL
| +BL+SL|c1=FC+LFE+FR+BR+SR,loudnorm=I=-14:LRA=1:tp=-1:linear=fal
| se:dual_mono=true"
| dbcooper wrote:
| What are the best upscalers for MPV these days?
| chungy wrote:
| I default on ewa_lanczossharp; it does pretty well at upscaling
| normal SD video to modern resolutions.
|
| I also often use oversample, for video game footage and whatnot
| where I want all the pixels to be not blurry.
| KenHV wrote:
| profile=high-quality
| loeg wrote:
| mpv is the most active fork/evolution of the historical "mplayer"
| player of yesteryear. I've been using this program in one form or
| another for probably 20 years now. It's great; highly recommend.
| newsclues wrote:
| I started using it after the latest Ubuntu version broke VLC, and
| am quite pleased
| devwastaken wrote:
| The only player that has proper HDR playback support and proper
| HDR to SDR conversion plus GPU accel.
| FrostKiwi wrote:
| Cannot recommend --video-sync=display-resample enough. The one
| reason I use mpv on every OS over every other media player
| navigate8310 wrote:
| Can you explain what it does?
| shmerl wrote:
| > Resample audio to match the video. This mode will also try
| to adjust audio speed to compensate for other drift. (This
| means it will play the audio at a different speed every once
| in a while to reduce the A/V difference.)
|
| I'm not sure what's the benefit of that is though.
| literallycancer wrote:
| Doesn't it already keep the audio in sync by default? What's
| the difference with this option?
| lossolo wrote:
| Does anyone else have a problem with it on Mac when trying to
| open videos using the 'Open With' dialog in Finder? I see it
| start for a second, and then it just quits. It works properly
| from the command line
| npteljes wrote:
| My default player is VLC, because it's a great generalist for
| video, audio and video inputs, but I appreciate mpv very much
| too. Especially useful on CPU limited devices, I get more
| performance out of it than any other player.
| solegrammarian wrote:
| Licensed on a GNU General Public License (GPLv2+) except for the
| /video/out files which appear to be either unidentifiable or
| proprietary code rewritten from nVidia, and another unnamed
| company's repository.
| opan wrote:
| mpv is one of my favorite pieces of software, incredibly useful
| and high quality, enjoyable to use. Right up there with (neo)vim,
| openssh, tmux.
| omeid2 wrote:
| The MPV of images for linux is IMV: https://sr.ht/~exec64/imv/
| kelvie wrote:
| with a couple of lines in ~/.config/mpv/mpv.conf, mpv is the
| mpv of image viewers:
|
| image-display-duration=inf autofit-larger=100%x100%
| slmjkdbtl wrote:
| Love the scripting system. I spend 100% my time to write scripts
| for mpv and vim and 0% for actual work.
| Perroboc wrote:
| If using KDE, I recommend Haruna as a frontend. Really easy to
| use!
| varenc wrote:
| I absolutely love mpv. And if you have a Mac check out IINA. It's
| just a relatively thin GUI over the mpv core.
| dsp_person wrote:
| I love their section on how to embed mpv in other apps [1]. Too
| bad there's not an XEmbed equivalent for Wayland [2].
|
| [1] https://github.com/mpv-player/mpv-
| examples/blob/master/libmp...
|
| [2] https://github.com/mpv-player/mpv/issues/9654
| feverzsj wrote:
| Libmpv also has a much better api than libvlc.
| tobyhinloopen wrote:
| MPV can play stuff VLC can't, and it's HDR support is superior
| gorgoiler wrote:
| This is an extremely venerable project, formerly known as
| mplayer. There are _half a million_ commits going back to 2001,
| and that's just from when the CVS repo was converted to
| Subversion.
|
| streamlink and mpv on a fanless Minix z100 running Ubuntu was a
| nigh-on perfect Olympics experience.
|
| https://streamlink.github.io/
|
| https://www.minix.com.hk/products/z100-0db-fanless-n100-mini...
| thrdbndndn wrote:
| I don't think mplayer and mpv are the same thing. It forked
| mplayer (among others), but mplayer is still its own thing.
| smeg_it wrote:
| I switch from mplayer to mpv some years ago but I don't
| remember when. I use it daily as my media center player.
| ctenb wrote:
| I love mpv. But when I pause and resume the video, the first few
| seconds are jittery. I've not encountered that on other players.
| Does anyone know why this is?
| Aardwolf wrote:
| For me I have that with VLC and MPV is the stable one (in
| Archlinux). In my experience, trying different sound output
| device or module settings sometimes fixes such issues (and
| usually pulseaudio is the laggy one)
| ctenb wrote:
| Both sound and video are stuttering for me, would that still
| be caused by audio issues?
| Aardwolf wrote:
| These two do seem connected, at least in my case, maybe the
| video is waiting for the audio codec. Of course your issue
| could be something entirely different than what I'm
| typically encountering!
|
| I have like 3 things trying to be audio device on my linux
| (of which the graphics card is the most unwanted one and
| sometimes it randomly manages to take over despite me not
| changing any settings) and the list of audio modules that
| show up is simply enormous (pulseaudio, pipewire, alsa,
| ...), some of those make VLC stutter, others don't. It's a
| mess but at least pipewire works better than puseaudio in
| my case...
| Simon_ORourke wrote:
| Awesome, any open-source cross-platform media player is always
| welcome in my setup!
| ho_schi wrote:
| You can use mpv on the framebuffer-terminal.
|
| Pass the option _--vo=drm_ and it works flawlessly with free
| drivers for AMD, Intel or Nvidia.
| kinibha wrote:
| Using for last couple of years, its best.
| ksdnjweusdnkl21 wrote:
| It sounds stupid but the killer feature for me is possibility to
| have multiple subtitles visible, all easily configurable with a
| few keybinds (track, offset, position, size etc). No streaming
| service provides this, and they actively omit subtitle languages
| that aren't "relevant" to your geolocation. I cannot respect a
| service like that.
| cenamus wrote:
| Especially for things like language learning they are amazing,
| but services like Amazon show like two (English and the local
| language) out of the 30 something they have available. And I
| won't even go into the difference of subtitles and dubbing...
| ksdnjweusdnkl21 wrote:
| For language learning there are some scripts that allow you
| to hover words and show translations for them. I haven't used
| them myself with mpv, but I found that kind of tools to be
| invaluable on a browser when learning a language with a
| foreign script.
| scbrg wrote:
| +1. This is a fantastic feature. I haven't even bothered
| learning the keybindings (perhaps I should), I just start with
| --sid1= and --sid2= and it works well enough.
|
| Neither me nor my significant other are native English
| speakers, but we have different native languages. I'm
| comfortable enough with English, but like having English
| subtitles since I have a hard time with some dialects and
| occasionally just miss a word or two due to noisy audio. My SO
| likes having subtitles in their native language.
|
| Being able to have multiple subtitles makes it possible for
| both of us to get the experience we like, at the cost of a
| little screen real estate. Well worth it.
| ksdnjweusdnkl21 wrote:
| They are not default keybinds, but like any configuration can
| be cycled or set at runtime. Actually I don't use the
| keybindings much directly since my default config usually is
| fine, but have a remote GUI to configure it when needed.
| OscarDC wrote:
| > actively omit subtitle languages that aren't "relevant" to
| your geolocation. I cannot respect a service like that.
|
| This may also be due to legal issues / restrictions in the
| contract they had with that content's right holders or
| subtitles providers.
| ksdnjweusdnkl21 wrote:
| They probably don't want to license them globally, because
| the expected usage is low. But surely this could be taken
| into account in the contract / negotiation. Anyway I guess
| I'm just not in the target audience. But that's what MPV is
| great for, it allows you to tweak it for that 0.1% use-case.
| hobofan wrote:
| I think it's also partially an issue with video + audio
| being paired by region.
|
| AFAIK, the video you are being served is always based by
| the geolocation and what video was licensed for that. E.g.
| in a French version of a movie, text in the movie may have
| been localized into french inside the video. Additionaly
| there might be additional/missing scenes in the localized
| version to get the desired age ratings in that market.
|
| The audio is then synced to that version of the video. That
| means that e.g. the French audio produced for the US video
| is not 1:1 the same audio as the French audio for the
| German video.
|
| So that takes it beyond a licensing issue, and would mean
| additional effort to produce compatible audio tracks for
| content that they may only have streaming rights for
| temporarily. For content native to the streaming service
| they usually put that effort in.
| iwishiknewlisp wrote:
| Mpv is great with subtitles. Not just being able to switch
| through subtitle tracks and configure positioning, but also
| being able to automatically find and play external subtitle
| files when playing a video. I wrote an article about this:
| https://www.baeldung.com/linux/mpv-subtitles-automatic. Only
| issue I found is the documentation for what subtitle formats
| are supported is lacking. You have to look through ffmpeg code
| to actually find what formats are actuallly supported.
|
| Additionally, https://subdl.com/ with
| https://github.com/alexanderwink/subdl is a great resource for
| finding and downloading subtitles from the comand line.
| pahn wrote:
| Mpv is great! And also the only player I found to be externally
| controlable, e.g. through a hardware jog/shuttle or an Arduino.
| This might be outdated (from 2018), but for reference (me talking
| to myself ;):
| https://softwarerecs.stackexchange.com/questions/53208/video...
| cranberryturkey wrote:
| For a web media platform checkout https://zymo.tv
| _V_ wrote:
| I switched to MPV years ago - for some reason VLC started to
| stutter when opening a file, which is quite annoying. It does not
| matter whether it is local ol remote file, format does not matter
| - every open and every seek will trigger this few-second long
| stutter.
|
| MPV does not do this, so over the years I began to use it as my
| daily driver.
| natrys wrote:
| This is S tier software. I remember using this on a laptop with
| 2gb RAM years ago. The combo of mpv and youtube-dl could deal
| with large number of sites (not just youtube), when even the
| browser struggled.
| Sporktacular wrote:
| I think youtube-dl is no longer under development. Any
| suggestions for an alternative?
| mzajc wrote:
| youtube-dl is still under development (last commit at the
| time of writing was 2 weeks ago), but there are forks with
| more features, such as yt-dlp.[1]
|
| [1] https://github.com/yt-dlp/yt-dlp
| natrys wrote:
| yt-dlp[1] has now taken on that mantle. I think mpv nowadays
| just recognises yt-dlp as the de facto alternative, but if
| yours doesn't then you can just put this in your mpv.conf:
| script-opts=ytdl_hook-ytdl_path=yt-dlp
|
| [1] https://github.com/yt-dlp/yt-dlp
| haunter wrote:
| No DVD or BD menu support as I've tried now
| Narushia wrote:
| Apparently there is partial support for it:
| https://github.com/mpv-player/mpv/issues/14370#issuecomment-...
|
| This should let you play a VIDEO_TS folder, ISO, or an actual
| disc... with the caveat that you need to figure out the
| coordinates of the menu yourself by using an external tool.
| Thaxll wrote:
| MPV is great for powerusers, for the vast majority of people just
| use VLC.
|
| I used both over the year and there are still things that are
| really annoying in mpv:
|
| - you can't render on a Chromecast
|
| - opening a file that does not work does nothing, you don't know
| what's happening, is the file corrupted, is the codec not
| supported ??
|
| - the no ui idea is nice for opening a single file, but then you
| go to the rabbithole of millions of settings / config to do
| anything more complicated, playlists? ( why can't I drag and drop
| on the window )
|
| - it's hard to compile, so it's up to you to find up to date
| version on your distro
| literallycancer wrote:
| If your distro has outdated packages, that's a problem with
| your distro.
|
| You can always just open files with a CLI if you want to see
| the error messages.
|
| What do you mean can't drag and drop on a window? That's
| literally how you add subtitles or open a file if you opened
| mpv from the shortcut, rather than by opening a file.
| Thaxll wrote:
| None of the distro keeps package up to date with mpv. Only
| rolling one are probably updated.
|
| Adding a file does not enqueued them, it just open it and
| play it right away.
| zamubafoo wrote:
| Never had to deal with your third point, I just open it via the
| CLI and it's pretty verbose regarding issues it encounters.
| thrusong wrote:
| mpv is a key part of my home theatre automation I wrote in PHP.
|
| It runs on a Pi 4. PHP assembles playlists with a Dolby ad, a
| vintage dancing hot dog ad, trailers, and the feature. It runs
| mpv through proc_open.
|
| It monitors the progress and controls mpv through a socket to
| know when to dim or raise the lights, open or close the curtain,
| etc.
|
| https://www.youtube.com/watch?v=Q7YEVGWJjvI
| Bluestein wrote:
| > Dolby ad, a vintage dancing hot dog ad, trailers, and the
| feature
|
| This is great.-
|
| _Particularly_ the vintage dancing hot dog ad, mind you :)
| flanked-evergl wrote:
| I use it as a backend for smplayer:
| https://www.smplayer.info/en/mpv
| Brosper wrote:
| This kind of project always lacks better UI/UX. I wonder if there
| is a way to bring more UI/UX people to Open-Source projects.
| cranberryturkey wrote:
| another good one in development is http://zymo.tv
| markwong wrote:
| I am using it for listening to the online radio in terminal.
| syngrog66 wrote:
| chiming in to say VLC is the best audio clip player I've found.
| every time in past I surveyed the space all other options I tried
| had one or more showstoppers like too buggy or not the right API.
| VLC (and driving it via either Golang or CLi) has been reliable,
| decently documented and ultra configurable.
| mysteria wrote:
| One cool thing about mpv is that it can transcode audio encoded
| in different surround sound formats (AAC, FLAC, Atmos, etc.) into
| regular Dolby Digital for use with old pre HDMI AVRs using SPDIF.
| AFAIK it's the only player that can do this natively without any
| additional work on the OS level.
|
| I'll just add this here but if you want this kind of transcoding
| for the entire system rather than just mpv you can use dcaenc
| with its virtual 6 channel input encoding everything to DTS. I
| send the encoded audio to the AVR using a cheap TI PCM27XX sound
| card with optical output.
| iwishiknewlisp wrote:
| What I like most about mpv is how you can control it through its
| socket. Often times I will play a movie or tv show on a separate
| monitor, so being able to pause or rewind or change volume
| without switching workspaces is important. I have in my i3
| config, keybindings so I can easily control mpv with my keyboard:
| https://github.com/ediw8311xht/dotfiles/blob/6a765910ab5ac17...
|
| Additionally, mpv has a powerful script system. One of my
| favorite scripts is fast foward through intro, which is crucial
| for watching a tv show. https://github.com/rui-ddc/skip-intro.
| Another nice script is
| https://github.com/familyfriendlymikey/mpv-cut, which enables
| creating clips in mpv. There are a ton of other useful scripts,
| and its not difficult to create a custom script yourself using
| lua.
|
| Mpv automatically resuming is also nice for watching tv shows or
| movies. Only problem is that if you shutdown mpv through killing
| the window then automatically resuming from history gets messed
| up.
| janandonly wrote:
| Mplayer, or MPV was my go-to program, next to VLC player, when I
| still used Windows and had loose mp4 files to play. Nowadays I'm
| just streaming on my Mac.
|
| Those good old days. [/ dream]
| bentt wrote:
| Technically superior with a bit of a learning curve, but really
| worth it. If they surfaced more of their functionality better, it
| would gain a lot of users.
| Gormo wrote:
| One of the nice things about MPV is that you can apply FFMpeg
| filters at playback, allowing you to use a wide range of
| transformations on a source video without having to re-render it
| for each variation.
|
| We're using inexpensive industrial mini-PCs, Alpine Linux, and
| MPV as a custom digital signage solution at my company, and
| centrally managing them via Ansible.
| carlhjerpe wrote:
| What does an industrial minipc offer that an RPI doesn't in
| this case? :)
| Gormo wrote:
| It's x86; it works better for hardware accelerated video
| playback via VAAPI due to FOSS Intel drivers; because it's
| fully integrated out of the box, its total cost is a bit
| cheaper than an RPi, and as a single unit with no assembly,
| it's quite a bit faster to deploy.
|
| I'm using these: https://www.amazon.com/MeLE-Fanless-
| Computer-Ethernet-PCG02/.... Works great with Linux, and has
| a very customizable BIOS.
| actinium226 wrote:
| We have free, open-source, cross-platform media player at home
| [vlc].
___________________________________________________________________
(page generated 2024-08-19 23:02 UTC)