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!
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?
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.
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!
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?
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.
I run ffmpeg on small segments of video and when you seek too far from the current transcoded position, i create another ffmpeg process. The hard part is making sure those segments can be watched without gaps or issues and no audio/video segment is repeated.
If there is enough interest about it I might make a blog post explaining this in details
I'm using the time skip/seek functions more than I should and Plex, Jellyfin, Emby are really not good in that department. I was WAITING for somebody to fix this problem. Plex, Jellyfin, etc. None of them came close to the youtube experience. It always felt very slow and clunky. I can't thank you enough for this really. Thank you very much for addressing this issue and creating this amazing project!
probably not in a close future since it requires paying $100 a year per app to publish to the app store. i also dont have any apple device so i cant even test it.
i dont know how hard/easy it would be to port the app in itself tho, its written in react native so it should be pretty straightforward but you never know.
Classic rust fan :p I tried to write the transcoder in rust before rewriting it in rust. You can call that skill issue, but I did not like the language and needed a rewrite because I was taking a fundamentally broken approach anyway.
it's good when you watch things from outside your home network. you can transcode things to watch on the train/subway or somewhere you don't have stable internet access.
No, I want to stay focused on movies/series/anime. There's already a lot to handle for me alone working on this, and ebook/music is just different enough that supporting it will need a good amount of efforts.
Thanks a lot.
The demo is the docker-compose from the README on an oracle's VPS always free tier.
I never tried to benchmark the server, but the limiting factor will certainly be the encode speed of the machine. If your clients all needs transcoding of different h265 8K movies at the same time, you would need vastly different GPU/CPU power than for the same amount of users with direct play.
