-
-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Questions on simultaneous ffmpeg processes (NVENC job concurrency) and segment buffering behavior #42
Comments
There is actually no limitation in number of concurrent transcoding processes. Transcoding is started depending on requested segments. For typical playback it should not be more that one process. But from your logs I see that transcoding jobs were started twice (
This looks like segments were already marked as being transcoded, but since ffmpeg never returned any valid segment they never get response from transcoding prccess. As you correctly pointed out, thisi sa bug:
It would be a nice addition to control number of concurrent transcoding processes. |
I see, then I misunderstood the comment Would it be more accurate to call this
In my use case, I have multiple clients requesting parallel segments indeed! (I did increase So you're saying this isn't currently supported, and I would need to implement some kind of locking mechanism to guard against this request pattern/behavior?
Gotcha. Probably quite easily fixable, but won't solve the root cause of these segments failing in the first place for me.
I'm not sure I fully understand. All of this is in I think where I struggle is that I don't understand what 'buffer' refers to in this context. Is buffer the number of segments cached on disk, before go-transcode starts deleting them? Can I accomplish the latter by simply setting |
It was meant to transcode as:
You can think of one VOD, that is split to N segments. Each segment is identified by exact time offset withing that media file, and duration. Sum of durations of all segments is duration of whole media file. Those segments are numbered One VOD media can have X clients. Every client can start playing VOD at any segment (or even seek forward/backwards). Depending on where current position of a client is, we need to ensure they will have available those segments. That is that Let's say
All already transcoded segments can be reused by other clients and should not be transcoded twice. So you should not guard against that, if thats not currently the case, this issue should be fixed.
That would mean, first transcoding job would esentially transcode whole video in just one job. But other clients, that want to start from seeked position would have those segments available after that transcoding finishes.
It is configured to clear all segments when closing the app, so we could add config value that contidionally calls |
Thank you so much for taking the time to explain all of this. Super helpful to me! Maybe this could be a nice baseline of some internal developer documentation?… One more basic question: what do you call a "job" in this context? I'm currently reading hlsvod.transcoding.TranscodeSegments() and I suspect a "job" in one invocation of that function. Is that accurate? I don't know how you and others are using go-transcode, but I'm streaming the video from a web browser (using hls.js for HLS support, because Chrome doesn't have that built-in). What are your thoughts on that? Will that immediately create ten jobs (segments 0–2, 1–3, 2–4, 3–5, etc.)? I could imagine that this might cause a lot of unnecessary transcoding, because presumably the "0–2" job, after having transcoded its first segment, will proceed to segment 1, unaware that the "1–3" job has already transcoded that. I suspect that is not what's going on, because then I can think of at least three different ways my entire application should immediately fail hard and not work as 'mostly fine' as it currently does. 😉 But I'll need to take a few hours and really analyze browser and transcoder logs to understand why it isn't happening. |
Yes, thats correct.
Yes it does learn about the individual segments as they get completed by reading them from channel in real time.
That might cause problems, but the buffer of player (actual prefetching) should match with go transcodes buffer. So when you know your player will be prefetching 10 segments,
No, it should only spawn |
Gotcha. The HTTP server component is really multi-threaded, not coroutine-based or so? My use case is synchronizing video playback between multiple browsers. So yeah, I'm definitely going to cause these simultaneous requests a lot. 😀 |
It is multi-threaded, but that is all expected. Simultaneous requests should be fully supported by this program. I tried to add this mutex, and it looks like it fixed the issue with processing a single request multiple times. Could you try it out? |
Thank you for all your changes! I'll give it a try next week. |
Is it possible that an issue exists with overlapping transcoding runs, i.e. is it possible that there is a situation (race condition?) in which
segmentBufferMax+1
ffmpeg instances run simultaneously?I'm using the VOD mode with (modified) GPU encoding via NVENC. Consumer-grade Nvidia GPUs only allow 2 or 3 (apparently they increased this to 3 some time in 2020) simultaneous NVENC jobs.
I'm testing with a GTX 1050 and a GTX 1070.
I've set
segmentBufferMax
to3
, otherwise I would constantly run into this issue. With that, at the beginning it runs just fine and does a couple of transcodes successfully. Eventually, it runs into the telltale 'nvenc concurrency' error:After that, go-transcode runs into some kind of hiccup where from now on until a restart, it only produces timeouts:
I'm not sure why this is, but apparently it doesn't handle the ffmpeg failure all too well.
Btw., I'm a bit confused, but from the code comments,
segmentBufferMin
has nothing to do with this, correct?segmentBufferMin
andsegmentBufferMax
are two completely different configuration values that don't work together to create some kind of range.Click to expand full log
The text was updated successfully, but these errors were encountered: