[MPlayer-users] Trouble with HD-PVR recordings

[Charlie Gunyon]

Hey Daniel (and everyone) - sorry to revive a dead thread but I felt
like I needed to put some more information out there as at least 1
person 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 can
toggle 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, the
lavf demuxer doesn't properly detect the audio format and no audio is
generated.  I've also found that if I'm streaming directly from the
HD-PVR, I need some kind of cache value... >= 2048 iirc.

I made a little bit of progress using -autosync 0 and -mc 1, but that
drops frames like crazy.  I know you need -mc 2 for PAFF streams, but
I tried that too and it was unsuccessful.  I don't even know what PAFF
is.

I guess I should reiterate what my problem is:

I have a Core2Quad 2.33 GHz (Q8200) and an onboard NVIDIA 9400m
chipset that supports VDPAU.  This configuration has no problem
playing normal h264 rips, like the HD rips you find on torrent sites
for instance.  Where I'm having trouble is playing MPEG-TS files
generated by the Hauppauge HD-PVR, which are 1080i, h264 & AAC/AC-3
(configurable).  The video/audio bitrate is configurable as well, and
the issue still exists after lowering them to the point of
ridiculousness, so I am confident it's not a
resource/bandwidth/bitrate issue of some kind.

The exact issue is that A-V slowly desyncs, with video lagging behind
audio.  I can fix this with -correct-pts, -autosync 0 and -mc 1, but
then 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 -lavdopts
skiploopfilter=all:skipframe=nonref /dev/video0

Frames are still dropped, and while I know I specified this, more are
dropped than I specified.  I eventually get the 'Your system is too
SLOW to play this!' message.  And to be clear, this occurs whether I'm
streaming directly from the HD-PVR or playing videos generated by the
device.  I also know that deint=0 is awful, but "good" hardware
deinterlacing drops even more frames, and "good" software
deinterlacing is even worse.  Daniel, your command-line pipes your
HD-PVR into MPlayer, is that significantly different than just
specifying /dev/video0?

I tried multithreaded FFMPEG, but its h264 decoding is too buggy to be
used.  I also suspected that my video card's VDPAU support was too
weak, so I ordered an awesome overclocked GTX260 (MSI OCv4).  That
also didn't work.  I should also mention that a couple of posts up
someone asked if transcoding to MKV helps the issue and I said that it
did.  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 that
my system has enough power to handle this stuff given sufficient
software support.

Honestly I'm not terribly interested in getting it working at this
point.  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 still
issues with:

  - h264 decoding/MPEG-TS demuxing
  - VDPAU implementation

or perhaps with the files that the HD-PVR generates (this is quite
likely).  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 my
experience out there and make sure that I'm not doing something
thoroughly incorrect.

Thanks,
-Charlie

On Sat, Jul 25, 2009 at 11:43 PM, Daniel Ranger<dranger003 at gmail.com> 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 at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users