Jump to content

What should my expectations be with live transcoding?


dnapoleon

Recommended Posts

dnapoleon

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

dnapoleon

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 by dnapoleon
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

dnapoleon

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

dnapoleon

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

dnapoleon

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

dnapoleon

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 by dnapoleon
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...