Hacker News Reader

Comment by hnlmorg | Hacker News Reader

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?

View on HN

> 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

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.

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.

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

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.

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

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.

Would still live with that, to have a single system that's no worse than my laptop.

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.

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.

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.

Do you still maintain it?

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.

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

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

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.

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.

Reply on news.ycombinator.com