Transcodes take up all available processing power

[CTalvio]

FFMPEG is a very hungry application, occupying all available threads and processing cycles if one lets it.

Because of context switching, this leads to greatly increased execution latency for other processes. Such as the Fireshare webservers serving the UI and videos.

This means that while transcodes are active, the web interface can become quite slow, and videos can fail to be served.

To Reproduce
Run a transcode, use the webUI. The problem will be more severe the less powerful the host system.

Expected behavior
I usually separate UI/service/realtime processes and work threads onto different cores on my system. This is not possible when the jobs I'd like to separate are within a single docker container.

I don't really care HOW this is solved, a simple solution would be to add a setting to limit how many threads transcodes can use.

Even better, allow the user to pin the transcodes to certain cores, and use taskset when starting transcode processes to enforce this, allowing the remaining cores to always be available for low-latency tasks.

[CTalvio]

Additionally, as transcoding is triggered right after upload, which is when you typically want to immediately link to what you just uploaded, it means Fireshare is always slow right when you're actually sending a bunch of visitors to it.

[ShaneIsrael]

So I wouldn't really call this a bug. This is more of an issue that you don't have a strong enough CPU to handle doing transcodes without completely locking it up. At least on my system with a 5600X I don't have this problem while transcodes are happening via CPU.

There might be a solution to this problem as you mention by pinning cores but that's not something I know how to do right off the top of my head and I would need to do a lot of research and testing to see if it is even possible to pin cores to a process in a docker container.

As much as I'd like to say "Hey yeah I'll try to get that fixed" I don't really see it as an issue. I'd go so far as to say you might want to disable transcoding if you don't have the cpu resources to effectively do it.

[CTalvio]

It's not. I just felt it was maybe more accurate compared to a feature request.

As I said, the problem will be more severe the less powerful the system. More cores and threads give the remaining processes more gaps to get CPU cycles in.

The main reason I'm personally running into this, is because I am already pinning the Fireshare container to the 4 threads (out of 12) that all my other services also pin "workload" task onto. This is because ffmpeg processes running on a system, no matter how powerful, is mutually exclusive with real-time execution on the same threads/cores. Media services that do transcoding usually at least provide a way to control the number of threads used, for this very reason.

I gave it more when I transcoded all my clips, but I do not need that speed for everyday use nor can I give it that at all times due to the other services running on my system, lest it interfere with them whenever a transcode is active.

Context switching, which is the CPU switching between execution environments, (since on the hardware level a core can only run one "program" at a time) takes time. When the CPU hits 100% utilization, context switching causes an unsolvable process scheduling issue that means the kernel will be unable to maintain real-time execution for services that require it. Essentially, ffmpeg taking up 100% causes "lag" because the CPU can't get back to time-critical processes fast enough.

I am intimately familiar with this, as I run things like Fireshare and Jellyfin on the same system as Titanfall, Minecraft, Valheim and other game servers and real-time services, at the same time.

A person watching a video in Jellyfin that is being transcoded by ffmpeg, will cause noticeable latency spikes for any players on a Titanfall server, simply if these processes ever try to schedule cycles on the same thread or core.

Even limiting ffmpeg to a single thread, such that total system resource utilization is well below 40%, is enough to cause execution latency for any other application that happens to be scheduled to use the same thread or core as the ffmpeg thread.

As such, I divide up my cores for real-time and workload purposes (Essentially achieving the same result as if were running these processes on separate systems). The problem cannot be solved by simply using a more powerful CPU, as the root cause is not one of insufficient processing power, but the impossibility of scheduling around context switching when a process has a workload so large, it uses up all "free" cycles (and in doing so delays other processes).

A more powerful CPU merely mitigates the issue, and allows the system so spend less time in this state, but it does not eliminate it. Not even priority can entirely solve problem, as the root cause is how CPUs work on a fundamental level.

PS: This is what "load average" is meant to measure. The load average is the number of processes that would like to use CPU cycles, but are still waiting to do so. If your load average is higher than your CPU thread-count, you have processes which are failing to keep up with real-time execution. Which is fine if that process is ffmpeg. Less fine, if the process is a game server that needs to process 60 ticks every second no matter what.

---

All that explaining aside, I'm only bringing it up because in the absence of anything else, I'll fix and PR a change myself. I consider it etiquette to open an issue before doing so, and thereby give anyone else potentially working on a fix a heads up so that no-one wastes time fixing the same problem.

[ShaneIsrael]

@CTalvio if your idea is asking Claude to create a "fix" for an issue that you are having without actually knowing what Claude is writing and without heavily testing it yourself before making said PR then don't waste your time.

I've had enough people try to brute force stuff into the app that I decline in that way without even testing it themselves because they don't have actual knowledge of coding and standing up the app locally. So they just assume whatever AI writes is fine and that's all there is too it.

The type of update you are asking to make is one that needs to be very well tested because it can easily introduce major issues if not done correctly.

I'm still very much of the opinion that this is a waste of time and effort. You are trying to solve a problem for systems using weak processors that in general shouldn't have transcoding enabled to begin with.

I know how much time and effort would need to go into trying to do what you are saying properly. I am not going to do it because I can't dedicate all of my time to issues that affect the 1/1000 person because they are trying to use a feature they should not be using given their hardware specs.

This isn't a project like Jellyfin that has massive community funding where I could justify the development time.

---

With all that said, if you still want to proceed with attempting to do this yourself then go ahead. I'll review the PR and request any changes I think need to be made or decline it if it's clear it's going to cause problems.

I only ask that if you do not have any proper formal coding experience that you stop here.

[CTalvio]

I don't use AI to code.

I'm also the guy who figured out that transcodes were freezing dude to the linux pipe buffer filling up. I didn't find that out by asking Claude.

And you've misunderstood the problem. This is not a problem caused by weak CPUs, it is merely more obvious on them.

Any CPU can do two things at the same time, by switching between the two processes. But that switch, itself also takes time.

If one of those two things requires real-time execution, no matter how fast your CPU is, you can't maintain real-time execution if the other process leaves no headroom for the CPU to execute the context switch. A more powerful CPU simply hides the problem, but with a sensitive enough application, (such as a game server) the problem will persist.

I should know. 5 years ago I learned this the hard way when ffmpeg using a single core (out of 12) was still causing lag-spikes on my game servers. Only separating the processes onto different physical cores solved the problem.

I may be a system admin as a hobby, but I've been doing it for over 10 years and have solved low level problems with custom python management scripts that start, stop and scale services depending on user demand and priority, setting up complex systemd and docker configs that divide up system resources core by core.

I've debugged and submitted fixes for the game servers I run.

I personally want this, in order to run Fireshare the way I'd like to on my system: I've shoved over a dozen services onto a single system, and I want them all to be responsive at all times, and I ensure that is the case by carefully managing system resources. I've created the tools to do that before, I've no doubt I can do it again.

Docker is a new challenge for me in this regard as I can't yet control processes and their hardware allocation inside the container the way I know how to on the host system. But I've already done some testing with the taskset command inside containers, and core pinning inside docker is absolutely possible.

I wont necessarily PR anything that complex, but a simple setting to set ffmpeg threadcount manually like in Jellyfin will be useful for anyone.

I already figured out the switch to libsvt. If it doesn't work, I'm not going to submit a PR that doesn't at least run on my system.

[CTalvio]

I REALLY like Fireshare, btw.

Absolutely adore it. I use it almost daily to share clips and some of my friends use my instance too. I just can't give it more cores without it interfering with the game servers we play on, and with the few cores it has it works great until someone uploads something, and then it's really slow for a few minutes while the transcodes run. Or even when other services run transcodes. I want to solve that.

I absolutely do not want to step on your toes in any way, which is another reason I didn't just PR out of the blue. As you're not interested in working on resource allocation functionality, I'll be looking into it. I'm not new to FOSS. Github issues are not demands, and you're a volunteer.

Now, I won't bother you with pointless updates until I have something useful.

[ShaneIsrael]

@CTalvio That's great. If this is something you really think needs to be improved and you have the time to look into it and test the changes thoroughly then I am more than happy to allow it.

My hesitancy is only because I've had a lot people try to ram features through with PR's or "If you don't do it, i'll do it" mentality and I have to draw a line on features/additions somewhere. In this case, I understand that its a performance improvement so I'm perfectly fine with you putting in the work to add it so long as it is thoroughly tested. Of course I'll also test it but my tolerance for untested AI rammed in features is very low so that was all I was getting at. I don't mind if you use AI to assist in the coding, in this day and age it's how the field is changing. I just want to make sure that you are in fact knowledgeable and can review any code written by AI.

I don't mean to come off as stubborn. But there is a sea of AI slop that people with no actual coding experience are pumping out and since it's so easy to do it's hard to trust anybody who says "I'll do it myself if you don't have the time" because even somebody with no coding experience can tell AI to do it without actually vetting and testing what AI did.

By all means please add in the improvement yourself and PR it when you are ready for me to test it. It seems like you do have a pretty good knowledge base on the issue and since you are able to articulate the problem as well as you are I don't think you are someone who is simply going to hand it off to AI. Apologies if I came off a bit rude.

[CTalvio]

I understand the woes of FOSS. Been there.

I'll endeavor to take up as little of your time as possible and make my contributions simple in the sense that they work and don't incur tech debt.

I approve of vetting contributors, I just thought my previous issue and PR already established my credibility. My user history is also sparse, but not short.

[ShaneIsrael]

I just thought my previous issue and PR already established my credibility

That's my bad for not remembering you made that contribution. I try to respond as much as possible to everyone has makes an issue or request and sometimes it just becomes a blur.