Bottom video lines are duplicates in case of vertical resolution not dividable by 8


When playing h264 or h265 content on a S905x I sometimes see that the last few lines at the bottom are duplicates. I already see this many releases and also on 9.0.1. Playback is on a LG C8 using HDMI.

After a while I noticed this only happens when the vertical resolution is not a multiple of 8 (or maybe 16).

For example I have a h265 encode with vertically 804 lines. This is not a multiple of 8.

I guess somewhere the hardware/software allocates the buffers in multiples of 8 or 16 lines because of how mpeg decoding works which result in a buffer of 808 lines for my example. Instead making the bottom lines black or not displaying them they are copies of the last line 804.

Is this a known issue? I tried googling for it a lot, but did not find anything.

As a remark I also have the feeling the playback slightly stutters in case the vertical resolution is off.

1 Like

Yes, I just double checked, and I can see the problem. You are correct, that video height must be a multiple of 8 (I believe). As far as I know this is a limitation of the hardware decoder, we can’t really do anything about it.
I haven’t noticed any stuttering issues, though.

1 Like

Thanks for double checking.

I’m pretty sure the h264/h265 specifications allow for these vertical dimensions. I believe amlogic follows these specifications as they are smart people. Usually, these kinds of artefacts are bugs in the software as it is very common to optimize decoding for the common resolutions and it is easy to overlook this in one of the many steps in the decoding process.

Isn’t the amlogic software that controls the hardware decoding open source? where does CoreElec get this from? OSMC, vero 4k? I guess this is in the Linux-amlogic branch?

The software I wrote to compress my stuff crops everything down to a modulus 16. I would rather use a few lines than have annoying artefacts.

True, sadly I do not compress all my videos myself to h265 and since the standard does not forbid it I cant really blame the other encoders.

Browsing through the amlogic source, i would guess the actual buffers are allocated around Linux-amlogic/drivers/amlogic/amports/vh265.c. I am not very familiar with the code so its difficult to find out where actually it could actually be located

Two more questions:

  1. Is this the right place for this problem or should it be in the hardware section?
  2. Are there actually developers at coreelec that work on the actual decoding part? If not, where is this part developed? Perhaps, I can get some pointers there of where to start looking