[mythtv] [experimental patch] pchdtv bttv support

[Isaac Richards]

On Tuesday 18 January 2005 08:57 am, Daniel Thor Kristjansson wrote:
> So the pchdtv driver advertises two /dev/v4l/video cards, so you need to
> add another column for extra device auxvideodevice. But I went back and
> looked at my first pchdtv w/bttv patch and it looks like the problem
> was that I also created another default input auxdefaultinput. This ment
> I could keep the old scan for inputs code, but also caused complications
> in the scheduler where I had to check the inputs connected to the
> regular input and the auxiliary input. But if I change the input scanner
> to prepend "Digitial:" to inputs scanned of the the ATSC input and
> "Analog:" to the inputs scanned of the NTSC input then the sceduler
> doesn't have to change, and the changes to tv_rec are at about the same.
> I have to change recorderbase to allow for an extra parameter, the
> auxvideodevice, and I need to make minor make changes in about the same
> places, but the schema won't really change.

I would simply add 2 columns to the input table - inputdevice and format, that 
can override the default settings of that specific capture card.

Ideally, the tv_rec.cpp changes would be extremely minimal, to the order of 
rebuilding the channel/recorder objects as needed.

> I'm not sure if this will impact the player though, can it cope with
> getting nuppelvideo one minute and mpeg2 the next? My guess is yes, but
> I'm not sure.

Ah, not _really_, but that would be fairly simple to add.  I'd think if the 
backend could send a 'different format' message on such an input & format 
change, that the frontend could simply treat that as a card change, which 
already handles the different format (it essentially tears down the player 
and rebuilds).

> If a different capture card has two sets of vbi and audiodev devices
> then we would need to duplicate those as well, which is an arguement
> for the multiple cards w/one tuner setup I devised. But I think this
> will work for PVR cards with radio, if we are willing to put the radio
> device in the auxvideodevice field (which I could name auxdevice).

Yup, I think so too..  Though, radio's really not all that interesting to me, 
due to the lack of guide data.

Isaac