[mythtv] Slave backend using different encodings specs

[Matt Zimmerman]

On Mon, Mar 24, 2003 at 04:44:04PM -0800, Bruce Markey wrote:

> Matt Zimmerman wrote:
> >On Mon, Mar 24, 2003 at 11:07:45AM -0500, Ben Brown wrote:
> >OK, then that is not implemented.  Eventually I think I will make a 
> >per-host
> >setting which selects which profile to use for Live TV.
> 
> You may remember in an earlier message on this topic, someone
> described having a Matrox and a bttv card in the same dual
> tuner system. This lead me to believe that a good solution
> would be to map the profile descriptions to specific codec
> parameters for a class of cards.
> 
> In other words, the profile field in the record table represents,
> say 0=Default, 1=(same as) LiveTV, 2=Best quality, 3=Save Disk
> Space, etc. Another table could then associate these with
> specific codecparams for a class of cards. For most people
> with one tuner, dual equivalent tuners, multiple backends with
> similar resources, they would only need one class and profile
> 0 (Default) is associated with codecparams 0. They would only
> need to enter these once, as we do now, rather than per host.
> 
> If they added an MJPEG or future HDTV, DVB, or hardware mpeg2
> card they could add a new class for these cards so that Default
> (0) is associated with codecparams 4, LiveTV (1) with params 5
> and so on. Any number of card classes could be created and
> any cardinputid could be associated with any class.

This is more or less what I was suggesting; I'm not sure that it makes sense
to do it in every case, as a complete additional layer of indirection,
however.  I think that two settings or so would be sufficient, and much
simpler.  For example, one setting for the default profile for recording,
and another setting for the default profile for Live TV.  Since we have
per-host settings, this would also provide for different defaults for
different systems.  Eventually, perhaps, it will be possible to explicitly
set the scope of a profile (per-host or global).

The user should be able to make most customization changes by adjusting the
existing sample profiles, or by creating new ones from scratch.  I don't
think that we need to provide "Best quality", "Save Disk Space" etc. as
an indirection layer, but we can provide them as example profiles showing
what kind of settings to start with to work toward a certain goal, and the
user can adjust from there.

> For me, I have some machines with similar resources but one has two tuners
> so parameters have to be geared to two recordings at once even though the
> other machines could record at higher resolutions. Either approach would
> work for me right now but I believe defining classes of cards will be more
> useful down the road.

I'm not convinced that the type of capture card is a useful criteria, except
in the case of hardware MJPEG.  CPU resources, storage resources, output
device, and input quality would probably be more significant (in that
order), don't you think?

-- 
 - mdz