[mythtv] Slave backend using different encodings specs

[mmbrich at customlinuxsolutions.com]

I have had a question and this thread seems to touch on it.  I have multiple 
backends but my main TV is hooked to a slave backend that I always want to 
have use it's local card.  Unless I set the cardid to 1 it always starts with 
the main backend, then when it tries to record, it uses the slave that I am 
watching which causes lots of skips, etc.  With profiles is there a way to 
bind a slave backend to only use its card for LiveTV?  Also, I set up a 
profile to use for the simpsons do I now put that recordingprofiles ID into 
the "profile" column of the "record" table?  The reason I ask is since they 
are all 0's I didn't want to mess something up.

I have asked the 1st question before and the answer was that Issac wanted to 
make that possible, I was just wondering if the profiles made it possible.

Thanks

Matt


On Tuesday 25 March 2003 10:55 am, Matt Zimmerman wrote:
> 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. :-)