fhdhr / fhdhr_plugin_stream_ffmpeg Goto Github PK

Currently building a proxy system for core, saving this here for later

ffmpeg -http_proxy=http://ip:port/

Hi,

To help offload transcoding, from CPU to GPU - enable / add in support for HW acceleration? For example, hevc_nvenc codec support?

Thanks!

The web UI has a field for bufsize (one F), but I needed to add a buffsize (2 'F's) to the config to get it to work.

I suggest changing the default value to be consistent with the code.

Hi,

I have noticed my log filling up with info from ffmpeg 🤣. I have the log level set to noob, then realized from this code that the banner and stats are on - but thinking for noob or info, that's not really desired. Agreed?

    def ffmpeg_loglevel(self):
        ffmpeg_command = []
        log_level = self.plugin_utils.config.dict["logging"]["level"].lower()

        if log_level in ["noob"]:
            log_level = "info"
        elif log_level in ["ssdp"]:
            log_level = "debug"

        loglevel_dict = {
                        "debug": "debug",
                        "info": "info",
                        "error": "error",
                        "warning": "warning",
                        "critical": "fatal",
                        }
        if log_level not in ["info", "debug"]:
            ffmpeg_command.extend(["-nostats", "-hide_banner"])
        ffmpeg_command.extend(["-loglevel", loglevel_dict[log_level]])
        return ffmpeg_command

Perhaps remove info from a level including stats and banner?

Thanks!

Hi,

OK, this was sort of tied before to "lagging" video - but trying to make it a bit more concrete. Ya, some of this will be a bit fuzzy yet 😜. But we'll figure it out.

The issue that I am seeing is video degrading vs. time (lagging, blocky, etc.), and trying to quantify this using VLC statistics. I (think) I see a tie in to log level as well, but that's perhaps just due to overall load (of Python?). But that all said, some data to try to explain, and then some observations below that. Yell of course if I'm just off base. Overall things are working quite well now, just minor little items - except for the dropping video.

And the data. I tried to capture (from VLC), Lost Video packets, and Dropped Input/Read (as VLC calls them). I ran this with my Ceton PCIe card, and tried both direct and ffmpeg. Also a couple of log levels. And as a baseline, I always ran in parallel with fHDHR a test with direct stream (direct, from /dev to vlc), clear; cat /dev/ceton/ctn91xx_mpeg0_3 | vlc -. So now, the data,

And, some observations - qualitative, and I maybe just just crazy, but hoping this helps,

1. The errors do seem to arrive in a bursty nature ... not dribbling in, but in "jumps"
2. The errors seem to "accelerate" vs. time ... starting slow, then getting worse. A good example is the last row - it ran quite clean for a long time ... then in the last ~ 40k frames it lost 3000 of them ... and actually, fHDHR restarted! I noticed it because the VLC video stopped, when to look at the log, and saw it had restarted. I have attached the full debug log for this one (sorry, I know it's long, but wanted to share it all in case it helps).
3. When the error count gets high, if I just stop the stream, start over ... it seems to be clean again.

I may be out to lunch here, but I'm wondering about memory leaks (typical for vs. time issues), but also ... perhaps run the generator in a separate thread? Or, use a Python queue? Then again, could it be because we aren't reading an integer number of packets each time? Again, just thinking out loud.

Unfortunately this tends to take a while to show up ... can be a few hours, so not quick to test. That said, let me know if there are things you want me to try.

Thanks!
crash-log.txt