PVR-150 on 6-STABLE: success and mini HOWTO

[Danny Pansters]

On Thursday 20 December 2007 17:40:47 you wrote:
> On Dec 19, Danny Pansters wrote:
> > On Thursday 20 December 2007 00:00:02 you wrote:
> > > On Dec 19, Danny Pansters wrote:
> > > > I just completed setting up my brand new Hauppauge PVR-150 (MCE I
> > > > think) on 6.2-STABLE using the newish port from usleep. All this info
> > > > can be found, but it is scattered, so I thought it might be useful to
> > > > put together a short step by step guide:
> > >
> > >     (I'm becoming active again).
> > >
> > >     It also works on 7 and 8 with the attached patch.  Tuning works
> > >     best by frequency.  Once I choose s-video or composite input, I
> > >     can't switch back to the tuner.
> >
> > I get that too (reload of kernel module needed), and using -m panics the
> > kernel.
>
>     I didn't see my own reply to the thread, maybe because it had an
>     attachment.  Another easy way to panic the system is to open a
>     second instance of the device, it will play for a couple of
>     seconds and then panic, I've always been in X so I miss the error
>     message.  I'm not sure what the best fix is, I mean, concurrent
>     access at the device level is nice, but mutual exclusion will
>     probably by much easier to implement.

It plays here with two players, but obviously it's not meant for that.

>
> > >     I'm also kinda working on mythtv, I've got the latest built, but
> > >     it's failing at probing the inputs of the card (the version in the
> > >     ports works at that part, but fails to get schedules).  I've never
> > >     used mythtv so I don't have reference to a working version.
> >
> > I'm mostly interested in integrating pvr support into kbtv, with embedded
> > mplayer if need to (12% wcpu).

Using sdl for ao and vo significantly reduces CPU I noticed.

>     I have not heard of ktv.  I'll take a look tonight.  I made a
>     little progress on mythtv, it now download the tv listings from
>     schedules direct but the backend refuses to start-up the capture
>     card.  I think I've located the problem to the some autoprobing of
>     the cards inputs, I have some hacks that I will try tonight.
>
> > >     For now, I'm using a slightly hacked version of the devel version
> > >     of mpegcat (multimedia/gopchop) to split the mpeg stream on the
> > >     hour.  I intend to send those patches to the author, they are
> > >     trivial.
> > >
> > >     --Mat
> >
> > For (video) viewing, mpeg2dec (over sdl) also works, but that's without
> > any audio stream playing yet.
>
>     I record to a file, and split every hour, I use a script to
>     softlink the current file to a file called NOW.  I play using
>     'tail -F NOW | mplayer -vf pp=lb -cache 5000 -'.  Or playing the
>     file directly makes fastfowrard-rewind works, however, when
>     playing a file directly it's exists at EOF instead of pausing like
>     it does when reading from stdin.  I wonder how hard it would be
>     hack that in...
>
>     PVR-150 (and 250) interlace the video, so the de-interlacer is
>     required for nice looking output.

Especially when scaling < capture size, yes. Halfpack works wonders, it 
converts to packed YUY2 by taking the luma of one field only, not of both 
fields. It almost completely eliminates artifacts with panning movement.
I now use this:

mplayer -cache 4096 -vo sdl -ao sdl [-slave -quiet] -framedrop -vf 
halfpack /dev/cxm0

for viewing. Oddly, when using SDL you can tune without needing to pause the 
video. I further noticed that after long playing (2 hours?) the audio started 
stuttering. This seems to be solved by framedrop.

Dan