3 ms·

I think legacy contributed most. On modern Linux, it’s possible, and not even terribly hard, to implement hardware-accelerated video playback without any libra

I think legacy contributed most. On modern Linux, it’s possible, and not even terribly hard, to implement hardware-accelerated video playback without any libraries or frameworks, by directly consuming V4L2 API exposed by the kernel. Here’s a proof, I did it alone spending a month or so part time, and resource use is lower than VLC’s despite my code is in .NET: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo However, that wasn’t always the case. Until recently software had to fallback to software decoders, and implement other workarounds. Software developers are reluctant to throw away old code and do something completely different. 1. They spent much time on that old code (sunk cost fallacy). 2. Old code usually works more often than it doesn’t (don’t fix things which aren’t broken). 3. Massive refactor of large software is very expensive in general. Moving stuff from CPU to GPU is going to cause large changes in many parts. You can’t usually afford to copy uncompressed video frames from VRAM back to system RAM and call it a day, that would be too much bandwidth. Instead, you have to change a lot of other code to handle GPU textures instead of system RAM images.

Jasper_ 6y ago
> On modern Linux, it’s possible, and not even terribly hard, to implement hardware-accelerated video playback without any libraries or frameworks, by directly consuming V4L2 API exposed by the kernel Do you mean V4L2 M2M decoding? That's only supported on a very small subset of devices, mostly ARM devices. Other devices might use VA-API (Intel), VDPAU (NVIDIA proprietary), or something from the OpenMAX standard (some AMD drivers). M2M is far from easy to handle in a lot of circumstances, though it depends on the kinds of devices you use. I don't really know why you're going into a screed about "sunk cost fallacy".
- vetinari 6y ago
  AMD uses VA-API nowadays.
  - selectodude 6y ago
    As does Nvidia.
- Const-me 6y ago
  > Other devices might use VA-API (Intel), VDPAU (NVIDIA proprietary), or something from the OpenMAX standard (some AMD drivers). Nothing prevents Firefox from consuming these things. The majority of time I’ve spent on that library was not on V4L2, it was containers parsing (they are incredibly complicated these days, as I found out in the process), bitstream and parameter sets parsing, also audio codecs shenanigans: https://github.com/Const-me/DtsDecoder https://github.com/Const-me/DtsDecoder > M2M is far from easy to handle in a lot of circumstances I know, and I never said it was trivially simple. But it’s not terribly complicated either. I have implemented that alone, for fun, spending a month part time. My implementation plays all h264 video files on my hardrives (more than 1TB of them). Because of that, I would expect better from a company with 9-digit annual revenue. BTW I had no prior experience with Linux multimedia, albeit I did a lot of related things on Windows, mostly with Media Foundation. > why you're going into a screed about "sunk cost fallacy" I have no idea how Firefox is developed. However, I’ve been developing other software for living for couple decades now, worked with many codebases including very old ones, and I think I know a few things about software development in general. That was just my educated guess.
megous 6y ago
BTW, you can strip down ffmpeg build to a pretty barebones level, so that it only includes what you need.
- Const-me 6y ago
  True. But I didn’t want to violate their license, nor publish my code under GPL. There were other considerations as well. For example, if I would have forked or re-built ffmpeg, I would then have to support my version. That’s something I try to avoid when I can. I think OS maintainers are doing much better job updating these third-party packages than I can possibly do myself, at least for an unpaid hobby project.
boring_twenties 6y ago
Very cool, thanks for sharing! I have some pretty old hardware so lower resource use is always good, will be trying your player out!
athrun 6y ago
Thank you for sharing your project! Very cool to see a combination of low-level Linux kernel APIs and .NET. True hacker spirit right there!
- Const-me 6y ago
  Thanks! BTW I used more than V4L2. ALSA from libasound.so.2, there: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/IO/ALSA/libasound.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/IO/... and the rest of libasound.*.cs files in that folder (parts of the same static class). Audio output is harder than necessary on all OSes I developer for, including Windows. From the internets I got an impression that at least on RPi, ALSA PCM is more reliable than the rest of them. Also doesn’t depend on any desktop components, important because the library can also be used without any desktop environment, rendering on a physical display. Message queues from librt.so https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/IO/Kernel/MessageQueue.api.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/IO/... .NET has equivalent stuff already. I needed poll() to get notified about multiple things not just queued messages, as both V4L2 and ALSA expose poll()-compatible file handles in their respective APIs.

Jasper_ 6y ago

> On modern Linux, it’s possible, and not even terribly hard, to implement hardware-accelerated video playback without any libraries or frameworks, by directly consuming V4L2 API exposed by the kernel Do you mean V4L2 M2M decoding? That's only supported on a very small subset of devices, mostly ARM devices. Other devices might use VA-API (Intel), VDPAU (NVIDIA proprietary), or something from the OpenMAX standard (some AMD drivers). M2M is far from easy to handle in a lot of circumstances, though it depends on the kinds of devices you use. I don't really know why you're going into a screed about "sunk cost fallacy".

vetinari 6y ago
AMD uses VA-API nowadays.
- selectodude 6y ago
  As does Nvidia.
Const-me 6y ago
> Other devices might use VA-API (Intel), VDPAU (NVIDIA proprietary), or something from the OpenMAX standard (some AMD drivers). Nothing prevents Firefox from consuming these things. The majority of time I’ve spent on that library was not on V4L2, it was containers parsing (they are incredibly complicated these days, as I found out in the process), bitstream and parameter sets parsing, also audio codecs shenanigans: https://github.com/Const-me/DtsDecoder https://github.com/Const-me/DtsDecoder > M2M is far from easy to handle in a lot of circumstances I know, and I never said it was trivially simple. But it’s not terribly complicated either. I have implemented that alone, for fun, spending a month part time. My implementation plays all h264 video files on my hardrives (more than 1TB of them). Because of that, I would expect better from a company with 9-digit annual revenue. BTW I had no prior experience with Linux multimedia, albeit I did a lot of related things on Windows, mostly with Media Foundation. > why you're going into a screed about "sunk cost fallacy" I have no idea how Firefox is developed. However, I’ve been developing other software for living for couple decades now, worked with many codebases including very old ones, and I think I know a few things about software development in general. That was just my educated guess.

megous 6y ago

BTW, you can strip down ffmpeg build to a pretty barebones level, so that it only includes what you need.

Const-me 6y ago
True. But I didn’t want to violate their license, nor publish my code under GPL. There were other considerations as well. For example, if I would have forked or re-built ffmpeg, I would then have to support my version. That’s something I try to avoid when I can. I think OS maintainers are doing much better job updating these third-party packages than I can possibly do myself, at least for an unpaid hobby project.

boring_twenties 6y ago

Very cool, thanks for sharing! I have some pretty old hardware so lower resource use is always good, will be trying your player out!

athrun 6y ago

Thank you for sharing your project! Very cool to see a combination of low-level Linux kernel APIs and .NET. True hacker spirit right there!

Const-me 6y ago
Thanks! BTW I used more than V4L2. ALSA from libasound.so.2, there: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/IO/ALSA/libasound.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/IO/... and the rest of libasound.*.cs files in that folder (parts of the same static class). Audio output is harder than necessary on all OSes I developer for, including Windows. From the internets I got an impression that at least on RPi, ALSA PCM is more reliable than the rest of them. Also doesn’t depend on any desktop components, important because the library can also be used without any desktop environment, rendering on a physical display. Message queues from librt.so https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/IO/Kernel/MessageQueue.api.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/IO/... .NET has equivalent stuff already. I needed poll() to get notified about multiple things not just queued messages, as both V4L2 and ALSA expose poll()-compatible file handles in their respective APIs.