Frontend occasionally hangs on playback with VDPAU

[Paul <paul@…>]

On a few occasions the DVB-T video has hung (no command responses) when starting a TV recorded video (mpeg2)

So all I see is "Please wait..." and I have to kill frontend task to recover.

Frontend log follows: 2009-11-14 17:10:31.413 TV: Attempting to change from None to Watching WatchingPreRecorded? 2009-11-14 17:10:31.495 TV: StartPlayer?(0, Watching WatchingPreRecorded?, main) -- begin 2009-11-14 17:10:31.605 [mp2 @ 0x4e2f6a0]Header missing 2009-11-14 17:10:31.776 AFD: Opened codec 0xd195c30, id(MPEG2VIDEO) type(Video) 2009-11-14 17:10:31.776 AFD: codec MP2 has 2 channels 2009-11-14 17:10:31.776 AFD: Opened codec 0xd8c2320, id(MP2) type(Audio) 2009-11-14 17:10:31.782 Opening audio device 'default'. ch 2(2) sr 48000 2009-11-14 17:10:31.783 Opening ALSA audio device 'default'. 2009-11-14 17:10:33.339 WriteAudio?: buffer underrun 2009-11-14 17:10:33.376 VidOutVDPAU Error: Failed to initialise VDPAU 2009-11-14 17:10:33.399 VideoOutput?, Error: Not compiled with any useable video output method. 2009-11-14 17:10:33.399 NVP(1), Error: Couldn't create VideoOutput? instance. Exiting.. 2009-11-14 17:10:33.399 Unable to initialize video. 2009-11-14 17:10:53.070 playCtx, Error: StartDecoderThread?() Failed to startdecoder 2009-11-14 17:10:53.070 TV: StartPlayer?(0, Watching WatchingPreRecorded?, main) — end error === I have Nvidia 190.32 running Release-0-22-fixes/mythtv/ [22759]

Note is it possible to have some sort of error handling on the playback thread to recover from crashes like this..

do you require any more debug output?

[markk]

Can you please attach the output of 'mythfrontend -v playback' from a failed attempt at playback.

thanks

Mark

[paul@…]

Mythfrontend file

[paul@…]

I did some messing around and finally reproduced it, but there are some issues with prebuffering also in here but the last 100 lines is where all the action is for the crash

[markk]

(In [22890]) Add an explicit warning around video memory shortages when using VDPAU in release-0-22-fixes as well as advice on how to rectify the problem. Refs #7493 and #7570.

I'm not applying to trunk as this whole section of code will change for 0.23.

[paul@…]

so do I need a Nvidia card with more memory? it looks like 512Mb is still border line? and what vdpaubuffersize should I use?

[Douglas Goldstein <cardoe@…>]

paul,

I've got an NVIDIA ION based board that has 512mb on it. I experience the same issue (and even get the new error message that he's added in r22890). However markk has the same hardware by a different manufacture (My setup is an ASRock and his I believe was Zotac)

However an interesting workaround has presented itself. My recorded content is MPEG2 (PVR-150 and pcHDTV HD-5500) while items played by MythVideo? are H264 files. If I wait about 4 hours between using my setup and then attempt to play something MythTV recorded (MPEG2 format), it will fail. However if I first go into MythVideo? and play a H264 file and then exit out and then play a recorded show, then it works.

This still feels like there is some bug in the Watch Recordings side of the house.

[markk]

Can anyone confirm whether or not this is still an issue in trunk?

[anonymous]

Not sure if I was having the same issue or not. I was having frontend lockups while playing high motion video. Particularly about 4 or 5 in the course of a basketball game. It would take about 2 minutes before playback would restart with av sync way off. In that time I was unable to start new processes on the frontend machine or connect via ssh. An exisisting ssh connection would allow me to kill mythfrontend.

Since the vdpau changes in trunk, I have watched 3 games without a single lockup. This is very much improved.

[Marc Tousignant <myrdhn@…>]

I am seeing a similar issue with trunk but it only started recently, or I was just not watching the right recordings. Might be unrelated.

MythTV Version : 23358M MythTV Branch : trunk Network Protocol : 56 Library API : 0.23.20100127-1 QT Version : 4.5.3 Options compiled in:

linux debug using_oss using_alsa using_backend using_frontend using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_mheg

It does not happen all the time and atfirst I was thinking it had something to do with commercials as that seems to be the most prevalent time I have been seeing this issue. My frontend is locking up on standard def channels (PVR-500 recordings) on commercials or occasionally on the black frame between the commercials and the show I am watching. I have yet to see this issue happen on any recordings made from my HD-5000's. Which is why I think it only started recently as I was watching those recordings and not the ones from the PVR-500. I never let it continue like the last reporter, I always killed the process and let my scripts reload it and I was good to go. However, if I attempted to rewatch the same section of video it would lock again, I had to be carefull to jump over that section. I'll attempt to get a dbg log on the next one and submit it.

[Marc Tousignant <myrdhn@…>]

Ok, finally found a recording to duplicate the issue, not going to delete this one incase someone wants a sample.

Here is what is going on according to the frontend log.

'video_output' mean = '50119.30', std. dev. = '105827.13', fps = '19.95' 'video_output' mean = '33367.29', std. dev. = '391.15', fps = '29.97' 'video_output' mean = '33363.51', std. dev. = '333.66', fps = '29.97' 2010-02-04 23:29:06.643 NVP(0): 400 interlaced frames seen. 'video_output' mean = '33361.32', std. dev. = '366.38', fps = '29.97' 2010-02-04 23:29:08.316 VDP: Accepting: cmp(>= 1280 720) dec(vdpau) cpus(0) rend(vdpau) osd(vdpau) osdfade(disabled) deint(vdpauadvanced,none) filt() 2010-02-04 23:29:08.316 VDP: Accepting: cmp(>= 0 0) dec(vdpau) cpus(0) rend(vdpau) osd(vdpau) osdfade(disabled) deint(vdpauadvanced,none) filt() 2010-02-04 23:29:08.317 VDP: LoadBestPreferences?(2048x2048, 0) 2010-02-04 23:29:08.318 VDP: LoadBestPreferences?(2048x2048, 60) 2010-02-04 23:29:08.319 VDP: LoadBestPreferences?(704x480, 60) 2010-02-04 23:29:08.320 VidOutVDPAU: InputChanged?(704,480,1.33333) 'MPEG2 VDPAU'->'MPEG2 VDPAU' 2010-02-04 23:29:08.327 VidOutVDPAU: DiscardFrames?(1) 2010-02-04 23:29:08.327 VideoBuffers::DiscardFrames?(1): uUDULUUAUuUAAUDUU 2010-02-04 23:29:08.328 VideoBuffers::DiscardFrames?(): AADAAAAAAAAAAADAA -- done() 2010-02-04 23:29:08.328 VideoBuffers::DiscardFrames?(1): AADAAAAAAAAAAADAA -- done 2010-02-04 23:29:08.329 VidOutVDPAU: DiscardFrames?() 3: AADAAAAAAAAAAADAA -- done()

Backtrace to be attached shortly.

[anonymous]

Firstly, can I ask that people stop posting with clearly different issues and unrelated comments. It just means bugs take longer to resolve due to the overhead of processing the noise and the inevitable red herrings introduced. If you're not sure, just create a new ticket.

Marc - your issue should have been fixed in r23467.

Paul/Doug? - I'm still no closer to actually understanding the underlying problem in your cases but I'm wondering whether it is somehow related to #7853. mpeg2 seems to be a common issue though the point initialisation fails is clearly different. It may be that you both have mpeg2 streams that have a similar characteristic, the driver is not releasing something internally and hence initialisation of the next playback fails. I will post a debug patch for testing.

Mark

[Paul Wilson <paul@…>]

thanks Mark, note I haven't seen a crash in the last few weeks, so I'm probably not a good test case any more, and I have also upgraded my video card to a GT220 which has improved performance and stability, so I think it was some memory/buffer shortage in my old 8400 card, but definitely some crash/recovery would be good during in video playback would be good Paul

[markk]

Pushing back to 0.24

[anonymous]

I am having this problem with an ION board as well running 0.23rc2. It happens so often as to make the system almost unusable. Most times, after playing 1 264 video, nothing else in the system will play, and just hang on the "Please wait" screen.

[robertm]

You comment adds nothing to this discussion, I award you no points for this round.

[markk]

(In [25644]) Improved GPU memory management.

This expands some pre-existing cache clearing code in the D3D9 and VDPAU painters to include the OpenGL painter and adds a public method to clear the GPU memory cache on request. The D3D9 and VDPAU renderers then ask the main UI painter to clear its cache before initialisation.

This allows video cards with only 256Mb of memory to work when using VDPAU rendering - BUT only when using the VDPAU painter.

Unfortunately, while profiling clearly shows the OpenGL painter clears large chunks of video memory, that memory is not made available to VDPAU and hence there is no real benefit.

The painter caches could also be managed more effectively by tracking estimated memory consumption.

Refs #7570

[markk]

(In [25645]) Add VDPAU as a UI painter option in the Appearance settings.

The VDPAU painter is fully functional and using it allows for improved memory management when using VDPAU for video acceleration.

See r25644. Refs#7570

[markk]

Marked as invalid but in reality the code has changed a lot in the last 10 months and there is simply too much noise on this ticket.