Hardware encoding on AMD A10 within a Docker container on Emby 4.0.0.2

[agates 2]

I just got vaapi HW encode working in emby from docker -- I just had to manually specify a quality profile or it would keep saying "Info App: Profile: Unknown Profile, No direct play profiles found for Path".

Edited January 19, 2019 by agates

[Luke 37093]

I just got vaapi HW encode working in emby from docker -- I just had to manually specify a quality profile or it would keep saying "Info App: Profile: Unknown Profile, No direct play profiles found for Path".

 

that's actually not entirely related. can you explain exactly everything that you did? Thanks !

[agates 2]

that's actually not entirely related. can you explain exactly everything that you did? Thanks !

 

Aside from creating the docker image, manually selecting the quality profile is all I did.  And actually I can't reproduce the problem on the Android app, so it might be specific to the web player or my browser... need to do more testing.

 

Here are the logs from the console in firefox when I get the error with Quality set to Auto:

Requesting url without automatic networking: http://localhost:8096/emby/Users/bfc0dcd3ef454ed28d67bea1be87f820/Items/9389/Intros apiclient.js:1:12885
Requesting url without automatic networking: http://localhost:8096/emby/Users/bfc0dcd3ef454ed28d67bea1be87f820
apiclient.js:1:12885
validateFeature: playback registrationservices.js:1:4939
Requesting url without automatic networking: http://localhost:8096/emby/Items/9389/PlaybackInfo?UserId=bfc0dcd3ef454ed28d67bea1be87f820&StartTimeTicks=0&IsPlayback=true&AutoOpenLiveStream=true&AudioStreamIndex=1&SubtitleStreamIndex=-1&MediaSourceId=4f97bb5d964d3a4773839e21850c0516&MaxStreamingBitrate=1500001 apiclient.js:1:12885
playing url: http://localhost:8096/emby/videos/9389/master.m3u8?DeviceId=TW96aWxsYS81LjAgKFgxMTsgTGludXggeDg2XzY0OyBydjo2NC4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzY0LjB8MTU0NzY5MjE2MTEzOQ11&MediaSourceId=4f97bb5d964d3a4773839e21850c0516&VideoCodec=h264&AudioCodec=aac&VideoBitrate=1308001&AudioBitrate=192000&PlaySessionId=e97921afec7547b4a58aa67915995f18&api_key=b307524974634f9cbbb9b303bd0d9b65&AudioStreamIndex=1&SubtitleMethod=Encode&TranscodingMaxAudioChannels=2&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=True&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&TranscodeReasons=ContainerNotSupported plugin.js:1:6259
Content Security Policy: The report URI (about:blank) should be an HTTP or HTTPS URI.
Content Security Policy: The page’s settings observed the loading of a resource at blob:http://localhost:8096/3e37c7b8-b2a6-4012-af67-9efb9de4db6d (“worker-src”). A CSP report is being sent.
HLS Error: Type: otherError Details: internalException Fatal: true htmlmediahelper.js:1:4244
Cannot recover from hls error - destroy and trigger error htmlmediahelper.js:1:5162
Active player: {"name":"Html Video Player","id":"htmlvideoplayer","playerName":"Html Video Player","playableMediaTypes":[false,true,false,false,false],"isLocalPlayer":true,"supportedCommands":["GoHome","GoToSettings","VolumeUp","VolumeDown","Mute","Unmute","ToggleMute","SetVolume","SetAudioStreamIndex","SetSubtitleStreamIndex","SetMaxStreamingBitrate","DisplayContent","GoToSearch","DisplayMessage","SetRepeatMode","PlayMediaSource","PlayTrailers","ToggleFullscreen","SetBrightness"]} playbackmanager.js:1:15568
Requesting url without automatic networking: http://localhost:8096/emby/Sessions/Playing apiclient.js:1:12885
Requesting url without automatic networking: http://localhost:8096/emby/Items/9389/PlaybackInfo?UserId=bfc0dcd3ef454ed28d67bea1be87f820&StartTimeTicks=0&IsPlayback=false&AutoOpenLiveStream=false&MaxStreamingBitrate=1500001 apiclient.js:1:12885
Requesting url without automatic networking: http://localhost:8096/emby/Sessions/Playing/Progress apiclient.js:1:12885
Error: no bytes available 3e37c7b8-b2a6-4012-af67-9efb9de4db6d:1:53533
playbackmanager playback error type: mediadecodeerror playbackmanager.js:2:6365
Requesting url without automatic networking: http://localhost:8096/emby/Items/9389/PlaybackInfo?UserId=bfc0dcd3ef454ed28d67bea1be87f820&StartTimeTicks=0&IsPlayback=true&AutoOpenLiveStream=true&AudioStreamIndex=1&SubtitleStreamIndex=-1&EnableDirectPlay=false&EnableDirectStream=false&AllowVideoStreamCopy=false&MediaSourceId=4f97bb5d964d3a4773839e21850c0516&MaxStreamingBitrate=1500001 apiclient.js:1:12885
Requesting url without automatic networking: http://localhost:8096/emby/Users/bfc0dcd3ef454ed28d67bea1be87f820 apiclient.js:1:12885
Requesting url without automatic networking: http://localhost:8096/emby/Videos/ActiveEncodings?deviceId=TW96aWxsYS81LjAgKFgxMTsgTGludXggeDg2XzY0OyBydjo2NC4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzY0LjB8MTU0NzY5MjE2MTEzOQ11&PlaySessionId=e97921afec7547b4a58aa67915995f18 apiclient.js:1:12885
playing url: http://localhost:8096/emby/videos/9389/master.m3u8?DeviceId=TW96aWxsYS81LjAgKFgxMTsgTGludXggeDg2XzY0OyBydjo2NC4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzY0LjB8MTU0NzY5MjE2MTEzOQ11&MediaSourceId=4f97bb5d964d3a4773839e21850c0516&VideoCodec=h264&AudioCodec=aac&VideoBitrate=1308001&AudioBitrate=192000&PlaySessionId=961dcb5ee4be4721a0805b645b643be7&api_key=b307524974634f9cbbb9b303bd0d9b65&AudioStreamIndex=1&SubtitleMethod=Encode&TranscodingMaxAudioChannels=2&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=True&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&TranscodeReasons=ContainerNotSupported&allowVideoStreamCopy=false plugin.js:1:6259
Requesting url without automatic networking: http://localhost:8096/emby/Sessions/Playing/Progress apiclient.js:1:12885
Content Security Policy: The report URI (about:blank) should be an HTTP or HTTPS URI.
Content Security Policy: The page’s settings observed the loading of a resource at blob:http://localhost:8096/c8a95092-f830-421b-a490-ea55ec215522 (“worker-src”). A CSP report is being sent.
HLS Error: Type: otherError Details: internalException Fatal: true htmlmediahelper.js:1:4244
Cannot recover from hls error - destroy and trigger error htmlmediahelper.js:1:5162
playbackmanager playback error type: mediadecodeerror playbackmanager.js:2:6365
Requesting url without automatic networking: http://localhost:8096/emby/Videos/ActiveEncodings?deviceId=TW96aWxsYS81LjAgKFgxMTsgTGludXggeDg2XzY0OyBydjo2NC4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzY0LjB8MTU0NzY5MjE2MTEzOQ11&PlaySessionId=e97921afec7547b4a58aa67915995f18 apiclient.js:1:12885
Requesting url without automatic networking: http://localhost:8096/emby/Items/9389/PlaybackInfo?UserId=bfc0dcd3ef454ed28d67bea1be87f820&StartTimeTicks=0&IsPlayback=true&AutoOpenLiveStream=true&AudioStreamIndex=1&SubtitleStreamIndex=-1&EnableDirectPlay=false&EnableDirectStream=false&AllowVideoStreamCopy=false&AllowAudioStreamCopy=false&MediaSourceId=4f97bb5d964d3a4773839e21850c0516&MaxStreamingBitrate=1500001 apiclient.js:1:12885
Requesting url without automatic networking: http://localhost:8096/emby/Sessions/Playing/Progress apiclient.js:1:12885
Error: no bytes available c8a95092-f830-421b-a490-ea55ec215522:1:53533
Requesting url without automatic networking: http://localhost:8096/emby/Videos/ActiveEncodings?deviceId=TW96aWxsYS81LjAgKFgxMTsgTGludXggeDg2XzY0OyBydjo2NC4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzY0LjB8MTU0NzY5MjE2MTEzOQ11&PlaySessionId=e97921afec7547b4a58aa67915995f18 apiclient.js:1:12885
playing url: http://localhost:8096/emby/videos/9389/master.m3u8?DeviceId=TW96aWxsYS81LjAgKFgxMTsgTGludXggeDg2XzY0OyBydjo2NC4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzY0LjB8MTU0NzY5MjE2MTEzOQ11&MediaSourceId=4f97bb5d964d3a4773839e21850c0516&VideoCodec=h264&AudioCodec=aac&VideoBitrate=1308001&AudioBitrate=192000&PlaySessionId=455c5c104f2d4835ad28ae2c30e7cd15&api_key=b307524974634f9cbbb9b303bd0d9b65&AudioStreamIndex=1&SubtitleMethod=Encode&TranscodingMaxAudioChannels=2&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=True&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&TranscodeReasons=ContainerNotSupported&allowVideoStreamCopy=false&allowAudioStreamCopy=false plugin.js:1:6259
Requesting url without automatic networking: http://localhost:8096/emby/Sessions/Playing/Progress apiclient.js:1:12885
Content Security Policy: The report URI (about:blank) should be an HTTP or HTTPS URI.
Content Security Policy: The page’s settings observed the loading of a resource at blob:http://localhost:8096/6a77a642-48aa-41d1-8324-dada0d76dd94 (“worker-src”). A CSP report is being sent.
HLS Error: Type: otherError Details: internalException Fatal: true htmlmediahelper.js:1:4244
Cannot recover from hls error - destroy and trigger error htmlmediahelper.js:1:5162
playbackmanager playback error type: mediadecodeerror playbackmanager.js:2:6365
Requesting url without automatic networking: http://localhost:8096/emby/Sessions/Playing/Stopped apiclient.js:1:12885
Requesting url without automatic networking: http://localhost:8096/emby/Videos/ActiveEncodings?deviceId=TW96aWxsYS81LjAgKFgxMTsgTGludXggeDg2XzY0OyBydjo2NC4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzY0LjB8MTU0NzY5MjE2MTEzOQ11&PlaySessionId=e97921afec7547b4a58aa67915995f18 apiclient.js:1:12885
Requesting url without automatic networking: http://localhost:8096/emby/Items/9389/PlaybackInfo?UserId=bfc0dcd3ef454ed28d67bea1be87f820&StartTimeTicks=0&IsPlayback=false&AutoOpenLiveStream=false&MaxStreamingBitrate=1500001 apiclient.js:1:12885
Error: no bytes available 6a77a642-48aa-41d1-8324-dada0d76dd94:1:53533
Requesting url without automatic networking: http://localhost:8096/emby/Users/bfc0dcd3ef454ed28d67bea1be87f820 apiclient.js:1:12885 

[Luke 37093]

Thanks for the info.

[Loki93 2]

Hi,

 

are there any news about AMD hardware transcoding in docker?

 

I tried @@agates docker-image, but with no succes. No errors regarding hardware-detection or transcoding itself, just one warning I found in a transcode-log:

[h264_vaapi @ 0x2297040] Warning: some packed headers are not supported (want 0xd, got 0).

Excerpt from hwdetection:

"Devices": [
        {
            "DeviceIndex": 0,
            "DeviceInfo": {
                "VendorName": "Advanced Micro Devices, Inc. [AMD/ATI]",
                "DeviceName": "Wani [Radeon R5/R6/R7 Graphics]",
                "SubsytemVendorName": "Advanced Micro Devices, Inc. [AMD/ATI]",
                "SubsytemDeviceName": "Radeon R5 Graphics",
                "VendorId": 4098,
                "DeviceId": 39028,
                "SubsytemVendorId": 4098,
                "SubsytemDeviceId": 6257,
                "DevPath": "/sys/bus/pci/devices/0000:00:01.0",
                "DrmCard": "/dev/dri/card0",
                "DrmRender": "/dev/dri/renderD128",
                "IsEnabled": 1,
                "IsBootVga": 1,
                "ApiVersionMajor": 1,
                "ApiVersionMinor": 4,
                "Driver": "Mesa Gallium driver 18.2.8 for AMD Radeon R5 Graphics (CARRIZO, DRM 3.26.0, 4.18.0-20-generic, LLVM 7.0.0)"
            },
            "Decoders": [

So everything seems ok to me, but for some h264 media (code via handbrake without hw-acceleration on a windows 10 machine) emby refuses playback saying there is no compatible stream.

[Luke 37093]

Hi,

 

are there any news about AMD hardware transcoding in docker?

 

I tried @@agates docker-image, but with no succes. No errors regarding hardware-detection or transcoding itself, just one warning I found in a transcode-log:

[h264_vaapi @ 0x2297040] Warning: some packed headers are not supported (want 0xd, got 0).

Excerpt from hwdetection:

"Devices": [
        {
            "DeviceIndex": 0,
            "DeviceInfo": {
                "VendorName": "Advanced Micro Devices, Inc. [AMD/ATI]",
                "DeviceName": "Wani [Radeon R5/R6/R7 Graphics]",
                "SubsytemVendorName": "Advanced Micro Devices, Inc. [AMD/ATI]",
                "SubsytemDeviceName": "Radeon R5 Graphics",
                "VendorId": 4098,
                "DeviceId": 39028,
                "SubsytemVendorId": 4098,
                "SubsytemDeviceId": 6257,
                "DevPath": "/sys/bus/pci/devices/0000:00:01.0",
                "DrmCard": "/dev/dri/card0",
                "DrmRender": "/dev/dri/renderD128",
                "IsEnabled": 1,
                "IsBootVga": 1,
                "ApiVersionMajor": 1,
                "ApiVersionMinor": 4,
                "Driver": "Mesa Gallium driver 18.2.8 for AMD Radeon R5 Graphics (CARRIZO, DRM 3.26.0, 4.18.0-20-generic, LLVM 7.0.0)"
            },
            "Decoders": [

So everything seems ok to me, but for some h264 media (code via handbrake without hw-acceleration on a windows 10 machine) emby refuses playback saying there is no compatible stream.

 

Hi, it's not officially supported in Docker yet, but if you provide the hardware detect and ffmpeg logs we can let you know if we see anything obvious. thanks.

[agates 2]

Hi,

 

are there any news about AMD hardware transcoding in docker?

 

I tried @@agates docker-image, but with no succes. No errors regarding hardware-detection or transcoding itself, just one warning I found in a transcode-log:

[h264_vaapi @ 0x2297040] Warning: some packed headers are not supported (want 0xd, got 0).

Excerpt from hwdetection:

"Devices": [
        {
            "DeviceIndex": 0,
            "DeviceInfo": {
                "VendorName": "Advanced Micro Devices, Inc. [AMD/ATI]",
                "DeviceName": "Wani [Radeon R5/R6/R7 Graphics]",
                "SubsytemVendorName": "Advanced Micro Devices, Inc. [AMD/ATI]",
                "SubsytemDeviceName": "Radeon R5 Graphics",
                "VendorId": 4098,
                "DeviceId": 39028,
                "SubsytemVendorId": 4098,
                "SubsytemDeviceId": 6257,
                "DevPath": "/sys/bus/pci/devices/0000:00:01.0",
                "DrmCard": "/dev/dri/card0",
                "DrmRender": "/dev/dri/renderD128",
                "IsEnabled": 1,
                "IsBootVga": 1,
                "ApiVersionMajor": 1,
                "ApiVersionMinor": 4,
                "Driver": "Mesa Gallium driver 18.2.8 for AMD Radeon R5 Graphics (CARRIZO, DRM 3.26.0, 4.18.0-20-generic, LLVM 7.0.0)"
            },
            "Decoders": [

So everything seems ok to me, but for some h264 media (code via handbrake without hw-acceleration on a windows 10 machine) emby refuses playback saying there is no compatible stream.

To be clear, HW encode doesn't work for me, only decode.

 

With HW encode, I also get the "no compatible stream" error -- from the web client, at least.

[softworkz 3338]

@@bkloppenborg - I can only repeat that I generally don't recommend running a hardware-bound application using a framework aiming for hardware abstraction and independence (like containers).

 

I think it has already been mentioned that we're not officially supporting hw acceleration inside Docker containers. 

Though, many users were able to get this working with Nvidia and Intel hardware, but AMD is the most problematic variant, even running natively (no container).

 

The following advise might still be helpful:

1. In case of AMD, you won't get it running flawlessly without AMD proprietary drivers
   Don't even bother to try
   .
2. Searching for Linux drivers on the AMD website is totally messed up 
   The best strategy for finding a recent driver for your hardware:
   • Don't search by specifying your hw model
   • Instead search generically for "Linux drivers" or similar
   • Then go through search results starting with the latest driver version and proceed in descending version order
   • For each version look at the release notes and see if your hw is supported
   • I don't understand their system, but even adjacent versions (a.b.12 and a.b.13) can support a totally different range of hardware
     So you need to carefully look at each release

Edited May 22, 2019 by softworkz

[agates 2]

 

@@bkloppenborg - I can only repeat that I generally don't recommend running a hardware-bound application using a framework aiming for hardware abstraction and independence (like containers).

 

I think it has already been mentioned that we're not officially supporting hw acceleration inside Docker containers.

 

I understand you appear to have an ideological disagreement with this entire hobby.  As a professional software developer and devops practitioner, I philosophically disagree with your point on the purpose of containers.

 

However does your disagreement with this mean we should not tinker whatsoever?  This used to be an open source project, and therefore attracted tinkerers.  Regardless, allow me to state some facts.

 

1. I don't expect this to be officially supported

2. I am using AMD Radeon hardware (RX 580) with 100% open source drivers

3. I have VAAPI HW decode working with Emby within my own docker image/container

4. VAAPI HW encode successfully generates the video files.  I have checked the output on disk and played them within an external video player.

 

No, the support isn't 100% for all video cards but the new drivers are much better than they used to be.  Again, I do not expect official support.

 

But I do believe there may be a bug (internal or external to emby) and I do not have the means nor the technical expertise around video encoding technology to debug the software myself.

 

I ask that you please avoid hostility toward mere tinkering.  Unless the project does not support this, then it should be stated as such.

[Luke 37093]

Hi, yes we're happy to help you tinker with this. If you can post the log files when you have a problem then we'll see if we can spot anything. Thanks !

[softworkz 3338]

I understand you appear to have an ideological disagreement with this entire hobby.  As a professional software developer and devops practitioner, I philosophically disagree with your point on the purpose of containers.

 

However does your disagreement with this mean we should not tinker whatsoever?  This used to be an open source project, and therefore attracted tinkerers.  Regardless, allow me to state some facts.

 

No, the support isn't 100% for all video cards but the new drivers are much better than they used to be.  Again, I do not expect official support.

 

But I do believe there may be a bug (internal or external to emby) and I do not have the means nor the technical expertise around video encoding technology to debug the software myself.

 

I ask that you please avoid hostility toward mere tinkering.  Unless the project does not support this, then it should be stated as such.

 

I apologize for the misunderstanding and I never meant to appear hostile in any way. 

Let me try to clarify:

1. What I said about running hardware bound applications inside containers is my personal point of view

   You got any right to disagree - competing opinions are driving the world's progress ;-)

   .

2. From the support point of view, we're supporting 8 different hardware accelerations on 5 different platforms. 

   Thinking about adding support for virtualization that would add 3 additional factors:

   • Virtualization Framework
   • Virtualization Guest OS
   • Virtualization Host OS

     => Now you can do the math. (multiply, not add)

     => I hope you can understand that it is simply impossible for a small team to support all this

      

3. But all that doesn't mean that we won't try our best to help as far as possible

   The larger part of my post was about providing potentially helpful information  - in case you didn't notice

 

Beyond all this - taking the risk you'd consider me being hostile again - when I summarize your post:

• I gave you an advice
• You rejected the advice, stating
  • the latest open source drivers are quite good
  • everything is working at your side
• Then you say that things are not working right

  => This must be a bug in Emby

(.........)

 

Please reconsider my advice. That wasn't some copy/paste boilerplate reply.

[agates 2]

Beyond all this - taking the risk you'd consider me being hostile again - when I summarize your post:

• I gave you an advice
• You rejected the advice, stating
  • the latest open source drivers are quite good
  • everything is working at your side
• Then you say that things are not working right

  => This must be a bug in Emby

 

Please do not misrepresent what I said.  My exact words: "I do believe there may be a bug (internal or external to emby)".

 

You are either intentionally misrepresenting this point of view or incapable of basic reading comprehension.  And I don't know how many times I need to state that I'm not expecting official support.

 

Regardless, I am attempting to further open source software rather than point fingers.  This matters more to me than the end result.  The modern amdgpu-pro drivers largely use the same code base as the all-open stack components anyway -- but I will make it a point to ask and work with AMD developers directly.

 

What logs are most important for collection?

[Luke 37093]

@@agates, at this point we've implemented support based on the AMD proprietary drivers. It's possible for us to look at supporting the open source drivers but that would be a separate effort from what we've done so far. Apologies for any confusion.

 

However, to answer your question, if you can attach the hardware detection log then we might be able to learn something from that. Thanks.

[Loki93 2]

Sorry for the late reply. Here are my logs from the hw-accelerated image the agates build. Please tell me if some necessary are missing.

HWDetection.log

ffmpeg.log

[Loki93 2]

And these are the logs from the standard emby image.

 

Maybe these information may also help:

In docker, rights are:

511 on /usr/share/misc/pci.ids

500 on /bin/pci.ids

511 on /usr/share/libdrm/amdgpu.ids

 

Serverside they are:

511 on /usr /share/pci.ids

751 on /share/libdrm/amdgpu.ids

511 on /usr/share/libdrm/amdgpu.ids

 

With the standard image, I can't choose any de- or encode when switching to advanced transcoding option. The lists with available devices stay empty.

 

The hw-accelerated image works as agates said: video-decode works, encode not.

 

ffmpeg.log

hwdetection.log

[Luke 37093]

Ok, thanks for supplying those. As i don't see anything obvious here I think this will just have to wait until we're able to look at supporting the open source drivers.

[Loki93 2]

If any testing is needed, native or (prefered) in docker, on HPE Microsever Gen10 plattform running ubuntu server I'd like to help.

[softworkz 3338]

@@Loki93

 

If you want a solution that is working right now:

 

- Install Emby Server on the host OS

- Install the AMD proprietary drivers

 

and you should be ready to run with hw acceleration.

[agates 2]

I have an (apparently) working docker image with working hwaccel encoding.  The output has the wrong ratio, however, on my machine.

 

registry.gitlab.com/agates/emby-hwaccel-docker/ubuntu-19-04:latest

 

This image is based on ubuntu 19.04 instead of 18.10 so should use newer drivers -- took me this long to try it because the dockerfile needed some changes to how s6-overlay is added (not sure why yet).

[Luke 37093]

@@agates, why do you say apparently?

[agates 2]

@@agates, why do you say apparently?

I haven't spent much time on it and have not tried to verify that it's working as intended, beyond enabling hwaccel encode and decode and seeing it work in the dashboard.

[Luke 37093]

Thanks for the info.

[Loki93 2]

I just tried it with a file that required transcoding due to incompatible sub (PGS). With the previuous images from @@agates and the offical beta-images, only hw-decoding worked. Now it indeed seems to work with de- and encoding with hw-accelaration.

 

As mentioned before, with the previous tested builds only hw-accelerated decoding worked. With enabled hw-accelerated encoding, the server was not able to deliver a stream. With hw-accelerated encoding deactivated, CPU-usage went straight up to 100%. Now, with the Ubuntu 19.04 based image, CPU usage rises to only about 50% when hw-accelerated encoding is enabled and besides, encoding is fast enough (~30fps) on my machine so viewing the film without stuttering is possible. Even quality is much better than with software encoding (though only 23fps were achieved).

 

Tell me if you want some logs ;-)

Edited June 9, 2019 by Loki93

[agates 2]

I just tried it with a file that required transcoding due to incompatible sub (PGS). With the previuous images from @@agates and the offical beta-images, only hw-decoding worked. Now it indeed seems to work with de- and encoding with hw-accelaration.

Did you notice any oddities with the output aspect ratio like I did? Or anything else, for that matter.

[Loki93 2]

No, nothing dramitcally right now. The tested file is coded with 1920x1080 (16:9) and the output as seen in "Stats for nerds" is 1920x1088.

 

I also did a quick test with a 4:3 file. Input was 720x576 and output was 720x576 as seen in "stats for nerds".

 

It seems fine to me:-)

Edited June 9, 2019 by Loki93