I see the same behavior (roughly 0.5x at 1080p) with both live and recorded programs.
Playing a recording with web client (safari), transcoding settles around 0.5x after 30 seconds or so. Same response on all recorded shows both both recently recorded and those recorded a couple of weeks ago. NAS CPU around 25%.
Playing a live TV stream seams flawless on all three channels i tried. Transcoding starts >2x and settles at around 1.08x after about 40 seconds. NAS CPU stays around 3-4 percent.
Are you using a PRIME? What does the log say when youâre streaming live tv? Iâm guessing the channel youâre watching is already H264, so no transcoding is required. The log probably says transcoder=remux
@chasut is that high def or standard content? I see a similar result when I stream a live SD broadcast. Starting >2x and settling just north of 1.0x
It might even stay around 2x for an SD recording.
But HD streams are .5x right from the start.
Makes sense I guess.
I wonder the expected behavior of the transcoder when it streams SD content with the setting on 1080P. Is it upscaling, or just sending in the native resolution?
A live broadcast is live. So it canât go much faster than 1x or you would be viewing the future.
That being said, my 216+ii transcodes previously recorded dvr shows at around 9x. So it is probably not the Linux kernel.
@tmm1, yes it turns out it was the Prime. I had the priority set for the Connect, but realized i had been initiating the live stream from âon nowâ tab, with the Prime selected. Log entry as you suggested. Mystery solved, didnât make sense that it would behave differently.
@bbowyer Yes, HD stream, but the problem was just me not paying attention.
Confirmed that Iâm seeing the same issue on DS916+. Transcoder rate is anywhere from 0.5-0.8x, which is much lower than I would expect for hardware transcoding. Will see if we can find a fixâŚ
2 Likes
The WD PR2100 has the same N3710 CPU, but runs kernel 4.1.13. It is able to transcode at faster than realtime.
My QNAP TS-251+ has a different Celeron (J1900), but a slightly newer kernel 3.12.6 and also transcodes files at faster than realtime.
The DS916+ is running kernel 3.10.77 with a i915 graphics driver from 2014 (i915 1.6.0 20141121).
We tried the DSM 6.1 RC, which uses a slightly newer kernel 3.10.102. Same issue.
Well this is disheartening. Correct me if I am wrong. So, Synology and QNAP for that matter use older kernels for stability reasons and therefor there is nothing that can be done if the kernel the NAS is using does not support faster hardware transcoding?
Not sure yet, weâre just reporting things as we find them. We have put in a bug report to Synology to see if they can investigate. It seems their own software is able to do some hardware transcoding, so itâs unclear why its not working for us. If anything, I would have expected it not to work at all, instead of working at half speed.
The QNAP kernel isnât much newer and works fine, so if we can find the particular patch that fixes the issue we might be able to get Synology to apply that patch to their kernel instead of upgrading the whole thing.
Iâve noticed something that may or may not be of interest. When using Synologyâs own DSVideoStation to stream a show recorded with Channels DVR to Chrome, the Synology launches a process called gs-launch-1.0 that seems to do the work. That appears to be an open source framework for multimedia called GStreamer.
This process doesnât launch when DSVideoStationâs hardware transcoding is disabled. Instead itâs just the ffmpeg process that does the work.
In contrast, when Channels DVR is streaming the same show to a browser, itâs always the ffmpeg that does the work, both with hardware or software transcoding selected.
So is Synology using some other method to access the hardware assist features of the processor? If GStreamer is open source, is that something that 3rd parties might have access to as well?
My gut tells me Synology is going to drag their feet with any Kernel upgrades. But we can all hope!
Thanks for going to great lengths to help resolve this.
Thatâs right, Synology is using gstreamer for hardware transcoding. This is because their ffmpeg is quite old and doesnât support hardware transcoding. The ffmpeg we use is much newer and supports hardware acceleration, and is working fine on other NAS and kernel versions.
Iâve tried comparing how gstreamer uses hardware transcoding vs how ffmpeg does it, but theyâre both pretty similar and its hard to tell why one is working better than the other on this specific hardware.
We have gotten in touch with the development team at Synology about this issue.
Strangely enough they tried it on a DS916+ themselves and are seeing 1.5x hardware transcodes. Hopefully we can figure out why its so much better for them and fix it for everybody else.
Here are the test commands we sent them:
cd /tmp
curl -o ffmpeg https://channels-dvr.s3.amazonaws.com/2017.02.01.0203/ffmpeg-linux-x86_64
chmod +x ffmpeg
curl -o sample.mpg https://s3.amazonaws.com/tmm1/sample.mpg
sudo ./ffmpeg -hide_banner -loglevel verbose -vaapi_device /dev/dri/renderD128 -i sample.mpg -c:v h264_vaapi -vf format=nv12,hwupload -b 4000k -f null -y /dev/null
When I run that here and it finishes, I see:
frame= 440 fps= 17 q=-0.0 Lsize=N/A time=00:00:15.34 bitrate=N/A speed=0.577x
17fps and 0.5x. However when Synology ran it they saw:
frame= 440 fps= 46 q=-0.0 Lsize=N/A time=00:00:15.34 bitrate=N/A speed=1.59x
If anyone can try it and post their results, along with the version of DSM installed that would be helpful.
I ran in ~/tmp, rather than /tmp, but canât imagine that makes a difference to anything. I got a number of warnings during the run, but in the end:
frame= 440 fps= 17 q=-0.0 Lsize=N/A time=00:00:15.34 bitrate=N/A speed=0.577x
Iâm on DSM 6.0.2-8451 Update 9
Also 0.577x on 6.1 RC1.
Though I do not have a DS916+, but the questions that I would wonder about would be
-
Does the process that transcodes need to start from a particular directory (maybe due to permissions in writing the temp file in the working directory, or RAMDisk in use to speed up part of the process)
-
What kind/speed drives are they using for testing⌠(not fair if they are using fast SSDs
)
frame= 440 fps= 16 q=-0.0 Lsize=N/A time=00:00:15.34 bitrate=N/A speed=0.569x
on DSM 6.0.2-8451 Update 9
No files are written during the test. I even removed the disk read by encoding empty black frames from RAM, and itâs just as slow.