Hey Daniel (and everyone) - sorry to revive a dead thread but I feltlike I needed to put some more information out there as at least 1person has e-mailed me specifically about this (found me on this list:) ) and I couldn't help them. So here we go. I'm using the component inputs on my HD-PVR (revision E1) and I cantoggle whether it generates AAC or AC-3 audio with info from that link- I'd already found it. Either way it doesn't make a difference, thelavf demuxer doesn't properly detect the audio format and no audio isgenerated. I've also found that if I'm streaming directly from theHD-PVR, I need some kind of cache value... >= 2048 iirc. I made a little bit of progress using -autosync 0 and -mc 1, but thatdrops frames like crazy. I know you need -mc 2 for PAFF streams, butI tried that too and it was unsuccessful. I don't even know what PAFFis. I guess I should reiterate what my problem is: I have a Core2Quad 2.33 GHz (Q8200) and an onboard NVIDIA 9400mchipset that supports VDPAU. This configuration has no problemplaying normal h264 rips, like the HD rips you find on torrent sitesfor instance. Where I'm having trouble is playing MPEG-TS filesgenerated by the Hauppauge HD-PVR, which are 1080i, h264 & AAC/AC-3(configurable). The video/audio bitrate is configurable as well, andthe issue still exists after lowering them to the point ofridiculousness, so I am confident it's not aresource/bandwidth/bitrate issue of some kind. The exact issue is that A-V slowly desyncs, with video lagging behindaudio. I can fix this with -correct-pts, -autosync 0 and -mc 1, butthen I get terrible framedrops. The command-line for this looks like(not copy-pasted, so forgive errors): mplayer -vo vdpau:deint=0 -vc ffh264vdpau,ffmpeg12vdpau -correct-pts-autosync 0 -mc 1 -cache 8192 /dev/video0 I also know there are neato tricks, like mplayer -vo vdpau:deint=0 -vc ffh264vdpau,ffmpeg12vdpau -correct-pts-autosync 0 -mc 1 -cache 8192 -lavdoptsskiploopfilter=all:skipframe=nonref /dev/video0 Frames are still dropped, and while I know I specified this, more aredropped than I specified. I eventually get the 'Your system is tooSLOW to play this!' message. And to be clear, this occurs whether I'mstreaming directly from the HD-PVR or playing videos generated by thedevice. I also know that deint=0 is awful, but "good" hardwaredeinterlacing drops even more frames, and "good" softwaredeinterlacing is even worse. Daniel, your command-line pipes yourHD-PVR into MPlayer, is that significantly different than justspecifying /dev/video0? I tried multithreaded FFMPEG, but its h264 decoding is too buggy to beused. I also suspected that my video card's VDPAU support was tooweak, so I ordered an awesome overclocked GTX260 (MSI OCv4). Thatalso didn't work. I should also mention that a couple of posts upsomeone asked if transcoding to MKV helps the issue and I said that itdid. I made a mistake when I tested that, it actually doesn't help.MKV/MPEG-TS makes no difference. Stuff that does work: - CoreAVC for Linux - VLC on Windows Both of those have pretty obvious downsides. But they do prove thatmy system has enough power to handle this stuff given sufficientsoftware support. Honestly I'm not terribly interested in getting it working at thispoint. Probably at some point I'll svn up everything and try it again(I haven't updated since I posted last). I suspect there are stillissues with: - h264 decoding/MPEG-TS demuxing - VDPAU implementation or perhaps with the files that the HD-PVR generates (this is quitelikely). If anyone has any ideas I'll put a little more time into it- I'm always happy to help - but I'm personally not that concerned.Again, my main motivation in reviving this was just to put myexperience out there and make sure that I'm not doing somethingthoroughly incorrect. Thanks,-Charlie On Sat, Jul 25, 2009 at 11:43 PM, Daniel Ranger<dranger003@xxxxxxxxx> wrote:>> This is an h264/ac-3 file in MPEG-TS. If I play this sample using the>> normal mpegts demuxer, then performance is bad. So I tried using the>> lavf demuxer but I got the following error:>>> h264/ac-3 would be recorded using the S/PDIF audio input.> Have you tried using the RCA instead?> You can force it when you load the driver as explained here:> http://www.mythtv.org/wiki/Hauppauge_HD-PVR#Miscellaneous_Kernel_Module_Options>> I personally have no issues on my side, but I use the RCA which produces an> h264/AAC stream instead (non-5.1).>>> mplayer -vo vdpau:deint=1 -vc ffh264vdpau,ffmpeg12vdpau -ao alsa>> -correct-pts xbox-sample.ts>>> Mine looks like this:>> cat /dev/video0 | mplayer - -vo vdpau:deint=0 -vc ffh264vdpau -mc 0 -delay 2.1> -cache 8192>> Try adding the -cache 8192, I need it for playing the live stream from my> HD-PVR but I can omit it when playing a saved ts file such as when I cat> /dev/video0 > test.ts for example.>> I use cat /dev/video0 so I can simply add | tee test.ts to save to file at the> same time.>> PS: I know deint=0 sucks so when I re-encode I use -vf yadif=2 but for live> streaming deint=0 or -vf field=0 (when not using VDPAU) is good to me.>>> Or with the lavf demuxer:>>>> mplayer -vo vdpau:deint=1 -vc ffh264vdpau,ffmpeg12vdpau -ao alsa>> -correct-pts -demuxer lavf xbox-sample.ts>>> I don't use the lavf dexumer since I have no issues but it also works for me.>>> My system specs (if it helps):>>>> MPlayer SVN-r29435-4.2.4 (C) 2000-2009 MPlayer Team>> I run SVN-r29438.> My launchpad PPA is at https://launchpad.net/~dranger003/+archive/ppa if you> want to try the same mplayer I'm using.>> Hopefully you'll sort this out.>> Dan>>> _______________________________________________> MPlayer-users mailing list> MPlayer-users@xxxxxxxxxxxx> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users_______________________________________________MPlayer-users mailing listMPlayer-users@xxxxxxxxxxxxxxxxx://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
