[amk9]

Hi forum,

I am trying to setup a new media box based on RPi4, ArchLinux, tvheadend, Sundtek USB tuner and Kodi. To be more specific:
Rpi4B 2GB Ram, 32bit Linux 5.15.26-2-rpi-ARCH #1 SMP armv7l GNU/Linux 19.4 (19.4.0) Git:20220303-nogitfound from Arch repository running as Kodi standalone (GBM)

A problem happens when trying to play some video files, there is no error message, just video does not appear. It is related to hardware decoding, similar to what is described in the other thread https://forum.kodi.tv/showthread.php?tid...ight=prime

My videos are not 4k, yet they fail to play, only audio is heard. Comparing debug output from working ones I do not see any error or a difference comparing to a working playback.

After some analysis and tests I was able to confirm that the failing files have HD resolution and are encoded with colorspace yuv420p(tv, bt709), complete info:
 

Code:

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 1664 kb/s, 24 fps, 24 tbr, 12288 tbn, 48 tbc (default)

Stream #0:0(und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 444 kb/s, 30 fps, 30 tbr, 15360 tbn, 30 tbc (default)

Files with lower resolution and H264 codec start playing, but at some random time they stop, and kodi outputs lot of errors to log file, eventually crashes:
 

Code:

                                                     Property: FB_ID    ID: 17    Value: 255
2022-03-07 01:02:37.252 T:2253    ERROR <general>: CDRMAtomic::DrmAtomicCommit - atomic commit failed: Bad file descriptor
2022-03-07 01:02:37.260 T:2253    ERROR <general>: CDRMAtomic::DrmAtomicCommit - test commit failed: (Bad file descriptor) - falling back to last successful atomic request
2022-03-07 01:02:37.260 T:2253    ERROR <general>: 
                                                   Object: plane    ID: 99
                                                     Property: FB_ID    ID: 17    Value: 254
2022-03-07 01:02:37.261 T:2253    ERROR <general>: CDRMAtomic::DrmAtomicCommit - atomic commit failed: Bad file descriptor
2022-03-07 01:02:37.404 T:2380  WARNING <general>: OutputPicture - timeout waiting for buffer
2022-03-07 01:02:47.421 T:2380  WARNING <general>: Skipped 126 duplicate messages..
2022-03-07 01:02:47.421 T:2380  WARNING <general>: OutputPicture - timeout waiting for buffer
2022-03-07 01:02:57.462 T:2380  WARNING <general>: Skipped 195 duplicate messages..
2022-03-07 01:02:57.462 T:2380  WARNING <general>: OutputPicture - timeout waiting for buffer

Based on the other thread I understand that the hardware is likely not capable of decoding the file, but I have some points I'd like to understand:

• Is it possible to match HW capability with video properties before attempting to use and report to the user that file cannot play?
  
• If the file is broken and HW decoding fails during playback, is there any watchdog to recover from the situation?
  
• Would it make sense to fallback to software decoding? Disabling PRIME works well for this contents, but if I keep it like that, the device is too slow to decode HD DVB stream.
  

Many thanks for any hint or enhancement that could be made.

amk

[popcornmix]

The other thread was specifically 4k h.264 video (which is an unusualy combination).
Pi4 will play 1080p h.264 and 4k hevc video (which your files appear to be).

Can you try with a LibreELEC 10 build? If that works it shows the files are fine and there's an issue with the Arch build.
If that fails, a sample file (e.g. cut a 1 minute chunk) that shows the issue would be useful.

[amk9]

I performed several test, including both 2GB and 8GB version of RPi4 with both Arch and LE10.
All combinations do not play hevc 4K, h264 4k, some h264 1080 work, some dont. I found also some that don't and do not have the bt709 colorspace. Here the complete files, neither plays with LE10, they are not long:

March of the Cobblers 106.9MB Duration: 00:02:51.97
Video: hevc (Rext) (hev1 / 0x31766568), yuv422p(tv, progressive), 2560x1440 [SAR 1:1 DAR 16:9], 5083 kb/s, 30 fps, 30 tbr, 15360 tbn, 30 tbc (default)
https://mega.nz/file/Ed4FTAIC#nbS3T7lz1Q...mHg-j6_tp0

Soon_the_dawn_will_come.mp4 160MB Duration: 00:03:15.56
Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 2560x1440 [SAR 1:1 DAR 16:9], 6608 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)
https://mega.nz/file/JEYWiLqC#0Xs4qGdFUm...yogOgGlcxc

Springband_reclame.mp4 102.4MB Duration: 00:01:16.33
Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1090 [SAR 1:1 DAR 192:109], 11063 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
https://mega.nz/file/QNJkCRaT#bpOppOc6-f...49_5xSB9rU

Amazing_Grace.mp4 59.2MB Duration: 00:01:47.06
Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 4516 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
https://mega.nz/file/4BRTnAzI#sNoX4pws3A...z8dKBflhgY

My TV has resolution 1360x768 if that matters, but when tried 1920x1080 there was no difference.

My main concerns are following:

• Kodi should not silently fail to show video, but report to the user that there is a problem playing the file.
  
• The user should be given a possibility to fallback to sw decoding, for the current file only. H264/4K fail HW decode but work via SW. hevc/4k fail both ways while hevc/720 fail in SW and work with HW.
  
• There is possibly not complete reset of the GPU when initializing playback. Once the playback fails, subsequent otherwise working files also tend to break until reboot.
  

[popcornmix]

yuv422p is not supported by hardware decoder (and is a very niche encoder setting).
Springboard and Amazing Grace are profile 5.0. We only officially support 4.1 (BluRay spec).
You can play these with increased gpu_mem (e.g. gpu_mem=128 in config.txt).

Soon_the_dawn_will_come is above 1920x1080 which is the limit for h.264 video on our hardware decoder.
That resolution would work with hevc.

I'll look into whether we can handle the failure to play any better.

[amk9]

Thanks for the comments and clarifications. I was thinking somehow that Kodi would also handle many formats, like vlc or mplayer, but it makes sense to limit the supported codecs/setting. I can recode the problematic files to play, also to match the resolution with the TV and save on file size.

I think it would be nice if the system could warn upfront when a file is not within supported specifications. But also when reading of the video device it is not very helpful to keep logging multiple messages like "OutputPicture - timeout waiting for buffer". I would suggest to stop playing the file, print out a message and offer to try sw/hw decoder, to play audio only or to skip the file and to move on with the playlist.

[popcornmix]

There is possibly not complete reset of the GPU when initializing playback. Once the playback fails, subsequent otherwise working files also tend to break until reboot.

That is a bug that should be fixed. I'll look into finding a solution.

But in general, kodi doesn't have the ability to offer switching to sw decoder if hw decode is not going well.
That would need a post in feature requests channel, but I suspect if hw cannot play it (probably due to too high a profile, or resolution) then sw is unlikely to be happy.

If we can detect a stream can't be played before decode starts (e.g. purely from headers), it may be possible to never start decoding with hw and choose sw initially.
But as kodi is very against platform specific code, that would depend on whether we can get this information though official APIs (i.e. through ffmpeg into V4L2).