[Mesa-dev] [PATCH] st/va: add mpeg4 startcode workaround

Ilia Mirkin imirkin at alum.mit.edu
Fri Nov 6 11:28:44 PST 2015


On Fri, Nov 6, 2015 at 2:15 PM, Christian König <deathsimple at vodafone.de> wrote:
> On 06.11.2015 20:10, Ilia Mirkin wrote:
>>
>> On Fri, Nov 6, 2015 at 1:48 PM, Zhang, Boyuan <Boyuan.Zhang at 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


More information about the mesa-dev mailing list