Kodi Community Forum

Alright folks, I just did a fresh compile from svn with maksimenkos patch applied and it doesn't change anything for me unfortunately. Patch applied fine, compile and install went fine, so I don't know what it would be on my side ...
Sorry, pastebin is kinda dead for me right now, can't upload complete log, but I guess this:

22:30:06 T:2872171408 M:1736466432 NOTICE: (VDPAU) Didnt found a Video Surface Available (Total: 1). Creating a new one. TRY #1
22:30:06 T:2872171408 M:1735561216 NOTICE: (VDPAU) Didnt found a Video Surface Available (Total: 2). Creating a new one. TRY #1
22:30:06 T:2872171408 M:1735561216 ERROR: (VDPAU) Error: The system does not have enough resources to complete the requested operation at this time.(23) at VDPAU.cpp:816
22:30:06 T:2872171408 M:1735561216 NOTICE: (VDPAU) Didnt found a Video Surface Available (Total: 2). Creating a new one. TRY #2

is the same that maksi gets without his patch. I get it still though with the patch applied. Any further suggestions?

boba

Get a 512mb card

I ordered a 9400gt 1024mb today :-) just wanted to see if that patch works. I wonder why it would work for maksi and not for me though ....

boba

It depends on the video. I couldn't properly play planet earth with my 256mb 8600GT card.

But other 1080p were fine. It depends on some "LEVEL" of the encode.

Right, Planet Earth was exactly what I was testing ...

boba

bobb0 Wrote:Speaking in totaly layman's terms, I find that just stopping and restarting the video tends to fix it. For me, it appears that VDPAU gets a frame (sometimes from a different movie) stuck in memory, as though the decoder wasn't properly cleared/reset/initialized.

Happens for me too sometimes with VDPAU. No matter if xrandr is used.

Created a ticket: http://xbmc.org/ticket/6411

Just to confirm, replacing my card with a 9400GT 1024mb solved all my 1080p h264 VDPAU problems. Planet Earth e.g. now plays like a charm ;-)

boba

bogey Wrote:Happens for me too sometimes with VDPAU. No matter if xrandr is used.

Created a ticket: http://xbmc.org/ticket/6411

I have seen the same problem.So far I've been able to solve it by just stopping and starting playback.

It should be fixed in -r19623. I'll try tonight.

Need a backtrace for a crash, a log file isnt much use. The sticky should give instruction on how to capture one.

Backtrace -> http://pastebin.com/m7254068b

Thats strange, are you running multiple monitors or something else strange? There's no reason I can think of that skipping around should cause preemption like you're seeing... that normally only occurs when something interferes with the display.

Just a single display (projector) over hdmi. I haven't upgraded any packages apart from normal SVN checkout and stuff..
I noticed some trac update regarding strictbindings so i tried to disable it but it didn't do any good. Normally i have both auto refresh rate and stricbindings enabled.

Also about this ticket http://xbmc.org/ticket/6411 and the issue with "You could get frames even from some different movie played earlier." I never had this problem earlier, but now after updating, i do.

I tested using the same file you're playing and recreated the issue, it would appear to be a bad encode, its choking our FFmpeg even in software mode (although current SVN mplayer can play it fine).

Its unfortunately unlikely that a fix for this will make 9.04 (it will require a new merge of FFmpeg)

I suspected that might be the case.. Weird coincidence that this happens with both h.264 videos that i "acquired" yesterday.