Transcoding problem with Nvidia 1050

All of my 4K movies playback fine using Emby server with the Emby Fire tablet app. Hardware transcoding works fine with my server using about 20%~25% CPU.

I also re-installed Plex on my server. All of my 4K movies play fine using Plex server with the Plex Fire tablet app. Hardware transcoding works great with my server using about 10% CPU.

When I try to play 4K movies on the Channels server using the Channels Fire tablet app NONE of my 4K movies will play back. Server CPU utilization bounces from 99% to 50%.

It doesn't seem to be a problem with my hardware. I recently installed Channels DVR so I don't have any weird setups.

Is there something that I am doing wrong? I don't get it.

When plex is transcoding, can you run this command in powershell and paste the output back:

Get-WmiObject Win32_Process | select commandline | Select-String -Pattern "Transcoder"

or this during emby transcoding:

Get-WmiObject Win32_Process | select commandline | Select-String -Pattern "ffmpeg"

Plex

Version 1.41.3.9314
Server CPU Utilization bounces from around 5% to 10%
Playback on the Fire 10 tablet is very good

PS C:\Users\Capt> Get-WmiObject Win32_Process | select commandline | Select-String -Pattern "Transcoder"

@{commandline="C:\Program Files\Plex\Plex Media Server\Plex Transcoder.exe" -codec:0 hevc -hwaccel:0 nvdec
-hwaccel_fallback_threshold:0 10 -threads:0 1 -hwaccel_output_format:0 cuda -hwaccel_device:0 cuda -codec:1 aac -ss
792 -analyzeduration 20000000 -probesize 20000000 -i
D:\media\movies\Tigers.2160p.4K.WEB.x265.10bit.AAC5.1.mkv -filter_complex
[0:0]hwupload[0];[0]scale_cuda=w=1920:h=1080:format=nv12[1] -map [1] -codec:0 h264_nvenc -b:0 15552k -maxrate:0 20736k
-bufsize:0 41472k -forced-idr:0 1 -r:0 23.975999999999999 -force_key_frames:0 expr:gte(t,n_forced*1) -filter_complex
"[0:1] aresample=async=1:ochl='5.1':rematrix_maxval=0.000000dB:osr=48000[2]" -map [2] -codec:1 libopus -b:1 768k
-segment_format matroska -f ssegment -individual_header_trailer 0 -flags +global_header -segment_header_filename
header -segment_time 1 -segment_start_number 792 -segment_copyts 1 -segment_time_delta 0.0625 -segment_list http://127.
0.0.1:32400/video/:/transcode/session/c0c89ea0a50331b3-com-plexapp-android/cb0d1a3d-edc6-412e-aaad-2c4a4131c601/manifes
t?X-Plex-Http-Pipeline=infinite -segment_list_type csv -segment_list_size 5 -segment_list_separate_stream_times 1
-segment_list_unfinished 1 -segment_format_options strip_dovi=1:output_ts_offset=10 -max_delay 5000000
-avoid_negative_ts disabled -map_metadata:g -1 -map_metadata:c -1 -map_chapters -1 media-%05d.ts -start_at_zero
-copyts -init_hw_device cuda=cuda:luid:00000000_000079f4 -filter_hw_device cuda -y -nostats -loglevel quiet
-loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/c0c89ea0a50331b3-com-plexapp-android
/cb0d1a3d-edc6-412e-aaad-2c4a4131c601/progress}

Emby

Version 4.8.10.0
Server CPU Utilization bounces from around 20% to 50%
Playback on the Fire 10 tablet is good

PS C:\Users\Capt> Get-WmiObject Win32_Process | select commandline | Select-String -Pattern "ffmpeg"

@{commandline="C:\Users\Capt\AppData\Roaming\Emby-Server\system\ffmpeg.exe" -loglevel +timing -y -print_graphs_file
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\logs\ffmpeg-transcode-96b8baa4-9609-4077-bc19-adab33dc0136_1g
raph.txt" -copyts -start_at_zero -init_hw_device "cuda=cuda:0" -f matroska,webm -ss 00:05:24.000 -c:v:0 hevc
-threads:v:0 1 -hwaccel:v:0 cuda -hwaccel_output_format:v:0 cuda -noautorotate -i
"D:\media\movies\Tigers.2160p.4K.WEB.x265.10bit.AAC5.1.mkv" -filter_complex
"[0:0]scale_cuda@f1=w=1920:h=1080:format=yuv420p,setsar@f2=sar=sar[f2_out0]" -map [f2_out0] -map 0:1 -sn -c:v:0
h264_nvenc -b:v:0 9583088 -g:v:0 72 -maxrate:v:0 9583088 -bufsize:v:0 19166176 -keyint_min:v:0 72 -r:v:0
23.976024627685547 -profile:v:0 main -c:a:0 copy -disposition:a:0 default -max_delay 5000000 -avoid_negative_ts
disabled -f segment -map_metadata -1 -map_chapters -1 -segment_format mpegts -segment_list
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB.m3u8" -segment_list_type m3u8
-segment_time 00:00:03.000 -segment_start_number 108 -individual_header_trailer 0 -write_header_trailer 0
-segment_write_temp 1 "C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_%d.ts"
-map 0:2 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment
-map_metadata -1 -segment_format webvtt -segment_list
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s2.m3u8" -segment_list_type
m3u8 -segment_time 00:00:03.000 -segment_start_number 108 -break_non_keyframes 1 -individual_header_trailer 1
-write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:05:24.000
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s2_%d.vtt" -map 0:3 -map 0:0
-an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1
-segment_format webvtt -segment_list
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s3.m3u8" -segment_list_type
m3u8 -segment_time 00:00:03.000 -segment_start_number 108 -break_non_keyframes 1 -individual_header_trailer 1
-write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:05:24.000
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s3_%d.vtt" -map 0:4 -map 0:0
-an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1
-segment_format webvtt -segment_list
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s4.m3u8" -segment_list_type
m3u8 -segment_time 00:00:03.000 -segment_start_number 108 -break_non_keyframes 1 -individual_header_trailer 1
-write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:05:24.000
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s4_%d.vtt" -map 0:5 -map 0:0
-an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1
-segment_format webvtt -segment_list
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s5.m3u8" -segment_list_type
m3u8 -segment_time 00:00:03.000 -segment_start_number 108 -break_non_keyframes 1 -individual_header_trailer 1
-write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:05:24.000
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s5_%d.vtt" -map 0:6 -map 0:0
-an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1
-segment_format webvtt -segment_list
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s6.m3u8" -segment_list_type
m3u8 -segment_time 00:00:03.000 -segment_start_number 108 -break_non_keyframes 1 -individual_header_trailer 1
-write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:05:24.000
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s6_%d.vtt" -map 0:7 -map 0:0
-an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1
-segment_format webvtt -segment_list
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s7.m3u8" -segment_list_type
m3u8 -segment_time 00:00:03.000 -segment_start_number 108 -break_non_keyframes 1 -individual_header_trailer 1
-write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:05:24.000
"C:\Users\Capt\AppData\Roaming\Emby-Server\programdata\transcoding-temp\27CEDB\27CEDB_s7_%d.vtt"}
1 Like

The latest pre-release should resolve this issue. Please let me know if you see any improvement.

Doesn't seem to work.

Version 2025.01.27.2217

[/] Use HEVC for transcoding
Use HEVC (H.265) for transcoding instead of H.264 for streaming to client apps. Requires hardware that can handle encoding HEVC.

On the Amazon Fire 10 tablet it just shows a spinning circle as if waiting.

http://dvr-media-server.local:8089/admin/log

2025/01/29 14:51:51.421389 [HLS] ffmpeg: file568-ip10.0.0.34:  [hevc_nvenc @ 0x23958c0] InitializeEncoder failed: invalid param (8): Unsupported Level.
2025/01/29 14:51:51.447095 [HLS] ffmpeg: file568-ip10.0.0.34:  Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
2025/01/29 14:51:51.532525 [ENC] Encoder stopped after starting from 16 without encoding any segments. Marked segment as failed.

Does it work without HEVC enabled?

with HEVC disabled it displays the following error message on the Fire Tablet after 30 seconds:

! Connection Lost
The connection to Channels DVR Server had a problem. Press play to try again.
failed after 31.012173925s: hls: temporary failure while downloading: Get "http://10.0.0.250:8089/dvr/files/568/hls/stream.m3u8/stream0.ts?acodec=copy&bitrate=2000&indexed=true&level=40&resolution=576&scodec=copy&ssize=1&vcodec=h264": context canceled

Please submit diagnostics from the DVR.

This is what it shows in the log:

2025/01/29 16:20:51.976526 [ENC] Starting encoder in /home/capt/channels-data/Streaming/file568-ip10.0.0.34-721020452/encoder-0-1039637583 at 0 (0.000000) (encoder=h264_nvenc, codec=h264, acodec=copy, resolution=576, deinterlacer=blend, bitrate=2000, segment_size=0.01)
2025/01/29 16:20:52.134937 [HLS] ffmpeg: file568-ip10.0.0.34:  [tonemap @ 0x23dc8000] Tonemapping works on PQ only
2025/01/29 16:21:53.951757 [HLS] Stopping inactive session file568-ip10.0.0.34

You can submit diagnostics by doing to Support -> Troubleshooting -> Submit Diagnostic Logs from the web interface of the DVR and providing the ID it gives you.

Logs have been submitted as c01db35c-8ab5-41c6-b42b-2eab063c328e .

Could you try the latest pre-release and see if that resolves your issue?

If not, please run this to make a sample of the file you're having problems with:

 ffmpeg -ss 00:05:00 -i 'Shrek.2001.2160p.4K.BluRay.x265.10bit.AAC5.1-[YTS.MX].mkv' -t 5 -c copy output.mkv

and then upload it to our dropbox: https://www.dropbox.com/request/MMjICRc053JJpSBPDIfQ

After updating to the latest Channels DVR I am getting the following error in Chrome browser:

Your connection is not private

Attackers might be trying to steal your information from dvr-media-server.local (for example, passwords, messages, or credit cards). Learn more about this warning

net::ERR_CERT_AUTHORITY_INVALID

Turn on enhanced protection to get Chrome's highest level of security

Well, on the plus side it does seem to be working now.

On the down side, all 4 cores of my server CPU go to almost 100%.

Just want to add that when watching the same movie using Plex the CPU load stays fairly low.

I have a dumb question.

When I look at ffmpeg in the channels-dvr folder it shows the following:

ffmpeg version 5.0.2 Copyright (c) 2000-2022 the FFmpeg developers

Is this the version that Channels DVR is using?

Why isn't Channels using a newer version like 7.1?

I have no idea if this would make a difference with transcoding but it might.

Nothing changed that would impact that. You may have accidentally specified https://dvr-media-server.local to trigger that error.

Please run:

ps auxww | grep ffmpeg

and provide the output.

Because we update from time to time when we have the resources to do so.

It's likely it's an issue with how we are doing the transcoding, but I would not know for sure without more details.

If you could do this, it will help me run some tests on the content:

File uploaded

capt@media-server:~/channels-dvr/latest$ ps auxww | grep ffmpeg
capt        6141  374  5.2 10012696 604628 ?     Sl   16:52   0:26 /home/capt/channels-dvr/2025.01.30.2024/ffmpeg-dl -hide_banner -nostats -loglevel warning -progress http://127.0.0.1:8089/dvr/files/568/hls/progress?key=file568-ip10.0.0.34 -fflags discardcorrupt+genpts -ss 427.8439999999998 -copyts -start_at_zero -probesize 8000000 -i /data/Movies/S.2001.2160p.4K.BluRay.x265.10bit.AAC5.1-[YTS.MX].mkv -enc_time_base -1 -max_muxing_queue_size 4096 -muxdelay 0 -map 0:v:0? -map 0:a? -ignore_unknown -map 0:s? -c:v h264_nvenc -g:v 60 -force_key_frames:v source -forced-idr 1 -profile:v high -level 40 -filter:v fastdeint=blend,format=yuv420p,scale=-2:min(ih\,576):eval=frame -b:v 1000k -minrate 900k -maxrate 1100k -bufsize 2000k -c:a copy -c:s copy -f hls -hls_time 0.010000 -hls_list_size 0 -hls_flags temp_file -start_number 101 -hls_passthrough_subtitles 1 /home/capt/channels-data/Streaming/file568-ip10.0.0.34-1614291663/encoder-102-4248978845/stream.m3u8
capt        6165  0.0  0.0   6620  2336 pts/0    S+   16:52   0:00 grep --color=auto ffmpeg

Great! Thanks for the details. It appears everything is operating as expected regarding the arguments that we are passing. We believe we have identified where the Plex encoder is using some efficiencies that we are not and are looking into what it would take to improve this.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.