Hey Andy, 2011/12/19 Andy Furniss <andy...@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). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev