DS916+ Emby transcoding performance

[newb 14]

Hi @@solabc16

 

I would also like to express my interest in getting transcoding to work on Synology devices.

My device is a DS216+II, so should be in the same family as the DS916+. Please let me know if I should rather start a separate thread though, since this thread was originally about the DS916+.

 

Logs: sendlogs_diskstation_synology_braswell_216+II_20161016T113744UTC.tgz

admin@diskstation:/$ ls -l /dev/dri/
total 0
crw------- 1 root root 226,   0 Oct 16 08:59 card0
crw------- 1 root root 226,  64 Oct 16 08:59 controlD64
crw------- 1 root root 226, 128 Oct 16 08:59 renderD128

[solabc16 379]

Hello @@newb

 

I've added you to the PM conversation with @@stratumorien, so you can grab the latest development package as well.

 

@@stratumorien, no problems catch up later, it will almost certainly be related to permissions; which would be expected.

 

- James

[newb 14]

Thank you @@solabc16, I have updated to the latest dev package and will start experimenting!

[Luke 38093]

That looks like a failure being interpreted as invalid. By failure I mean failure on the part of the server to run ffmpeg -version and extract the result. i'm saying that because there isn't anything in that result that the server would reject. i will have to add more logging so that we can track it down.

[solabc16 379]

"Synology do not include FFprobe with DSM, so the error you are getting when trying to swith to the version of FFmpeg found in /usr/local is expected."

[Luke 38093]

Thanks !

[stratumorien 8]

Would the recording based transcoding option (to mkv) not be taking advantage of hardware acceleration? Currently CPU is maxed recording/transcoding Curious George.

 

record_transcode.txt

[Luke 38093]

the recording process does not yet use hardware acceleration, no.

[stratumorien 8]

ok, thanks for confirming @@Luke

[poerlemans 5]

@@Luke @solabc16:

 

Phantastic!!

I just installed the beta version 3.1-193-0 on my Synology DS216+.

I choose for Intel QuickSync hardware acceleration and tested the playback of a 1080p 60Mbps movie in the webbrowser.

The results are very good!:

• No playback interruptions anymore.
• CPU activity between about 4 - 12%.

There was one problem: at the start of playing a sign is showing that playback isn't possible (however in reality playback isn't giving any problem). At pressing on the OK-button, playback is stopped.

 

Included the logs.

ffmpeg-transcode-68cdabad-b556-4419-b6cb-65a9c2674622.txt

server-63612384705.txt

[solabc16 379]

Hello @@poerlemans

 

The latest beta includes hardware transcoding support for the VA API, not Intel Quick Sync Video, so there's something else going on here.

 

Can you try again with hardware acceleration set to "Video Acceleration API (VA API)".

 

Also, can you run the diagnostics (https://github.com/MediaBrowser/Wiki/wiki/Synology-:-How-to-Run-Diagnostics) and send logs (https://github.com/MediaBrowser/Wiki/wiki/Synology-:-How-to-Send-us-Support-Logs) utilities, so we can see what's really going on behind the scenes.

 

Thanks

- James

Edited October 18, 2016 by solabc16

[poerlemans 5]

Hello @@poerlemans

 

The latest beta includes hardware transcoding support for the VA API, not Intel Quick Sync Video, so there's something else going on here.

 

Can you try again with hardware acceleration set to "Video Acceleration API (VA API)".

 

Also, can you run the diagnostics (https://github.com/MediaBrowser/Wiki/wiki/Synology-:-How-to-Run-Diagnostics) and send logs (https://github.com/MediaBrowser/Wiki/wiki/Synology-:-How-to-Send-us-Support-Logs) utilities, so we can see what's really going on behind the scenes.

 

Thanks

- James

I repeated the playback.

I adjusted Video Acceleration on VA API.

Playback went smoothly. No disturbances now. But CPU activity higher (between 24% and 39%).

Included the logs. I will run diagnostics shortly.

[poerlemans 5]

Hello @@poerlemans

 

The latest beta includes hardware transcoding support for the VA API, not Intel Quick Sync Video, so there's something else going on here.

 

Can you try again with hardware acceleration set to "Video Acceleration API (VA API)".

 

Also, can you run the diagnostics (https://github.com/MediaBrowser/Wiki/wiki/Synology-:-How-to-Run-Diagnostics) and send logs (https://github.com/MediaBrowser/Wiki/wiki/Synology-:-How-to-Send-us-Support-Logs) utilities, so we can see what's really going on behind the scenes.

 

Thanks

- James

I repeated the playback.

I adjusted Video Acceleration on VA API.

Playback went smoothly. No disturbances now. But CPU activity higher (between 24% and 39%).

Included the logs. I will run diagnostics shortly.

ffmpeg-transcode-747466b0-81ea-4e00-90de-9a7892364a4e.txt

server-63612386950.txt

[poerlemans 5]

I sent logs.

See:

sendlogs_Meterkast_synology_braswell_216+_20161018T094356UTC.tgz

[solabc16 379]

Thanks @@poerlemans, I'll take a look.

 

The playback with acceleration set to Intel Quick Sync definitely fails (as expected), with the error "Error initializing an internal MFX session".

 

This will be the cause of the "playback isn't possible" message you saw.

 

When you playback with hardware acceleration set to 'None', what is your typical CPU utilisation?

 

- James

[solabc16 379]

...can you post a screenshot of the 'Media Info' section from the Web UI, for the title 'Chez Benali.S01E03.ts'.

 

Thanks

- James

[poerlemans 5]

Without hardware acceleration CPU utilisation is 87-92%.

Below a screenshot of Chez Benali S01E03.ts.

[solabc16 379]

Thanks @@poerlemans. These are early days for hardware transcoding support, so I expect there will be a few things we'll need to work through.

 

My initial thoughts on the above are to understand why it is not direct playing in the first place.

 

What appears to be happening, as a result of the error being caused by acceleration being set to Intel QSV, is that it is then actually direct playing.

 

This is why you see such remarkably low CPU utilisation figures during playback.

 

Can we try and repeat this, so we can work from a single log...

 

1) Set hardware transcoding to Intel QSV.

2) Stop and Start Emby Server

3) Attempt playback in the WebUI of Chez Benali.S01E03.ts.

4) Acknowledge any errors like you did before.

 

Let us know what happens and can you attach the most recent server log at the end.

 

Thanks

- James

[poerlemans 5]

@@solabc16

 

James,

I carried out the test according your proposal.

The same phenomena as during the first test with QSV: Sign that video playing is going wrong, but in the same time a smoothly playing video.

CPU utilization somewhat higher: between 9% and 20%.

Included are the logs.

ffmpeg-transcode-a0c28eef-6b77-4e19-8f1b-aa1d14ebdb7e.txt

server-63612403824.txt

[solabc16 379]

Hello @@poerlemans

 

Thanks for the attached logs, this confirms my findings from analysis of the previous set of logs.

 

We're being subtely tricked here as to what is actually happening.

 

The playback of Chez Benali.S01E03.ts is failing, as expected, with "Error initializing an internal MFX session" due to QSV not being currently supported.

 

Now, I'm suspecting you have autoplay next episode enabled, as what is happening after playback fails is 'Chez Benali.S01E04.mp4' starts playing.

 

This file apepars to be being sourced from Dropbox: https://api.dropbox.com/1/media/auto/*****/General-High/TV/ChezBenali/Chez Benali.S01E04.mp4

 

Are you able to PM me a link to 'Chez Benali.S01E03.ts', so I can look further into why this doesn't direct play?

 

- James

[solabc16 379]

Hello All

 

Release 3.0.8200.0-1 has been published today for Synology/XPEnology, which includes experimental support for VA API h/w transcoding on 'braswell' based machines.

 

Many thanks to @@stratumorien, @@moulin and @@newb for working through this with us.

 

Please let us know how you get on and post any comments or queries here.

 

This is a new feature, hence comes with the tag 'experimental' and I'm sure we'll need to work through and refine a few things along the way.

 

- James

Edited October 18, 2016 by solabc16

[poerlemans 5]

Hello @@poerlemans

 

Thanks for the attached logs, this confirms my findings from analysis of the previous set of logs.

 

We're being subtely tricked here as to what is actually happening.

 

The playback of Chez Benali.S01E03.ts is failing, as expected, with "Error initializing an internal MFX session" due to QSV not being currently supported.

 

Now, I'm suspecting you have autoplay next episode enabled, as what is happening after playback fails is 'Chez Benali.S01E04.mp4' starts playing.

 

This file apepars to be being sourced from Dropbox: https://api.dropbox.com/1/media/auto/*****/General-High/TV/ChezBenali/Chez Benali.S01E04.mp4

 

Are you able to PM me a link to 'Chez Benali.S01E03.ts', so I can look further into why this doesn't direct play?

 

- James

 

Hi James,

 

Sorry, I didn't knew that but you are right: in QSV-hardware mode the documentary S01E03.ts doesn't start but the next file S01E04.mp4 (with less resolution, placed in Dropbox) is started.

In the case of VA-API hardware mode, the right documentary S01E03.ts is started. Sorry, sorry, sorry.

I put the file CHez Benali.S01E03.ts on Google Drive.

I will send yoy the link.

[stratumorien 8]

Attached is a transcode log with VAAPI enabled in 3.0.8200.0-1

 

Note that playback was initiated for LIve TV (Channel 600, CNN HD) from Chrome remotely (WAN). Playback is smooth, CPU usage for ffmpeg is ~10% vs ~85% when there is no HW acceleration.

 

Nothing negative to report just wanted to share my log in the event there is useful information for further optimizations.

Transcode_VAAPI_remote_Chrome.txt

Edited October 18, 2016 by stratumorien

[Luke 38093]

Very nice results there, thanks !

[solabc16 379]

Hi @@poerlemans, no worries at all, all part of the process of getting up to speed with new features.

 

I'll have a look at that file when you get the link across to me.

 

- James