What should my expectations be with live transcoding?

[dnapoleon 0]

PC setup

• Windows 10
• AMD 1800x (8 core 16 thread)
• Corsair Vengeance 16 GB DDR4
• Samsung 860 EVO 500 GB
• Garbage Radeon HD5450
• Emby Premiere Subscription

Environment / Goals

• I have 16 4MP cameras that I have setup for trying to live stream to 4 televisions in a sudo matrix setup.
• I have used Emby on the LG TV directly and also with a new Chromecast for Google TV.
• Goal: Send upto 7 different RTSP streams to 7 TV's simultaneously.

Testing

My testing consists of a single camera and a single TV. The camera has been set all the way down to 720P, 20fps, 512 bit rate. 

Regardless of how I configure the camera, I always have about 20-30 seconds of lag between the actual moment in time of something happens and the replay. Even on the preview on the Emby dashboard. I assume that the lag is due to the buffering in Emby with the "segmenting" of the stream to the temp location in the FFMPEG commands. If I use VLC or similar to watch the steam I have sub second lag. 

In a second test...

I am a budding novice when it comes to FFMpeg and have configured a separate computer as an RTMP over NGINX server for transcoding the camera with FFMPEG and output to the RTMP service. This allowed me to test various "pre-transcodings" before handing off to Emby. I had the same results.

In all tests CPU usage is sub 5%.

Questions

1. Are there any FFMPEG setting that I can use that would help to "pre" transcode from my RTMP server? Making it so that Emby does not try to segment (if that is the issue)?
2. I have budgeted for an expensive video card (Quadro RTX 4000 or P2200 for the unlimited simultaneous encoding) . Will this solve any issues?
3. Do I need a separate SSD for segmenting purposes?

Attached is a short log file in case in has any value.

Thank you

ffmpeg-remux-2128e187-bdfd-41ec-9cdd-c4bb114b5e1b_1.txt

[Carlo 4552]

There is going to be lag time in a setup like this that you won't be able to avoid with the current software.
In the next version of Live TV however this lag will likely be much shorter because of the new pipeline being used.

[dnapoleon 0]

Will disabling transcoding in Emby help if I "pre transcode" the data before sending it into the LiveTV? Or is this not part of the pipeline that causing the issue?

Any link to the pipeline github issue or similar to watch for progress?

Thank you for your reply.

 

Edited February 24, 2021 by dnapoleon

[Luke 40137]

There's currently nothing you can do because we always run rtmp urls through ffmpeg rather than getting the stream with our own code. If you could somehow use http urls instead, then you'll have a shot at avoiding transcoding if the format of the stream can be played natively by the Emby app that you're using.

[dnapoleon 0]

So just transcode to HLS? Is that what you mean by http urls?

Would you be willing to give me the spec to get the stream to be played natively? 

Thank you so much Luke!

[Carlo 4552]

If you're camera doesn't support http out of the box it's not really worth you messing with as you would then be doing the same thing (transcoding) that Emby is doing for you.

[dnapoleon 0]

Cayars,

Do you support LL-DASH or LL-HLS?

The ffmpeg command in my attached log file appears to use MPEG-TS as the segment format. But the -segment_list_entry_prefix uses the pathing "hls/..."

The reason that I want to know is that I am assuming that you may have non-specific settings for segmenting. If I can tune mine or use a different protocol then I may be able to outperform Emby externally without waiting for the "pipeline" to change.

Thank you

 

[Carlo 4552]

Don't segment it and feed it to Emby.  If you have to touch the stream before it gets to Emby you're essentially going to be doing what Emby can already do so you're not gaining anything.

If you camera has a different mode built in then explore that.

[dnapoleon 0]

Sorry if I'm annoying you.

I'm not segmenting it, I feed it to Emby, Emby segments it. 

I need to know what to feed in that will still work with transcoding disabled to keep Emby from segmenting it. 

That is why I keep asking for specs, I will continue to reverse engineer the issue until I find something that will work. I just assumed it may be quicker to ask.

[Carlo 4552]

You're missing what I'm trying to convey and that is if the goal is to make it faster then you adding a transcode or other process before feeding Emby isn't likely going to help as you're just shifting where a transcode happens.

But if you want to try just create a TS stream using mpeg2 or H.264 video.

[dnapoleon 0]

It is logical to me as well, that if I add something in the middle then I am slowing down the process. 

This question is the one that probably should have been asked before...

If I send a stream that does not need to be transcoded, will Emby still use segmenting to hand off to the clients?

I was assuming that the segmenting was only necessary if transcoding is actually being performed. This is because I also assumed that Emby would stream copy the audio and video if the transcoding was unnecessary.

 

Edited February 28, 2021 by dnapoleon

[Carlo 4552]

There is no straight answer to that question.  If the client can play what you send it and not need anything done to it then it will try to direct play it but if anything needs to be changed it will need to be remuxed or transcoded.

Emby is very dynamic in this nature.  Just try it and see if you can improve the latency.