dnapoleon 0 Posted Tuesday at 05:56 PM Share Posted Tuesday at 05:56 PM 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 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)? I have budgeted for an expensive video card (Quadro RTX 4000 or P2200 for the unlimited simultaneous encoding) . Will this solve any issues? 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
cayars 1890 Posted Wednesday at 02:07 PM Share Posted Wednesday at 02:07 PM 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
dnapoleon 0 Posted Wednesday at 04:40 PM Author Share Posted Wednesday at 04:40 PM (edited) 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 Wednesday at 04:43 PM by dnapoleon Link to post Share on other sites
Luke 26174 Posted Wednesday at 07:32 PM Share Posted Wednesday at 07:32 PM 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 0 Posted 6 hours ago Author Share Posted 6 hours ago 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 1890 Posted 6 hours ago Share Posted 6 hours ago 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
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now