[zoriya]

Some times ago, I introduced my self-hosted media browser [Kyoo](https://github.com/zoriya/kyoo) here (plex/jellyfin alternative). I received great feedback and continued to work in it since. I decided to talk more about how Kyoo works under the scene, so here is my first blog post about that!

This is one of my first blogs, so I'm eager for some feedback!

[memco]

The article seemed to have a nice level of detail without being too light or heavy: nice job!

At the end you discussed how you moved from C to Rust to Go for this: I’m assuming the interface with ffmpeg is inconsequential to the language choice so I’m curious to read more about what has motivated you to make those changes and where you might go next. Do you see any potential for replacing parts or all of ffmpeg or is it a foregone conclusion that ffmoeg will be the core of the project?

[zoriya]

In C, I was using ffmpeg's functions directly instead of their CLI. I was manually decoding packets, frames and so on. Having to do all of this, I quickly became familiar with how ffmpeg works (and got able to read their source code) ; but this level of control was unneeded to create a HLS multi-variant stream. I made more sense to simply call ffmpeg via it's CLI interface and use a higher level language to manage states.

I then moved to rust, mostly because I was curious about the language. When I decided to use the original's video keyframes I needed to rewrite everything anyway, so I decided to change language at this time. The CLI interface did not change but using golang made state management easier since it has great tooling for (goroutines, concurrent maps, channels...). Rust lacks those tools, and it was hard to handle mutexes and so on.

[social_quotient]

I’d be curious if people really ever switch from ffmpeg and if yes, what to?

[Terretta]

Well done! This is a great breakdown and explanation.

Nearly two decades ago, we shifted from other formats such as WindowsMedia -- that had great multi-bitrate support built in -- to H.264 over HLS not just so we could serve over traditional http CDNs at scale instead of needing media servers, but so we could do a host of features enabled by splicing on the fly. We used extremely similar techniques to enable not just live switching among bitrates of live feeds from live events, but similar adaptive bandwidth playback for VOD as well. And of course, dynamic ad insertion (even tailored to audiences) into a stream in place of the blank a broadcaster sends, without ad support (or ad blocking) in the player. It's interesting this still isn't the norm.

Very cool to see how this works unpacked again, and very cool for Plex to have a challenger!

[SoothingSorbet]

Looks good, I have a few questions about the project:

- Is there an Android app or is it Web only on Android? (This is very important for playback on video player apps, which support more than the Webview does.)

- Is there a Flatpak available?

- Why did you choose to use a big server like Postgres over using SQLite? Did it not meet your needs? It seems way overkill for a personal media manager. Are there any plans to at least support SQLite as an alternative in the future?

[zoriya]

There is an android app, available as an apk in the release tab of github (I plan on publishing it on the android store this summer).

There is no flatpak and no linux/mac/windows client yet. Right now client support is not a priority, I want to focus on supporting more features and stabilizing bugs before creating clients, but this is definitely in the todo.

There is no plan to support SQLite in the future, Kyoo already uses multiples executables/containers anyway. Postgres offer better scalability with little disaventages.

[jdenning]

Excellent article - as others have said, it's the perfect level of detail for this kind of post. Keep writing!