[jhjh]

I'm having some issues while using VA-API with ATI igp (hd3200) which produce jumpy playback. I'm referring to this forum thread where user hal2100 is seeing the same problem.

I've managed to resolve the problem to VAAPI.cpp file and specific to the EnsureContext function. That function checkes the video streams reference frame count and based on that calculation a suitable surfaces count is reserved. The problem is, when reference frame count is for example 3 and the function reserves frame count + 2 surfaces, it doesn't work anymore and the result is video which jumps randomly back and forth between new and old frames. A quick fix was to reserve reference frame count * 2 surfaces. I'm not sure if that is the correct or optimized way to solve it, but the mplayer way to implement this is to always create 21 surfaces for h.264 videos, so I'm guessing it should be ok.

[Robotica]

Elupus implemented VAAPI so he probably knows whats happening...

[elupus]

Seems abit weird. Weird we should only need 2 extra frames. But i've heard same reports elsewhere. Is it enough to make it allocate +3 surfaces?

[jhjh]

I've done more testings with different encoding parameters, using different reference frame, b-frame and other settings and I couldn't replicate the problem that I have on one video. That problematic video is encoded using an old handbrake version which I don't have anymore. All the encodings done with new handbrake are working correctly with vaapi.

I guess the problem might be in the encoding itself which is done with some unusual settings. For now the solution could be using reference frame count + 3 when reserving surfaces. Atleast that works for me and to my problematic video and it appears that it doesn't break other videos playback.

OT @elupus: is there any progress to enable deinterlacing with vaapi? Because it appears that it is working now with mplayer when using bob deinterlacing. I don't know what is the situation with intel graphics but atleast ati is working. I could try to help with that so xbmc would have atleast bob deinterlacing when using vaapi.

[elupus]

okey, means that file is marked wrong on the number of ref frames. Could you get me that file. It should detect this and increase surfaces.

[jhjh]

The original video is Disney movie Cars and I'm not going to share that But I cut 30 second clip from the start which shows the problem and you can use that to test it. The file is here.

About that deinterlacing, it wasn't that off topic after all. When testing some very dirty hack to deinterlace 1080i video clip using bob, the same jumping frame problem appeared. The method I used to deinterlace was to copy surface twice on same frame (vaCopySurfaceGLX) using top and bottom field flags. It kind of worked, the picture was deinterlaced but the playback was jumpy and stuttering. The jumpiness was fixed when I added more surfaces, actually more than twice the ref frames, but the stuttering remained.

This was just to quickly test the deinterlacing, but should this be taken into account when fixing this playback jumpiness? I mean if the movie is interlaced or not if the deinterlacing is implemented in the near future.

[oleksiy]

http://forum.xbmc.org/showthread.php?p=6...post644712