[mythtv] Slave backend using different encodings specs

Matt Zimmerman mdz at debian.org
Tue Mar 25 12:55:45 EST 2003


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

> Matt Zimmerman wrote:
> ...
> >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.
> 
> Yeah, adding a layer of indirection sounds like more goo but it would be
> fairly simple and add a lot of flexibility. I can imagine a three column
> table that holds the profile label number, The class name and the
> codecparams number. The 'record" table profile and codecparams profile
> fields would be unaffected by this (but some renaming may be in order ;-).

Now imagine a UI for making changes to this table. :-)

> I want to reiterate that most people would never need to create a second
> class but by having this, they could customize their profiles to suit
> whatever mixture of hardware they may have now or in the future.

It seems that the only advantage of creating classes, rather than using a
few fixed settings, is the ability to create new classes.  This seems like a
pretty small benefit compared to the added complexity of implementing it.
Or did you have a different application in mind?

> I don't believe it would be any harder (or easier) for users to understand
> that thay are changing the parameters for host "B" than it would be to
> understand that they are changing the parameters for their MJPEG card(s).
>
> The solution you suggest is suited to the Ben's request but doesn't
> address other cases. If someone had a hardware JMPEG card and a bttv card,
> either on the same machine or separate backends, they may want to record
> with both. Currently, the record table marks all the profiles as '0' (but
> I look forward to your support for per show profiles 8-). The user would
> want different codecparams for Default on the MJPEG than the Default on
> the bttv card whether they were on the same host or a different host. It
> is possible that she could use mpeg4 on both systems but she should have
> the choice of configuring these differently.

Where does the card fit in?  Are you suggesting that each capturecard entry
should have a default profile associated with it?  Or only that the profile
selections should be per-host?  The latter is already planned.  The former,
it seems, could be addressed by adding a profile column to the capturecard
table, if this is desirable.

To be honest, though, I only have one capture card in all my kingdom right
now, so I'm not really looking toward wildly heterogenous setups.  A single
backend with one MJPEG card and one bttv card seems like a bit of a corner
case at this point. :-)

> I agree that allowing custom profiles is a step towards this kind of
> indirection. However the problem remains that the 'record' table has one
> field for profile. The specific parameters to achieve the objective of
> that profile may be different for different cards.

That column is intended as an override for when the user requests specific
encoding parameters for a particular recording.  Otherwise, a default set of
parameters could be used (either a global default or a per-capturecard
default).  Things get weird if the record row is an allrecord, if for
example an allrecord matches both a source on a bttv card and a source on an
mjpeg card.

> In my case, I have four bttv cards in three machines. I would like to
> treat the two in the dual tuner system differently than the two in single
> tuner machines.

Assuming that you want to treat the dual tuners equally, that is addressed
with simple per-host default settings.

> For example, I'd like to record science shows on digital channels in high
> quality (record profile 2 for example, not necessarily literal ;). Three
> hours of talking heads war coverage on CNN, I'd want to save space
> (profile 3 in record).
>
> For high quality (2) assigned to a single tuner I want high res, high bit
> rate. For the dual tuner cards, med res, high bit rate. For saving space
> (3 in record) I'd use low res, low bit rate for the save space profile for
> either class of cards (codecparams 3 and 7 per my previous example).

1. Create a profile named "High Quality (single tuner)" and make it the
   default on the single-tuner systems
2. Create a profile named "High Quality (dual tuner)" and make it the
   default on the dual-tuner system
3. Create a profile named "Save Space"
4. For recordings where you desire the highest quality, configure the
   recording so that it will only happen on a single-tuner system
5. For low-quality recordings, select profile 3.
6. Be happy :-)

It sounds like the additional functionality that you want is to be able to
"fall back" to lower quality settings if the system cannot handle it.  I
think that appropriate defaults can get you more than 90% of the way there
with very little new code or complexity.

> Let me clarify that I don't believe the software should try to determine
> the class for a cardinput, the user should.  The user should be able to
> create a new class then add the cardinputs they want to have in that
> class.
> 
> When a new class is added, it would need to have at minimum a codecparams
> for Default. Until the user defines the params for the other labels,
> recordings with other profile values assigned to a tuner of that class
> should default to ...well, Default ;-).

I'm concerned that this will complicate things (code- and bug-wise, and
potentially UI-wise) for the 99% case to accomodate the 1% case.  It would
be challenging to have "the right thing" happen when there are so mayn
levels at which a preference is specified.  If a cardinput is a member of a
class, and the scheduled recording specifies a different class, which wins?
How do you ensure that a cardinput won't inadvertently be assigned a class
which it cannot support (Hardware MJPEG, frame size, etc.)?   That last one
is already a problem, of course, but I think would be more complex to solve
with a profile/class system than with the current design.

Of course, I'm not one to stand in opposition to someone willing to do the
work. :-)

-- 
 - mdz


More information about the mythtv-dev mailing list