Hi Christian,
2012/1/2 Christian König <deathsim...@vodafone.de>:
> Hi Maarten,
>
> first of all: Happy new Year and sorry for the late reply, have been on
> vacation for the last week.
>
>
> On 29.12.2011 16:41, Maarten Lankhorst wrote:
>>
>> Hey Christian,
>>
>> Op 26-12-11 14:00, Christian König schreef:
>>>
>>> Based on patches from Maarten Lankhorst<m.b.lankho...@gmail.com>
>>>
>>> Signed-off-by: Christian König<deathsim...@vodafone.de>
>>>
>>> diff --git a/src/gallium/include/pipe/p_context.h
>>> b/src/gallium/include/pipe/p_context.h
>>> index de79a9b..f7ee522 100644
>>> --- a/src/gallium/include/pipe/p_context.h
>>> +++ b/src/gallium/include/pipe/p_context.h
>>> @@ -410,7 +410,8 @@ struct pipe_context {
>>> enum
>>> pipe_video_profile profile,
>>> enum
>>> pipe_video_entrypoint entrypoint,
>>> enum
>>> pipe_video_chroma_format chroma_format,
>>> - unsigned width,
>>> unsigned height, unsigned max_references );
>>> + unsigned width,
>>> unsigned height, unsigned max_references,
>>> + bool
>>> expect_chunked_decode);
>>>
>> I really don't like this part, isn't it implied from entrypoint>=
>> PIPE_VIDEO_ENTRYPOINT_IDCT?
>
> Not necessarily, I'm still trying to give this interface a more general look
> and feel.
>
> So for the current use case it can be deduced from the fact that XvMC only
> supports entry-points IDCT and MC, while VDPAU only supports bitstream, but
> that doesn't necessary have to be always the case.
Even if this is true, it seems like this is a limitation that only
applies to the shader based decoder. The nouveau pmpeg xvmc
implementation in mesa doesn't need it at all.
~Maarten
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
