Enable ffmpeg, for Direct (/dev) Stream

[arrmo]

Hi,

I think this one is a screw up by me - confused a bit by "stream" ... as there is streaming from the source, and then of course from fHDHR to the client. In the code currently ffmpeg is sort of "tied" to rtp, but not sure that makes sense. And really - direct from /dev to ffmpeg would be very handy => encode (possibly in HW), on the source side, reduce the bit rate to the client.

I did hack this up here, and can make it work, but I would appreciate your thoughts, @DanAustinGH. I can see a couple options,

1. add a new configuration variable, for direct => to go through ffmpeg or not. Basically, allow direct from /dev to be transcoded (vs. now, where it's tied to direct read only)
2. no new variable, rather in the pcie case, always get the stream from /dev ... never use rtp for the (internal) HW. I'm almost thinking this one makes more sense => why add rtp "overhead" for the pcie card

Somewhat thinking out loud here, please do comment. I can set this up either way, and don't have a real strong preference ... but would like to be able to transcode on the source end, really for a couple reasons, a. I am seeing less dropped packets if I lower the bit rate to clients (like ffmpeg, Plex). And really, why waste the BW. b. if I already transcode before going to Plex => Plex doesn't need to transcode (i.e. I have more manual control), and recordings are already in the format I want. No post-processing to transcode!

Again, please let me know your thoughts. Thanks!

[DanAustinGH]

I favor option 2. I do/did feel that RTP should work, but that does not mean it makes sense to use it. I think one of the early tests we had ffmpeg reading from the device. Couple that with the quality settings that @deathbybandaid has already added and I think you are pretty close to this goal. With option HW acceleration you could shoot for real-time H264 or even H265 and seriously trim the bandwidth to emby/plex and the clients.

[arrmo]

OK, I'll modify the code here then, go with Option 2 - it's your plugin, want to make sure you're happy with any mods! And agree rtp is cool, but not really necessary for the pcie card, extra overhead (and adding extra config variables is more confusing). I'll try to get you a PR to look at a bit later today.

With option HW acceleration you could shoot for real-time H264 or even H265 and seriously trim the bandwidth to emby/plex and the clients.

With my hacks, I actually had that running overnight (h.264_nvenc), to test it out => I ran 2 tuners / clients in parallel, ffmpeg to show me stats. Dropped packets was fine (no increase), and bit rate was ~ 2.5 Mbps, down from the raw ~ 16 Mbps. Then Plex ... no transcode, recordings are real time ready. Life is good 😄.

Again, will try to get you something a bit later today to shoot arrows at.

[DanAustinGH]

Meh. I was in line to buy the new HDR 6 tuner that Silicon Dust killed off before shipping. I found a Ceton 6, and actually was quite impressed with the build quality. Sadly software was non-existent and not supported by Emby. I found a windows only emulator, but don't use Windows on my media server, so I tweaked it to run in Wine, which was a pain since my server is headless.

That code is in delphi and to my eye very hard to read, so I fired up a copy of wireshark and documented the API calls from the emulator to the Ceton, which then let me tweak one of @deathbybandaid plugins to provide basic functions. I am not a developer and had not worked with Python before. The fact I have ben able to use it for 6 months to watch and record TV has been way more than I expected.

All that is a long-winded way to say I won't be overly critical and hugely appreciate your efforts. I am only aware one one other user of this plugin and if we three are happy, all is good.

[arrmo]

Sounds great, thanks!

OK, I think I have it all working here - just pushed #29. Please take a look, comment by all means! I did check both "direct" and "ffmpeg", and they work with pcie => but I can't test external of course. A few notes to help understand,

1. I left (on purpose) rtp and /dev detection in ... that way other clients using the HW are detected still.
2. startstop is still there, just based on HW type (i.e. don't start rtp, but now on pcie only, vs. "direct" ... which is a stream_method)
3. if you add transcode_quality in the [ceton] section ... it pulls and uses it. You can use one of the already defined ones, or I can share with you my "test" (HW encoding) one. Just let me know. But that said, I do have it running right now with h.264_nvenc!

Thanks!

[arrmo]

Oh, and I do notice ... when HW transcoding is enabled on fHDHR / ceton, it is a bit slower to start up. I think it's just the HW setup, etc. To me, not a huge deal, a few seconds. But so you know.

[DanAustinGH]

I would be interested to see what your custom profile looks like.

[arrmo]

Sure, NP at all! I added a new one, just hacked in for now, and set this in config.ini,

        elif stream_args["transcode_quality"] == "nvenc720":
            ffmpeg_command.extend([
#                                    "-hwaccel", "cuda",
#                                    "-i", "pipe:",
                                    "-c:v", "hevc_nvenc",
                                    "-s", "hd720",
                                    "-c:a", "copy",
                                    "-f", "mpegts",
                                    ])

Had to fiddle a bit, output file format and codec seem to have to play nicely (or not 🤣) with ffmpeg, Plex (clients). It's running right now, codec confirmed in ffmpeg. Bit rate is ~ 2-3 Mbps.

Give it a try? You can also select one of the options already in the file, SW transcoders. Should also work - just add to the [ceton] section (my case),

transcode_quality = nvenc720

[arrmo]

BTW, @DanAustinGH - close this one now, with the recent merge?

Thanks!

[DanAustinGH]

Sure!