[mythtv] ivtv settings patch

Geoffrey Hausheer ou401cru02 at sneakemail.com
Sat Sep 6 11:18:35 EDT 2003


> > Dealing with the transcoder is tricky.  1st, there is little reason to
> > schedule a transcode if you haven't done the commercial cut (in which
> > case, use 'X'), or when you want to save space by doing RTJpeg to MPEG4
> > (use AutoTranscode).  I don't really see the use for control from
> > mythweb.
> 
> Well, just a matter of personal taste, I don't like going on 
> automatically (especially lengthy and disk-consuming processes) and 
> besides, I don't want to transcode stuff that I'll just watch and 
> scratch. Secondly, IMHO, I find the fact of having to watch the 
> recording in order to transcode it counter-intuitive. Thirdly, for 
> recordings I know I'll not watch soon, I like the fact of launching the 
> transcode after the recording, from the office, knowing that it'll be 
> probably done when I'm back.
> But, I agree these likings are maybe not the ones of the majority.
This is doable (you just need to send the right commands to mythbackend,
to start a transcoding).  These are normally sent after a recording is
finished or if the user pressed 'X', but it is easy to change.  This just
seems like a pretty advanced option to me.  I guess I just think of
transcoding as being 'free'.  It uses CPU that is not otherwise in use,
and shouldn't impact doing any other normal tasks, so I see no reason to
only transcode some programs (assuming commerical cut is not being used).
 thus there are two options: (1) transcode everything, (2) transcode
after doing commercial cut (use 'X').  Of course there are issues when it
comes to multiple tuner cards, but that is what I'm trying to fix here.

> > It all makes sense, but it is quite a bit more effort than what I was
> > actually plnning on implementing.  I'm also not sure it is very intuitive
> > for a user. If you have a 'MJPEG' profile, you can't attach it to a bttv
> > or pvr card (same for all others), so to me it seems backwards to have a
> > pool of profiles associated with random cards.
> 
> I totally agree that card-profile associations should be restricted 
> based upon types.
> I'm rather thinking in terms of database normalization and openness. 
> There are myriads of codec and/or encoder cards and/or technically 
> specific profiles (e.g. VCD) which could be potentially used with MythTV 
> and associated with different cards.
> Your multiple set approach is most the easiest to implement (and 
> again...), but it kind of de-normaize Myth as you can end-up with 
> exactly the same profile being duplicated several times.
> In terms of implementation, after having a look at the code, I think it 
> would be "technically" very easy to do, actually, if we add the db 
> fields to add the association. The complicated part will be to create an 
> intuitive setup frontend ;-)
After thinking about it more, I think I agree with you...A pool of
profiles would be somewhat more usable for the user (especially if myth
shipped with predefined profiles...then the user could just associate a
given profile witha given card).  And, yes, I think making this easy to
use will be the hardest challenge.

I'm currently in the process of trying to get both my cards to work on
the same box at the same time.  Once that has been conquered, I'll
probably try coding soimething.

.Geoff


More information about the mythtv-dev mailing list