[Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder

[Maarten Lankhorst]

Hey Andy,

2011/12/19 Andy Furniss <andyqos at ukfsn.org>:
> Maarten Lankhorst wrote:
>>
>> Hey Andy,
>>
>> On 12/07/2011 05:48 PM, Andy Furniss wrote:
>>>
>>> Maarten Lankhorst wrote:
>>>
>>>> Hm, could you test with some added sanity checks?
>>>
>>>
>>> mplayer: vl/vl_vlc.h:139: vl_vlc_eatbits: Assertion `vlc->valid_bits>
>>>  num_bits' failed.
>>>
>>>> If that works, maybe remove the vl_vlc_fillbits call I added in
>>>> vl_mpeg12_bs_decode
>>>> to see if that is what caused it. Unfortunately the bitstream parser
>>>> just fails to work
>>>> correctly here on a lot of my test videos, but that happens even without
>>>> this patch.
>>>
>>>
>>> Yea, since the rewrite I have seen some crashes - only at the end of some
>>> transport streams and only so far with svn mplayer, release mplayer doesn't
>>> do it.
>>>
>>>> You might want to check with valgrind to see if it tosses any warning,
>>>> too.
>>>> I don't suppose you have a short clip of the failing video that
>>>> reproduces the problem?
>>>
>>>
>>> Anything should do - I haven't found one that works yet, mpeg1, mpeg2
>>> progressive/interlaced, TS, PS, SD, HD with release mplayer or svn, all
>>> crash before rendering anything.
>>>
>>>
>> Ok looks like I found the issue, could you try the version below?
>
>
> It doesn't crash anymore, but there are regressions.
>
> On the plus side - some transport streams that used to crash/hang at the end
> with -vc ffmpeg12vdpau are now OK.
>
> Playing dvd from disc without -cache 8192 is still problematic. This only
> affects vdpau decode, xvmc was and still is OK.
>
> With the patch I get an assert rather than a hang/crash.
> mplayer: vl/vl_vlc.h:138: vl_vlc_eatbits: Assertion `vlc->valid_bits >=
> num_bits' failed.
Full backtrace please?

> although -cache xxxx mostly works around it. I can still rarely trigger it
> by doing a lot of skipping forward/back.
No idea why this would even affect things.

> With the patch and vdpau decode on some streams there is occasional
> corruption where a few of the bottom right macroblocks render as solid
> colours.
Might be related to previous issue.

> The next issue affects xvmc as well as vdpau - performance is quite severely
> reduced. Looking at top it seems that less Cpu is used with the patch, but
> fps is 50-60% worse - meaning with vdpau decode I can't even play some 30fps
> HD with my card on high, these would normally be OK on low.
Hm, I was using only a single decode buffer which removed all
batching, might be related. Just wanted to be sure this worked before
re-enabling it.

> In addition with vdpau decode I get some 1/4 - 1/2 second stalls when
> testing HD (this was in benchmark mode so I don't think it's just because I
> haven't got the perf to reach fps).