New QNAP Package for Testing

[DNM 3]

Did you try going into the server transcoding menu and enabling vaapi support?

Novice here!. Could you provide a bit more detail on how to access to menu to be able to enable “vaapi”?

[Luke 37178]

In the emby server dashboard under the Transcoding menu. You can learn more here:

 

https://github.com/MediaBrowser/Wiki/wiki/Transcoding

 

Thanks.

[Allex 8]

If you're wondering why it's because we have to build for QNAP on a QNAP device, therefore it's not hooked into our automated build system. We're not going to manually produce daily betas as that will just be too much for us to handle. The reason the other NAS devices do get betas is because their build processes are bit more flexible.

I was only wondering because of SSL issue, that's loosing connection. Do you know if that's going to be fixed in next stable release.

[DNM 3]

Perfect!

 

Thanks so much...will test some more tomorrow.

[plexrefugee 0]

Loving this app so far, the support for HDR x265 direct play is fantastic - I am blown away with the speed and stability, and your support for subtitles on the samsung Tizen app..

 

I am now only left with figuring out how to implement sharing, adding telegram connectivity from an equivalent app to PlexPy and I am buying a lifetime pass..

[Luke 37178]

Thanks for the feedback !

[Allex 8]

Luke, why xbox one x can't play hdr and 7.1 audio in hevc 10bit direct play?

[syplex 4]

I'm getting the https crash too. Anything I can do to help you figure this out?

[Luke 37178]

We are looking into it, thanks.

[frgabriel 0]

Whenever I try to play any media from the iOS app, the Emby server freezes and I need to restart it from the QNAP interface. Is this the same SSL issue, if so any workaround to be able to use the iOS app in the meantime? Happens locally FYI, not on a WAN connection.

[Luke 37178]

Whenever I try to play any media from the iOS app, the Emby server freezes and I need to restart it from the QNAP interface. Is this the same SSL issue, if so any workaround to be able to use the iOS app in the meantime? Happens locally FYI, not on a WAN connection.

 

How to report a problem. Thanks.

[Luke 37178]

The build in the first post has been updated with the 3.2.40 release. Thanks guys.

[raven-au 17]

The build in the first post has been updated with the 3.2.40 release. Thanks guys.

 

I see that the r600 (Radeon) vaapi driver is included in this as well as libva 2.0.

 

I'll check that out for hardware transcoding on the QNAP Radeon based device I have.

 

But I found that this didn't work with, at one point a message about B frames not supported, and at another point it was looking for the radeonsi dri driver, not sure what I did there.

 

Another problem I had was the libstdc++ library version was too old but ffmpeg (and presumably the libraries) appear to have been compiled with gcc 6.3 which uses a newer version of stdc++.

Maybe I missed that (ffmpeg had been compiled with a later gcc) earlier and was using the wrong libs and an older version of mesa so I guess there is some hope this will work.

 

Ian

[Luke 37178]

Another problem I had was the libstdc++ library version was too old but ffmpeg (and presumably the libraries) appear to have been compiled with gcc 6.3 which uses a newer version of stdc++.

Maybe I missed that (ffmpeg had been compiled with a later gcc) earlier and was using the wrong libs and an older version of mesa so I guess there is some hope this will work.

 

Ian

 

What Emby problem does this translate too?

[raven-au 17]

What Emby problem does this translate too?

 

By building and dropping in the appropriate shared libraries I wasn't able to get Radeon vaapi hardware transcoding to work.

 

Maybe not your problem but since the r600 Radeon vaapi driver is now included in the qpkg you guys probably would like some feedback on testing.

I have removed Emby and installed from scratch to check this out.

[macvirii 0]

By building and dropping in the appropriate shared libraries I wasn't able to get Radeon vaapi hardware transcoding to work.

 

Maybe not your problem but since the r600 Radeon vaapi driver is now included in the qpkg you guys probably would like some feedback on testing.

I have removed Emby and installed from scratch to check this out.

 

I just tried as it is, but no game too:

 

radeonsi: driver missing

[AVHWDeviceContext @ 0x1450440] libva: /share/CACHEDEV1_DATA/.qpkg/EmbyServer/lib/dri/r600_drv_video.so init failed

[AVHWDeviceContext @ 0x1450440] Failed to initialise VAAPI connection: 2 (resource allocation failed).

major_brand : isom

Device creation failed: -5.

minor_version : 1

Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Input/output error

compatible_brands: isom

Error parsing global options: Input/output error

[raven-au 17]

I just tried as it is, but no game too:

 

radeonsi: driver missing

 

 

The radeonsi driver is probably dlopen()ing this as part of Radeon device detection (it doesn't show as a dependent library with ldd).

 

To build the radeonsi driver from mesa you need LLVM and a bunch of X11 libraries (IIRC), it's hard work.

And if you get that far then there's every chance you'll get "B-frames not supported" message after a successful vaapi open.

 

Ian

Edited November 25, 2017 by raven-au

[alucryd 217]

@@raven-au We're shipping the libstdc++ directly from the toolchain that was used to build everything, it can't be the wrong version, or did you mean you had another one lying around?

 

As for radeonsi, sadly yes it needs llvm (but no X11 libraries, they can be disabled, and they already are to get the r600 driver to build), and building with the on on my system, even statically linking against it, is a no go. It will link against my system glibc instead of the one from the toolchain, which is way too recent for QNAP. I'd need to first build llvm with my toolchain, then build mesa, but I don't exactly want to take on such a long and daunting task if it ends up spouting "B-frames not supported" all over the place.

[Allex 8]

Does anyone know why emby transcode every single hevc files to x264 from qnap ts870 on xbox one x?

[Luke 37178]

Does anyone know why emby transcode every single hevc files to x264 from qnap ts870 on xbox one x?

 

We are working on an update for the xbox app to resolve this, thanks.

[raven-au 17]

@@raven-au We're shipping the libstdc++ directly from the toolchain that was used to build everything, it can't be the wrong version, or did you mean you had another one lying around?

 

As for radeonsi, sadly yes it needs llvm (but no X11 libraries, they can be disabled, and they already are to get the r600 driver to build), and building with the on on my system, even statically linking against it, is a no go. It will link against my system glibc instead of the one from the toolchain, which is way too recent for QNAP. I'd need to first build llvm with my toolchain, then build mesa, but I don't exactly want to take on such a long and daunting task if it ends up spouting "B-frames not supported" all over the place.

 

First please understand that I have not worked with cross compiled environments before, this little excursion was meant to be a learning experience wrt. cross compiling and it has satisfied that goal, so I'm happy.

 

As for the libstdc++, when I was building these things I thought there was no libstdc++ in the Emby qpkg, maybe there wasn't at the time, I just noticed it in the latest qpkg.

So, at the time, I couldn't build with a later version of mesa (IIRC).

 

Anyway, I have now built these things (including the latest mesa) with a gcc 6.3 crosstool-ng toolchain and we'll see how it goes.

I suspect the Radeon vaapi driver (or one or more of it's dependencies) was never properly finished, I'll try and talk to Dave Airlie at LCA in January and see if he is familiar with this code.

 

I can't remember now what pulled in the X11 libraries, perhaps it was the omx stuff or the vdpau stuff .... doesn't really matter anyway.

 

The vaapi interface is the only method that can be used with this, the ffmpeg is compiled with vaapi support only and re-compiling ffmpeg is another major dependency madness undertaking.

That's about were I got to weary with this and stopped working on it.

 

There was a suggestion somewhere that omx isn't very good so I won't continue with that either.

Also I don't see any way to utilize vdpau from the server configuration so that's not worth it either.

 

The only other thing to try is a radeon vaapi driver that uses vdpau as a backend.

When I tried that in the past it failed silently, no messages whatsoever, so there was no way to know what sort of problem there was with it.

 

Ian

[raven-au 17]

As for radeonsi, sadly yes it needs llvm (but no X11 libraries, they can be disabled, and they already are to get the r600 driver to build), and building with the on on my system, even statically linking against it, is a no go. It will link against my system glibc instead of the one from the toolchain, which is way too recent for QNAP. I'd need to first build llvm with my toolchain, then build mesa, but I don't exactly want to take on such a long and daunting task if it ends up spouting "B-frames not supported" all over the place.

 

The LLVM cross compile was a big pain.

 

I think this is what got around the sort of problem you pointed out (called QNAP.cmake below) :

# this one is important
SET(CMAKE_SYSTEM_NAME Linux)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)

# specify the cross compiler
SET(CMAKE_C_COMPILER   $ENV{CROSS_TOOLS}/bin/x86_64-QNAP-linux-gnu-gcc)
SET(CMAKE_CXX_COMPILER $ENV{CROSS_TOOLS}/bin/x86_64-QNAP-linux-gnu-c++)

# where is the target environment 
SET(CMAKE_FIND_ROOT_PATH  $ENV{CROSS_FS})

# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

along with something along the lines of:

.PHONY: llvm
llvm:
        @if test -d $(BUILD)/$(PKG_LLVM); then \
                rm -rf $(BUILD)/$(PKG_LLVM); \
        fi
        tar Jxf $(TARS)/$(PKG_LLVM).tar.xz -C $(BUILD) && \
        mkdir $(BUILD)/$(PKG_LLVM)/build && \
        cd $(BUILD)/$(PKG_LLVM)/build && \
        export CROSS_TOOLS=$(TOOLS); \
        export CROSS_FS=$(TARGET); \
        cmake -DCMAKE_CROSSCOMPILING=1 \
              -DCMAKE_TOOLCHAIN_FILE=$(TOP)/QNAP.cmake \
              -DCMAKE_INSTALL_PREFIX=$(TARGET) \
              -DLLVM_TARGETS_TO_BUILD="AMDGPU;X86" \
              -DLLVM_ENABLE_TERMINFO=OFF \
              -DLLVM_ENABLE_LIBEDIT=OFF \
              -DLLVM_INCLUDE_DOCS=OFF \
              -DLLVM_INCLUDE_EXAMPLES=OFF \
              -DLLVM_BUILD_TESTS=OFF \
              -DLLVM_BUILD_LLVM_DYLIB=ON ..; \
        cmake --build .; \
        cmake --build . --target install
        rm -f $(TARGET)/lib/*la

There's almost certainly a better options selection than I have used but this might be a start.

 

There's also the problem of llvm-config.

It sometimes returns different paths depending on where it is run from and sometimes just crashes causing incorrect builds or failed builds.

 

I ended up using this as llvm-config:

#!/bin/bash

fix_paths()
{
	local IN="$1"

	echo -n ${IN} | sed -e "s?${TOP_DIR}/host/?${TOP_DIR}/target/?"
}

VAL=`${TOP_DIR}/host/bin/llvm-config.real $@`
fix_paths "${VAL}"

and got the llvm-config.real from this:

.PHONY: llvm-host
llvm-host:
        @if test -d $(BUILD)/$(PKG_LLVM); then \
                rm -rf $(BUILD)/$(PKG_LLVM); \
        fi
        tar Jxf $(TARS)/$(PKG_LLVM).tar.xz -C $(BUILD) && \
        mkdir $(BUILD)/$(PKG_LLVM)/build && \
        cd $(BUILD)/$(PKG_LLVM)/build && \
        cmake -DCMAKE_INSTALL_PREFIX=$(HOSTROOT) \
              -DLLVM_TARGETS_TO_BUILD="AMDGPU;X86" \
              -DLLVM_ENABLE_TERMINFO=OFF \
              -DLLVM_ENABLE_LIBEDIT=OFF \
              -DLLVM_INCLUDE_DOCS=OFF \
              -DLLVM_INCLUDE_EXAMPLES=OFF \
              -DLLVM_BUILD_TESTS=OFF \
              -DLLVM_BUILD_LLVM_DYLIB=ON ..; \
        cmake --build .; \
        cmake --build . --target install
        cp -f $(HOSTROOT)/bin/llvm-config $(HOSTROOT)/bin/llvm-config.real
        cp -f $(TOP)/bin/llvm-config $(HOSTROOT)/bin/llvm-config
        rm -f $(HOSTROOT)/lib/*\.la

I can post more information about the various macros if you can't work out what they are but most should be fairly obvious.

Edited November 26, 2017 by raven-au

[raven-au 17]

And while we're at it, there's also the circular dependency of libva depending on mesa and mesa depending on libva to build the vaapi driver.

 

To get around that I build mesa with va disabled, then build the libva stuff and finally build mesa again with va enabled.

 

If there's anything you think I'm doing wrong or that I've missed in my approach (causing the drivers to be built incorrectly) then I'm all ears.

 

Cheers,

Ian

[austie 3]

I found that running off my QNAP TS-569L with 3GB of ram running nothing more than Emby that with my Xbox One S if something was in full 1080p it would stop and start.

Then when I tried to get a standalone laptop to run Windows Media Centre so my Xbox 360 could see the server, found that it was just too much.

 

So I've now reverted to a Windows 10 laptop with a i7 2nd gen processor 8GB of ram and an onboard Nvidia 610 2gb video card.

It is also running WMC for the Xbox side of things

Since the move I've found all my previous Emby issues get resolved except one where it won't pick up the correct series for some unknown reason.

 

When running the QNAP version and not the community version I found improved performance but the 1080p videos just was the ultimate killer for me.

[raven-au 17]

I found that running off my QNAP TS-569L with 3GB of ram running nothing more than Emby that with my Xbox One S if something was in full 1080p it would stop and start.

Then when I tried to get a standalone laptop to run Windows Media Centre so my Xbox 360 could see the server, found that it was just too much.

 

The TS-569L is an Intel Atom dual-core @2.13 GHz.

The TS-453 Pro is a Celeron quad-core @2.0 Ghz and is barely capable of transoding 1080p so the TS-569L has even less chance of doing this.

 

I don't know what graphics hardware the TS-569L has but it probably isn't Intel HD graphics of some sort so the hardware transcoding feature of the qpkg here probably won't work.

The TS-453 Pro does have Intel HD Graphics hardware and the hardware trancoding does work with the qpkg here and makes quite a difference.

 

I haven't used it much other than some initial testing to see if it worked so I can't comment on the relative quality of the transcode.

 

If Emby server thinks your players can accept direct play or direct stream playback then trancoding isn't needed and 1080p generally works fine (not withstanding any network throughput limitations).

 

The bottom line is, if your NAS CPU power is not somewhere around that of the Windows machine you mentioned or supports hardware transcoding with it's on board graphics hardware (the QNAP quoted hardware transcoding generally does not relate to whether apps like Emby server can use on-board hardware trancoding) then your clients must be able to play your content without trancoding.

 

Ian

Edited November 27, 2017 by raven-au