Missing Codec Type, Profile not enabled

Matt Writer

Hello !

I have TVH 4.3 (fresh pull from the master branch, although i am currently trying the upstream/dev_vainfo2 branch to see if that helps) installed in a privileged LXC container, using a base 24.04 Ubuntu template. this is running on Proxmox 8.2.4 on an Intel i7-3770, and I have the Quicksync devices passed through (they show up fine in the container, vainfo gives the expected output).

Somehow Tvheadend is letting me create h264_vaapi profiles, but won't enable them. Everything seems to be in order except it's not showing the right type of codec, as can be seen in the screenshot. As a result, the profile is disabled, and cannot be enabled.

Does anyone have any idea about this?

ukn_unknown

Hi, In order to separate the issue between container and transcoding, can you compile the project on the physical machine (outside of container) and temporary install it to confirm you experience the same problem?

Matt Writer

ukn_unknown

afraid not. it's a production proxmox environment, with quite a bunch of critical applications running on it. "testing" software on it is not exactly good practice 🙂

what i can offer as insight though, is that i already had tvheadend with working hw-transcoding working on this very same system, but it was an actual virtual machine. since i swapped over to running TVH in a container, I've encountered this error. so when it was installed as a VM, passing through the intel quicksync devices worked and transcoding happened via vaapi, making me think that the underlying software situation on the proxmox host is working fine.

ukn_unknown

In this case I think the container is not exposing properly the drivers or tvh is not able to understand how driver is exposed. Installing upstream/dev_vainfo2 will help understand if vaapi is exposing the codecs. Can you run "vainfo -a" in the container (I don't have experience with containers ... if this is foolish let me know), and upload the file. This will help us understand if container is exposing properly the driver properties. Next step should be for you to confirm if you can transcode with ffmpeg spawn command (to confirm ffmpeg is working on that container).

Matt Writer

ukn_unknown or tvh is not able to understand how driver is exposed

i guess this seems to be the case, as ffmpeg has no issues.
using an MPEG-TS Spawn profile, ffmpeg is able to transcode using hwaccel_vaapi. (h264_vaapi to be precise).

output of 'vainfo -a' is attached.

vainfo-output.txt

8kB

ukn_unknown

Everything looks good on the vainfo. H264 Main profile should be valid. Can you enable the vainfo detection?

The issue seems to be on the bottom function. ~~But interesting is that top function works ... How is possible that 'codec' is valid on top and not valid on the bottom?~~

Actually I take that back ... I don't think the top one works properly. Take a look how 'Codec' is on my machine. It has some extra information that is taken from some ffmpeg code. BTW: codec_profile_class_name_get() is populating the Codec field (not Codec Name).

Can this be a rise condition? like we are requesting type 'too soon'? I don't know how to debug this problem 🙁 .

Matt Writer

ukn_unknown Can you enable the vainfo detection?

i had already built with the upstream/dev_vainfo2 branch as stated in my first post, so vainfo detection was already enabled by me (done it immediately after building it).
but an interesting development happened today ... noticing on github that the changes in that branch had been merged to the master branch, i've built the master branch again, and lo and behold, it now seems to recognize the codec, and the profile is indeed enabled.

edit: i did "fiddle" with driver packages (removing intel-media-va-driver and instead building and installing intel-vaapi-driver, since i had come across a blog post explaining that with the newest intel-media-va-driver package, intel had messed up support for i915 chipsets), so in that sense there is a difference in the driver state of my container between the build of dev/upstream_vainfo2 and the build of master today. so if any "conclusion" can be drawn from this, then that the driver situation for vaapi needs to be already all in order before building, or else it may still be a problem even if the drivers are resolved post-build.

ukn_unknown

@chewitt We should copy into documentation the information above (with <unknown>) to help future users when will experience the same issue.

chewitt

https://app.gitbook.com/invite/GUiJM9P5N3CkY42Hcs8P/7hmZSVRZkZqEIJarLFX5

^ Anyone can use GitBooks to edit and submit changes. It'll create a pull-request on GitHub (the upstream source) which can be merged. Have at it..