Seeking in video HLSPlayHandler (Safari) it doesn't kill the previous ffmpeg command about remote-mediaserver

[OwenRay]

This is partially by design. Unused hls sessions should timeout after about 30 minutes, (that way you can pause the video and not have any activity for a while but still resume).
There is supossed to be a cpu throttling mechanism but it works "less then ideal" with hls.
I'll keep this open because of the cpu usage: we'll need to find a way to pause ffmpeg without it consuming a lot of cpu.

[sspilleman]

I kinda figuered that one out ;-)

You are working with sessions right.... If hou keep a relation on the server between spawned processes and the session id.... Then if you get a new Play request (when seeking).... you are able to find the old spawned process and kill it.... Good idea?

Somewhere along the lines of:

const spawned = {} // this object must "live" outside of the scope of the request (obvously)

// new request
if (spawned[session_id]) spawned[session_id].kill(); // this is where you kill the previous
spawned[session_id] = new Ffmpeg() // this is where you store the pointer to the newly created process

[OwenRay]

That's a good idea, maybe we should consider to reuse the previous session in some way, or properly signal session ending from the client. You don't want to be killing somebody else's session;)

[sspilleman]

A session is unique to a browser session I think. So if you would be using that, you would never kill another users session right?

[OwenRay]

right every single play attempt has a unique session id (including seeking).
as it is now, any time you start playing the hls an x-playback-session-id header is automatically passed by the browser, this is used to determine which session every subsequent request belongs to. If the session-id is not available one is generated.

So, sessions are unique, but right now there is no info who the session belongs to, so there is not enough information to determine which session to kill.
So the way sessions are handled might need a partial rewrite.

[sspilleman]

So If I understand you correctly... Each play request starts another unique session. If so, we'll need to change that I guess... We do need to kill those CPU consuming processes

[OwenRay]

Yes most certainly,
for reference 2 things have to change:

• The session handling
• the throttling mechanism

[sspilleman]

As quick hack, we might consider linking the process to the file that is being played instead of the session id and kill if we get another play request for the same video. This will go alright as long as there are no other users playing the same file.... this obviously isn't sustainable ;-) But the current solution isn't sustainable for multiple users anyway based upon the CPU load as it is now.

I quickly don't understand the throttling mechanisch would have to change... You are doing it per request as it is now?

[OwenRay]

well, the throttling mechanism is actually the core of the problem as I see it.
How it works right now:
It monitors the number of buffered chunks that haven't been read by the client. If there are enough chunks available the encoding process is paused. This should mean a dorment session has a 0 load cpu process.
Sadly the hack used to pause ffmpeg actually spins the cpu up to a 100% now.

Remote-MediaServer/backend/modules/ffmpeg/FFMpeg.js

Line 195 in 2b24a52

this.proc.stdin.write('c');

So if we can find some other (cross-platform) way to pause ffmpeg that would already be enough of a solution for now imho.

for mpeg encoding the ffmpeg output stream is paused that works really well. This doesn't work for hls because ffmpeg writes directly to disk.

[sspilleman]

Ah, I see your point.... You've implement the throttling to save on disk space I assume?

They are some pointers here: pause-and-resume-ffmpeg-encoding

Not entirely clear though what solution / platform combo's will work...

you could get the PID with pgrep ffmpeg then use kill -s SIGSTOP to suspend. Then resume kill -s SIGCONT .

This will probably work on unix based OS-es I guess, not sure on windows.... But I kinda assume, most people usinging your repo are on linux/macOS anyway ;-)

[OwenRay]

I do know some people who are using rms on Windows, I don't want to break that support. But we could ofcourse use the current implementation as a fallback for Windows.

[OwenRay]

@sspilleman let me know if this works for you, if not feel free to reopen it;)