Attempting to watch "live" TV from a Hauppauge PVR-150 (via /dev/v4l/video0) causes mplayer to segfault. Reproducible: Always Steps to Reproduce: 1. Run mplayer, typically: mplayer -demuxer mpegps -ao alsa -lircconf ~/TV/lircrc -lavdopts fast /dev/v4l/video0 2. Begins to draw a display screen and then segfaults. Actual Results: MPlayer interrupted by signal 11 in module: decode_video - MPlayer crashed by bad usage of CPU/FPU/RAM. Expected Results: It should be able to play video directly from device video0 without problem. It has done so in the past. It is unlikely that this is a Linux version, V4L or shared library problem as older versions of mplayer, e.g. the Gentoo version circa 3 Nov 2007, or a version compiled from the released mplayer source (#r25533) circa 12 Dec 2007 DO work fine on the same hardware, with the same version of Linux, with the same shared libraries with the same program arguments. Sometime in early 2008, the released versions of mplayer both from Gentoo and the actual direct mplayer source (I have compiled it) stopped working (and started segfaulting) when reading direct (streaming) video. The "production" release of mplayer should be backed off to one from late 2007 which works correctly with live v4l feeds. This is a problem specific to v4l feeds, the current mplayer will correctly play .mpg files and .vob files.
Created attachment 150097 [details] Strace of mplayer which segfaults I have compiled a full mplayer from source with debug symbols and attempted to perform a stack trace when the segfault takes place. It does not seem useful perhaps due to the requirement that the frame pointer must be omitted when compiling some modules. Either that or it is down in some low level library functions which have not been compiled with debugging. Perhaps this strace will help.
An interesting discovery related to this segfault. When looking at the strace I began to wonder why it was loading DLL files from /usr/lib/win32. If one renames this directory, thus preventing access to the Win32 DLL files, then mplayer will play the *video* from /dev/v4l/video0 (/dev/video0) fine. No sound is present. If one restores the presence in /usr/lib/win32 of: avisynth.dll, AVIFIL32.dll, DevIL.dll, GDI32.dll and MSACM32.dll mplayer will return to its segfaulting condition. The question might be "Is there any way to decode an MPEG stream (which is what the Hauppauge card is supposed to produce) without using Windows sound codecs?
> avisynth.dll, AVIFIL32.dll, DevIL.dll, GDI32.dll and MSACM32.dll None of these files are part of the official codec pack, and while fixes are welcome, there is no support for using these from upstream (which I represent). IMO you should just remove these. The missing sound issue is caused by something else, the -tsprobe option might help, but hard to say without the full MPlayer output.
Reimar, you are correct. Those codecs appear to be from a a download I installed when I had problems decoding a specific sound stream. Removing all codecs except those installed on Nov 10 2007 as part of the win32codecs ebuild, reveals a different set of problems. 1) mplayer will play video but no sound. 2) mplayer with "-lavdopts fast" seems to cause a different segmentation fault (trace will be attached). 3) mplayer with "-tsprobe" and various values from 512 through 100000 makes no difference. I am concerned that -tsprobe may be useless on an mpegpes stream but I know little about these areas.
Created attachment 150388 [details] Segfault and stack trace using "-lavdopts fast" Previous versions of mplayer did work with the option "-lavdopts fast". This is a recent bug introduced either by mplayer or the current v4l (v4l2?) changes.
Created attachment 150390 [details] Strace of mplayer with video but no audio This is an strace of a working mplayer which does display a video stream but provides no audio stream to alsa.
Try with 20090731 snapshot and up-to-date system. Reopen if it's still a issue.
