On Fri, Nov 6, 2015 at 2:15 PM, Christian König <deathsim...@vodafone.de> wrote: > On 06.11.2015 20:10, Ilia Mirkin wrote: >> >> On Fri, Nov 6, 2015 at 1:48 PM, Zhang, Boyuan <boyuan.zh...@amd.com> >> wrote: >>> >>> Hi Emil, >>> >>> Please see the following information about this patch. >>> >>> - Issue: For Mpeg4, the VOP and GOV headers were truncated. With the >>> existing workaround in st/va, playback shows massive corruptions. >>> - This Patch: Provide another way to get the truncated headers back. >>> Massive corruptions are gone with this patch. At the same time, add an >>> environmental variable to allow user to decide whether to use this patch. >> >> Why would the user not want to use this? Sounds like a correctness >> fix, no? Or is it some thing that a hypothetical gallium driver might >> not need but the radeon uvd-based ones do? In that case it should be >> behind a PIPE_VIDEO_CAP_bla (sorry, I'm still not too clear on what >> "bla" is here...) > > > The problem is that this is a rather extreme hack. > > As you probably knew VA-API didn't correctly specify which start code should > be included and which shouldn't for MPEG-4. This is an issue for AMD as well > as NVidia hardware and pretty much everybody which sticks close to an > elementary stream. > > What we do in this hack is just searching the bytes *before* the pointer and > size we got from the application for the stuff that's missing. E.g. we > access memory the application didn't told us to access. > > This is rather speculative, but works surprisingly well with a lot of > applications.
Hm, that is a little dodgy indeed. But making user-selectable options (provided via env var) for correct decoding... doesn't seem ideal either. Is there some "correct" way to resolve this without changing the va api? -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
