Decoding of 1080x1920 videos seems broken

[carlonluca]

Trying to play this sample using OpenMAX results in a broken output where more than half the frame is corrupted. I suppose the reason is it is a 1080x1920 video (this is simply a rotated big buck bunny). I tested with omxplayer and the same seems to happen. I bisected rpi firmwares using rpi-update and it seems to me Hexxeh/rpi-firmware@2b42a48 is the offending commit. Before that commit omxplayer was working properly here, and so was my code using egl_render. Can someone confirm? Any way to fix this in HEAD? Thanks.

[popcornmix]

Technically 1080x1920 is not supported and I was surprised it was working at all.
But your sample did work in the past.

The deinterlace change in that firmware commit increases the height of images allocated by a couple of lines and that seems to be causing the issue. I need to have a closer look to see if it is really needed in this case (height's already get aligned up for sdram pagesize alignment reasons which may be sufficient already).

[deborah-c]

The decoder does officially support this resolution -- it was tested and deployed commercially when iPhone 4 started generating portrait video this way. (Pretty much everyone else uses 1080p with metadata to indicate rotation.)

However, the hardware can't handle the stride required to have such a tall stripe, so the default allocator was modified to provide images in which we have whole stripes of Y pixels, then after all the Y stripes, a set of UV-only stripes (of which the bottom half is unused and wasted). The Y to UV offset is set to jump across all the Y pixels. I suspect this (compliant but) unusual image format may be the source of the problem.

[nenadlazovic]

Hi all,
thanks a lot for support on RPI2 GPU.

We are using RPI2 and so far were using Nov 1, 2015 commit (Hexxeh/rpi-firmware@d0ab2f4)

We do have 2 mandatory requirements to

• support 1080x1920 (very common in digital signature apps - portrait mode)
• support multiple (at least 2) videos at the same time (in lower then 1080x1920 resolutions)

From what I understand, build Nov 6, 2015 commit 2b42a4 (Hexxeh/rpi-firmware@2b42a48) is breaking 1080x1920 support, yet fixing threadlock "firmware: vcilcs: Avoid a potential deadlock when very threaded"

This puts us in hard place having to chose between 2 mandatory requirements as we can not support both. If we go for newer then Nov 1 2015, we loose 1080x1920. If we go with older the Nov 1, we loose thread locking bug fix and future improvements :) :)

2 questions

1. Is there a chance for enabling 1080x1920 support in latest version so that we can have benefits of threadlock bug fix ?
2. is there a max portrait mode resolution that will still work with latest version ?

Thanks a lot.

Nenad

[popcornmix]

Can you try with this test firmware: https://dl.dropboxusercontent.com/u/3669512/temp/firmware_portrait.zip

[nenadlazovic]

thanks a lot for prompt response.
will try immediately. can you give instructions how to apply this test firmware ?

[popcornmix]

Easiest is to open the zip file in windows and extract the contents to the sdcard.
You should see a similar set of files when the Pi's sdcard is inserted into windows machine.

[nenadlazovic]

ok. will get back to you shortly.

[nenadlazovic]

I have tested https://dl.dropboxusercontent.com/u/3669512/temp/firmware_portrait.zip.
1080x1920 is working fine. It shows videos correctly. Tested on 5 videos that were working in Hexxeh/rpi-firmware@d0ab2f4.

To make sure problem is fixed I

• sudo rpi-update d0ab2f4 (nov 1 2015 build)
  • no problem showing 1080x1920 videos (as expected this is last versiono when there was no problem showing 1080x1920)
• sudo rpi-update 2b42a4 (nov 6 2015 build)
  • problem showing 1080x1920 videos (see https://www.dropbox.com/s/ujusp4lbms0dazo/20160307_183343.jpg?dl=0)
• https://dl.dropboxusercontent.com/u/3669512/temp/firmware_portrait.zip
  • no problem showing 1080x1920 videos

GREAT. Thanks.

Can you advise if / when you can commit this version to mainline ?

Thanks in advance.

NOTE: as side test, I tested multi-videos and getting issue that might look like #449. I will comment on #449.

Nenad

[popcornmix]

It will appear in next firmware update. Typically there are one or two a week, so it shouldn't be long.

[nenadlazovic]

Thank you a lot. It is really great and fast response you demonstrated here.
If there is a way to donate, pls let me know.
Nenad

[popcornmix]

This has now been pushed to rpi-udpate.
@carlonluca can you test?

[carlonluca]

Seems perfect. Great work! Thanks!

[nenadlazovic]

i also tested Hexxeh/rpi-firmware@2a7eb4f it and it works correctly. Great. Thanks.

[cris-b]

this seems to be happening again as of

pi@raspberrypi:~ $ sudo /opt/vc/bin/vcgencmd version
Oct 22 2020 14:06:02
Copyright (c) 2012 Broadcom
version 74e754ff8947c58d2773253f77f6f68a303188f8 (clean) (release) (start)