https://bugs.freedesktop.org/show_bug.cgi?id=91281
Andy Furniss changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=91281
--- Comment #6 from Andy Furniss ---
Maybe if enc->base.level is unreliable I shouldn't trust
enc->base.max_references either, but it seems that the h/w gets set up using it
-
radeon_vce_40_2_2.c
RVCE_CS(MAX2(enc->base.max_references, 1) - 1);
https://bugs.freedesktop.org/show_bug.cgi?id=91281
--- Comment #5 from Andy Furniss ---
I can do a patch, but I'll need time to think/look/test more.
First thought = easy just add 52 and maybe make default vary with chip type as
done elsewhere, will fix gst-vaapi, but not going to help OMX.
https://bugs.freedesktop.org/show_bug.cgi?id=91281
--- Comment #4 from Christian König ---
Nice catch. Brave enough to provide a patch or should Leo and I take a look?
I'm just back from vacation and so busy that I probably won't come to it before
the end of the month.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=91281
--- Comment #3 from Andy Furniss ---
I know what causes this now.
It's the get_cpb_num case statement in radeon_vce.c.
It only handles up to 51 and defaults to 42.
ffmpeg lucked into working because it calls 51 when it should really be 52.
https://bugs.freedesktop.org/show_bug.cgi?id=91281
--- Comment #2 from Andy Furniss ---
More debugging and size 24883200 works fine in the working case, it's
mapping->it.last
that varies between working and failing.
size mapping->it.last
0x0108fde000 14 13 24883200
https://bugs.freedesktop.org/show_bug.cgi?id=91281
--- Comment #1 from Andy Furniss ---
Now that vaapi is enabled the situation with this is more mixed.
omx still just always fails.
ffmpeg vaapi always works.
gatreamer vaapi fails or works depending on framerate, which is a bit
confusing.
https://bugs.freedesktop.org/show_bug.cgi?id=91281
Bug ID: 91281
Summary: Tonga VCE 2160p encode fails with BO to small for
addr
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status:
