Server: FFMPEG Producers are not always freed

[ronag]

Producer are not always freed an can leak memory and hog cpu. Seems to happen when ffmpeg is stuck on IO.

Example, if you connect to an rtmp stream which is not delivering any data, it becomes impossible to kill the producer. I think the same thing might happen with HTTP. Are we missing an io timeout? interrupt request? or something else?

FFMPEG bug? Should we terminate/kill the thread after a timeout?

[ducthiem90]

It is error in code when open input:
```cpp
AVFormatContext* ic = nullptr;
FF(avformat_open_input(&ic, filename_.c_str(), input_format, &options));
auto ic2 = std::shared_ptr(ic, { avformat_close_input(&ctx); });
...
ic2->interrupt_callback.callback = Input::interrupt_cb;
ic2->interrupt_callback.opaque = this;
````
must alloc a context, set interruput callback before use it to open a url

[Julusian]

This is a compound of a couple of issues.
1) as @ducthiem90 suggested, the AVFormatContext was being setup incorrectly
1) The callback would always return ok, as abort_request_ wouldnt be changed until the producer was destroyed, which was blocked on waiting for input to respond.

This isnt helping in all cases though. As when interrupt_cb return 1, avformat_open_input will not call interrupt_cb again but will block for a further ~30 seconds. This was with a rtmp stream with no data.

Any suggestions on this? It feels to me like either a ffmpeg bug or some options need tweaking, but I dont know where to begin on that.

[ronag]

will block for a further ~30 seconds

I don't think this is a huge problem as long as it gets released eventually.

[ducthiem90]

This is a compound of a couple of issues.

1. as @ducthiem90 suggested, the AVFormatContext was being setup incorrectly
2. The callback would always return ok, as abort_request_ wouldnt be changed until the producer was destroyed, which was blocked on waiting for input to respond.

This isnt helping in all cases though. As when interrupt_cb return 1, avformat_open_input will not call interrupt_cb again but will block for a further ~30 seconds. This was with a rtmp stream with no data.

Any suggestions on this? It feels to me like either a ffmpeg bug or some options need tweaking, but I dont know where to begin on that.

Can you config a timeout to check in interrupt_cb?

[Julusian]

Can you config a timeout to check in interrupt_cb?

Not that I could find from a google. But it was calling it rapidly right up until it returned 1, which is what makes confuses me about this

[Julusian]

@ronag are you happy for this to be closed with the new fix from efe466db0310e740ad5bd42353d122997b0996c9?