4 ms·

It’s not that difficult to be honest. VLC / ffmpeg can do most of the heavy lifting. And there’s no shortage of libraries for rendering in a UI. There used to

by hnlmorg 2mo ago

It’s not that difficult to be honest. VLC / ffmpeg can do most of the heavy lifting. And there’s no shortage of libraries for rendering in a UI. There used to be dozens of options to choose from. Multiple different XBMC forks. Multiples different Subsonic forks. Multiple different DNLA servers. Multitudes of web-based servers. CLI MP3 servers. Independent media centres for a variety of different consoles. Maybe that’s still available and just not indexed on that site. But I noticed the choices had shrank significantly last year when I was looking for Plex alternatives compared with when I last built a media centre approximately 15 years ago. Maybe smart TVs have reduced people’s desire here?

metek 2mo ago
I think I understand how to use about 20 of the command line options for ffmpeg and the companion utilities like ffprobe. Which is to say; I understand about 0.5% of the total options they provide and am likely a world leading expert in it. I'm mostly joking -- as in, overstating how many of them I understand. Understanding ffmpeg borders on a specialization in itself. No big surprise that so many of the alternatives have fallen away over the years as people realize the absolute scope of that piece of software.
- hnlmorg 2mo ago
  You don’t need to understand much of ffmpeg to build a media centre. Your requirements here are extremely simplified and there are hundreds of guides online on how to use it for very simple transcoding. But if you don’t want to use ffmpeg directly then use one of the many ffmpeg wrappers. Or a different lib entirely like gstreamer or VLC. Around 15 years ago I built a media centre for my car and the media playback part turned out to be the easiest part of the project.
  - rpdillon 2mo ago
    Do you still maintain it?
    - hnlmorg 2mo ago
      No. It was built before Android / Apple integrations existed and was built around tactile controls and voice interactions. But I think Apple Car play is a far far more useful product these days than anything I built 15 years ago. Even if their touch controls are an ergonomic step backwards.
- 0x457 2mo ago
  i had media center powered by a few perl script that would transcode all videos into formats that ps3 supported in 2007-ish. Yes ffmpeg had a lot of options, 99% of them does not matter, there really only 3 ways to stream to client: as is, repack streams into something client support (i.e. your source is mkv) or transcode into something client support (clients know which formats they support). People that run these services don't want "dynamic stream quality selection".
JoshTriplett 2mo ago
I would love to see an Open Source media center that supports streaming services. I wouldn't care if the services say "we only support 1080p for browsers / open source, anything more needs a locked-down device". (Perhaps the project could have some add-on you can buy that's a physical hardware dongle for doing 4k HDR and emitting HDCPed HDMI.) I already live with that for watching on my laptop. Just having watchable basic-resolution streaming would make it a one-stop-shop.
- MostlyStable 2mo ago
  If streaming through a browser/open source / not the locked down app supported 1080p I would be a lot happier. My understanding from the last time i looked is that it actually only supports 720p
  - JoshTriplett 2mo ago
    Would still live with that, to have a single system that's no worse than my laptop.
  - gspr 2mo ago
    You can coax Netflix into giving you 1080p in ordinary Firefox by setting the right user-agent. That's good enough for me, and if it stops working I'll be motivated to stop paying those assholes anyway.
- hnlmorg 2mo ago
  The issue is many streaming services require DRM in the browser. I can’t recall if Chromium supports that, I have a feeling Google only include that DRM in Chrome. But if it is available in Chromium then you might be able to build an Electron app.
buran77 2mo ago
> It’s not that difficult to be honest. Sounds easy if all you have to do is write a short comment about it. People who actually did it, like the recently retired lead of the Jellyfin project, didn't make it sound like it's "not that difficult" [1]. If you want ot vibe code a project for yourself it's probably reasonable amount of effort. But if you want to build a product, something with polish, something not held together by spit and scotch tape, something reliable, it won't be easy. [1] https://forum.jellyfin.org/t-project-leadership-changes https://forum.jellyfin.org/t-project-leadership-changes
- hnlmorg 2mo ago
  I did write a media centre around 15 years ago. What that link you shared describes is the very real toll that maintaining an open source project demands. Not the specific complexities of transcoding multimedia. From personal experience, the transcoding was the easy part. Building a UX that was intuitive and a backend that catalogued the media accurately required far more attention.
  - wredcoll 2mo ago
    This is such a weird comment chain. Of course transcoding media is the easy part, ffmpeg exists. Even if it didn't, it would still be the easy part because you're just building computer algorithms that are like specified and defined and testable. Making something that actually interacts with "the human world" is 100s of times harder than writing any kind of algorithm.
    - Anamon 2mo ago
      > Even if it didn't, it would still be the easy part because you're just building computer algorithms that are like specified and defined and testable. I'd challenge that. Have you looked at the specifications of any reasonably current compression standards? The AVC one is some 900 pages, I think. Entire communities exist around discussing the strengths and shortcomings of different codec implementations.
piaste 2mo ago
> Multiple different XBMC forks. Multiples different Subsonic forks. Multiple different DNLA servers. Multitudes of web-based servers. CLI MP3 servers. Big difference between _audio_ streaming and _video_ streaming servers. Video streaming is much more complex and pretty consolidated, as I mentioned. Audio streaming is much more manageable: no issues with transcoding, acceleration or subtitling, and a radically simpler UI. Also ID3 tags aren't great but they're a pretty universal standard with lots of databases, you don't need to desperately scrape IMDB/TMBD for info. As a result there are quite a few music servers, often exposing Subsonic compatible APIs, ranging from the minimalistic to the 'I'm trying to do everything Spotify does'.
- hnlmorg 2mo ago
  There’s literally no difference in difficulty between audio and video. They all suffer from the same problems of indexing content. They all have multiple different encoding formats available. And they all need a frontend widget in your client for playback. I’ve worked with both the audio and video streaming platforms and what you’re describing is grossly inaccurate. The fact that your container format isn’t including video frames doesn’t magically solve any of these issues. Plus ID3 can be a source of new problems by itself given the way it was implemented…twice.
  - Anamon 2mo ago
    ID3 is hell... The answer to every question about how to use/write it is the counter question: well, which software or player do you want it to work with? Here are your 8 mutually incompatible options.

by hnlmorg 2mo ago

metek 2mo ago

I think I understand how to use about 20 of the command line options for ffmpeg and the companion utilities like ffprobe. Which is to say; I understand about 0.5% of the total options they provide and am likely a world leading expert in it. I'm mostly joking -- as in, overstating how many of them I understand. Understanding ffmpeg borders on a specialization in itself. No big surprise that so many of the alternatives have fallen away over the years as people realize the absolute scope of that piece of software.

hnlmorg 2mo ago
You don’t need to understand much of ffmpeg to build a media centre. Your requirements here are extremely simplified and there are hundreds of guides online on how to use it for very simple transcoding. But if you don’t want to use ffmpeg directly then use one of the many ffmpeg wrappers. Or a different lib entirely like gstreamer or VLC. Around 15 years ago I built a media centre for my car and the media playback part turned out to be the easiest part of the project.
- rpdillon 2mo ago
  Do you still maintain it?
  - hnlmorg 2mo ago
    No. It was built before Android / Apple integrations existed and was built around tactile controls and voice interactions. But I think Apple Car play is a far far more useful product these days than anything I built 15 years ago. Even if their touch controls are an ergonomic step backwards.
0x457 2mo ago
i had media center powered by a few perl script that would transcode all videos into formats that ps3 supported in 2007-ish. Yes ffmpeg had a lot of options, 99% of them does not matter, there really only 3 ways to stream to client: as is, repack streams into something client support (i.e. your source is mkv) or transcode into something client support (clients know which formats they support). People that run these services don't want "dynamic stream quality selection".

JoshTriplett 2mo ago

I would love to see an Open Source media center that supports streaming services. I wouldn't care if the services say "we only support 1080p for browsers / open source, anything more needs a locked-down device". (Perhaps the project could have some add-on you can buy that's a physical hardware dongle for doing 4k HDR and emitting HDCPed HDMI.) I already live with that for watching on my laptop. Just having watchable basic-resolution streaming would make it a one-stop-shop.

MostlyStable 2mo ago
If streaming through a browser/open source / not the locked down app supported 1080p I would be a lot happier. My understanding from the last time i looked is that it actually only supports 720p
- JoshTriplett 2mo ago
  Would still live with that, to have a single system that's no worse than my laptop.
- gspr 2mo ago
  You can coax Netflix into giving you 1080p in ordinary Firefox by setting the right user-agent. That's good enough for me, and if it stops working I'll be motivated to stop paying those assholes anyway.
hnlmorg 2mo ago
The issue is many streaming services require DRM in the browser. I can’t recall if Chromium supports that, I have a feeling Google only include that DRM in Chrome. But if it is available in Chromium then you might be able to build an Electron app.

buran77 2mo ago

> It’s not that difficult to be honest. Sounds easy if all you have to do is write a short comment about it. People who actually did it, like the recently retired lead of the Jellyfin project, didn't make it sound like it's "not that difficult" [1]. If you want ot vibe code a project for yourself it's probably reasonable amount of effort. But if you want to build a product, something with polish, something not held together by spit and scotch tape, something reliable, it won't be easy. [1] https://forum.jellyfin.org/t-project-leadership-changes https://forum.jellyfin.org/t-project-leadership-changes

hnlmorg 2mo ago
I did write a media centre around 15 years ago. What that link you shared describes is the very real toll that maintaining an open source project demands. Not the specific complexities of transcoding multimedia. From personal experience, the transcoding was the easy part. Building a UX that was intuitive and a backend that catalogued the media accurately required far more attention.
- wredcoll 2mo ago
  This is such a weird comment chain. Of course transcoding media is the easy part, ffmpeg exists. Even if it didn't, it would still be the easy part because you're just building computer algorithms that are like specified and defined and testable. Making something that actually interacts with "the human world" is 100s of times harder than writing any kind of algorithm.
  - Anamon 2mo ago
    > Even if it didn't, it would still be the easy part because you're just building computer algorithms that are like specified and defined and testable. I'd challenge that. Have you looked at the specifications of any reasonably current compression standards? The AVC one is some 900 pages, I think. Entire communities exist around discussing the strengths and shortcomings of different codec implementations.

piaste 2mo ago

> Multiple different XBMC forks. Multiples different Subsonic forks. Multiple different DNLA servers. Multitudes of web-based servers. CLI MP3 servers. Big difference between _audio_ streaming and _video_ streaming servers. Video streaming is much more complex and pretty consolidated, as I mentioned. Audio streaming is much more manageable: no issues with transcoding, acceleration or subtitling, and a radically simpler UI. Also ID3 tags aren't great but they're a pretty universal standard with lots of databases, you don't need to desperately scrape IMDB/TMBD for info. As a result there are quite a few music servers, often exposing Subsonic compatible APIs, ranging from the minimalistic to the 'I'm trying to do everything Spotify does'.

hnlmorg 2mo ago
There’s literally no difference in difficulty between audio and video. They all suffer from the same problems of indexing content. They all have multiple different encoding formats available. And they all need a frontend widget in your client for playback. I’ve worked with both the audio and video streaming platforms and what you’re describing is grossly inaccurate. The fact that your container format isn’t including video frames doesn’t magically solve any of these issues. Plus ID3 can be a source of new problems by itself given the way it was implemented…twice.
- Anamon 2mo ago
  ID3 is hell... The answer to every question about how to use/write it is the counter question: well, which software or player do you want it to work with? Here are your 8 mutually incompatible options.