View Single Post
Old 02-01-11, 02:23 PM   #13
Registered User
Join Date: Jun 2005
Posts: 36
Default Re: VdpauDecoderRender() takes unusually long to complete


Originally Posted by rnissl View Post
Meanwhile I have been able to reproduce this behavior myself. It happens always for the same call (1795th in xine, 1796th in mplayer) of vdp_decoder_render() when replaying the sample from the beginning.
Some more information:
If you start replaying a bit later in the stream, the message is nolonger reported. I've used a bisect approach and found the following byte offset: 10845227. For example
dd if=watchdogtest.ts of=watchdogtest2.ts skip=1 bs=10845227
mplayer/mplayer -vo vdpau -vc ffh264vdpau -demuxer lavf watchdogtest2.ts
often reported the message
A:31440.1 V:31440.1 A-V:  0.000 ct: -0.688   0/  0  1%  0%  0.6% 18 0 

========== vdp_decoder_render() returned after 35.246 ms ==========
call 1550

A:31447.0 V:31447.0 A-V:  0.000 ct: -0.688   0/  0  1%  0%  0.6% 18 0
while skipping a little more let the message vanish. And skipping a little less showed the message always.

Using the original sample and xine running in debugger gives the following backtrace for the video decoder thread when my watchdog fires (the video output thread currently sleeps and there is no thread trying to lock the display nor holding the display lock):
(gdb) bt
#0  0x00007ffff5356e87 in ioctl () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007fffef64b887 in ?? () from /usr/lib64/
#2  0x00007fffef5ff07d in ?? () from /usr/lib64/
#3  0x00007fffef5f9fe8 in ?? () from /usr/lib64/
#4  0x00007fffef61d279 in ?? () from /usr/lib64/
#5  0x00007fffef5f082c in ?? () from /usr/lib64/
#6  0x00007fffef5e0df7 in ?? () from /usr/lib64/
#7  0x00007ffff0190db3 in guarded_vdp_decoder_render (decoder=47, target=14, picture_info=0x7fffeaac6a40, bitstream_buffer_count=1, bitstream_buffers=0x7fffeaac6d90) at ../../../xine-lib-1.2/src/video_out/video_out_vdpau.c:284
#8  0x00007fffd445e000 in vdpau_decoder_render (this_gen=0x7fffd002c960, vdp_buffer=0x7fffeaac6d90, slice_count=1) at ../../../../xine-lib-1.2/src/video_dec/libvdpau/vdpau_h264.c:631
#9  0x00007fffd445e932 in vdpau_h264_decode_data (this_gen=0x7fffd002c960, buf=0xb2daa0) at ../../../../xine-lib-1.2/src/video_dec/libvdpau/vdpau_h264.c:830
#10 0x00007ffff7b914d1 in video_decoder_loop (stream_gen=0xad5ca0) at ../../../xine-lib-1.2/src/xine-engine/video_decoder.c:404
#11 0x00007ffff55f4a4f in start_thread (arg=0x7fffeaac7710) at pthread_create.c:297
#12 0x00007ffff535e82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#13 0x0000000000000000 in ?? ()
In case you require the load base of libvdpau, this is what I get when I quit xine:
VDPAU nvidia: Version: NVIDIA VDPAU Driver Shared Library  260.19.36  Tue Jan 18 17:14:46 PST 2011
VDPAU nvidia: Error detected 1 2335 
VDPAU nvidia: Backtrace:
--: /usr/lib64/ [0x7fffef5ce000] DSO load base
00: /usr/lib64/ [0x7fffef5e2e3e] 
01: /usr/lib64/ [0x7fffef5ebc97] 
02: /usr/lib64/ [0x7fffef5d724f] 
03: /usr/lib64/ [0x7fffef5dbde3]
Despite the guarded_ prefix in the above backtrace, this function does not lock the display as video_out_vdpau.c was compiled with #undef LOCKDISPLAY.

rnissl is offline   Reply With Quote