2009-04-18, 01:12
Hello,
Following up on my previous post:
Further research show that nvidia vdpau trace shows the vdp_*_destroy functions right before another vid is going to play, or on xbmc exit... I guess that's how nvidia handles the vdp_*_destroy calls, or at least trace it...
For the other problem that I had (playing 1080p vids on 1080p output surfaces and the not enough resources error), even if I changed the NUM_OUTPUT_SURFACES just to 2 it would occasionally happen, so i digged a little bit more and found that if the vdp_video_mixer_create is called without the deinterlace features for videos not interlaced (as most of my .mkv's) it would then have resources for the creation of the required video_surfaces...
motd2k, I've uploaded a patch in http://pastebin.com/m21b98e20. If you could take a look at it and commit whatever you think is relevant I'd really appreciate it. Beside the handling of CheckFeatures (just adding the deinterlacing to the video mixer if its enabled and the video is interlaced), the handling of the output surfaces (keep a var with the total of output surfaces that were created without problems), the handling of FFGetBuffer (dont add a render struct to the m_videoSurfaces vector if the vdp_video_surface_create didnt return a VDP_STATUS_OK, so there is not an invalid handle in the render pool), there are some cosmetic changes...
Following up on my previous post:
maksimenko Wrote:b) Another thing that i've noticed is that when i set the VDPAU_TRACE to 1 or 2, and VDPAU_TRACE_FILE=vdpau.log and run xbmc (with an unmodified vdpau.[cpp|h] or with my modified one) the log contains the record for all the vdp_*_create calls, but not even one vdp_*_destroy call... tracing mplayer, it records both vdp_*_create and vdp_*_destroy calls... (I've tried with both 180.44 and 185.19 nvidia driver versions with the same results)... So, i dont know if vdpau is freeing its resources sucessfully or not...
Further research show that nvidia vdpau trace shows the vdp_*_destroy functions right before another vid is going to play, or on xbmc exit... I guess that's how nvidia handles the vdp_*_destroy calls, or at least trace it...
For the other problem that I had (playing 1080p vids on 1080p output surfaces and the not enough resources error), even if I changed the NUM_OUTPUT_SURFACES just to 2 it would occasionally happen, so i digged a little bit more and found that if the vdp_video_mixer_create is called without the deinterlace features for videos not interlaced (as most of my .mkv's) it would then have resources for the creation of the required video_surfaces...
motd2k, I've uploaded a patch in http://pastebin.com/m21b98e20. If you could take a look at it and commit whatever you think is relevant I'd really appreciate it. Beside the handling of CheckFeatures (just adding the deinterlacing to the video mixer if its enabled and the video is interlaced), the handling of the output surfaces (keep a var with the total of output surfaces that were created without problems), the handling of FFGetBuffer (dont add a render struct to the m_videoSurfaces vector if the vdp_video_surface_create didnt return a VDP_STATUS_OK, so there is not an invalid handle in the render pool), there are some cosmetic changes...