Jump to content

What should my expectations be with live transcoding?


dnapoleon

Recommended Posts

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 post
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 post
Share on other sites

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 post
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 post
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 post
Share on other sites
cayars

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 post
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...