[mythtv] Slave backend using different encodings specs

[Bruce Markey]

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 ;-).

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.

> 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).

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.

> 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.

Sorry, I didn't intend to suggest "Best quality" and "Save
Disk Space" as specific predefined profiles. I intended these
as examples of user defined 'Create a New Profile' with labels
that suggest the motivations for creating these custom profiles.

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.

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.

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).


> 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?

Exactly, this is why the user would want the freedom to
customize what parameters best suit a recordingprofile
objective as in my example above.

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 do appreciate you quick and thoughtful response. I hope
you will consider how this approach can allow the users to
handle foreseeable and unforeseeable situations rather than
treating LiveTV as an exception or the resources of a single
system as an exception.

Thanks Matt,

--  bjm