[mythtv] Re: [PATCH] transcoding profiles v4.1

Robert Tsai rtsai1111 at comcast.net
Thu May 5 15:26:18 UTC 2005


On Thu, May 05, 2005 at 12:38:32AM -0400, Chris Pinkham wrote:
> > Just to clarify and avoid ambiguity, I've attached a new patch
> > attached without any of the unrelated cruft; no changes otherwise.
> 
> Couple questions/comments based on my initial observations after
> applying the patch.
> 
> 1) The "UPDATE table1, table2, tabl3 SET table1.column" syntax is
> not valid for MySQL v3.x, so this will need to be changed to
> something like the following and put after the performActualUpdate()
> call.
>
> ----------------------------------------
>         QString thequery;
>         int recordid;
>         MSqlQuery query(MSqlQuery::InitCon());
>
>         thequery = QString("SELECT r.recordid "
>                        "FROM record r, recordingprofiles p, codecparams c "
>                        "WHERE c.name = 'autotranscode' "
>                            "AND c.value = 1 "
>                            "AND c.profile = p.id "
>                            "AND r.profile = p.name; ");
>         query.prepare(thequery);
>
>         if (query.exec() && query.isActive() && query.size() > 0)
>         {
>             MSqlQuery query2(MSqlQuery::InitCon());
>             while (query.next())
>             {
>                 recordid = query.value(0).toInt();
>
>                 thequery = QString("UPDATE record SET autotranscode = 1 "
>                                    "WHERE recordid = %1;").arg(recordid);
>                 query2.prepare(thequery);
>                 query2.exec();
>             }
>         }
>     }
> ----------------------------------------

*Grumble*. OK. I'll work on this. I can shuffle around the SQL as
described above, but I don't think I'll be able to test it, as I only
have a single FE/BE system with whatever the debian default MySQL is
(presumably some 4.x version).

> The logic of the above update seems to be flawed anyway.  I set my
> recordings to record using the "Default" profile, and have
> autotranscode off except for my air2pc recording profile.  The
> update changed all my recordings to autotranscode = 1.  This isn't
> what I want, I only want recordings to transcode when they record on
> my air2pc card, not when they record on my M179 cards.

I think this is correct.

The intent of the SQL is to migrate all recording schedules associated
with an autotranscoding recording profile to have the
per-recording-schedule "autotranscode" flag set to 1. The recording
profiles continue to keep their present "autotranscode" flag.

There are two "autotranscode" flags floating around that eventually
get ANDed together.

Scheduled recordings can have autotranscode=1. This means that the
recording *may* be autotranscoded.

The "Default" recording profiles associated with your devices should
have autotranscode set to 1 or 0, depending on whether you want the
profile associated with that device to allow autotranscode. So in your
case, you would configure the Air2PC "Default" recording profile to
enable auto-transcode, and you would configure the M179 "Default"
recording profile to *not* enable auto-transcode. This
recording-profile-autotranscode means that any recordings associated
with this profile (on this device) *may* be autotranscoded.

The recording profile is looked up by name at the time the recording
is actually done, so it finds the one associated with the recording
device, so it should get the correct device-based "autotranscode",
which is then finally ANDed with the "autotranscode" value associated
with the recording schedule, to finally decide whether or not to kick
off mythtranscode.

It is this ANDing that should allow you to transcode only HD content,
and not transcode analog content (that was already compressed at
recording time).

That is the intent, anyway. Given my above explanation, do you still
see a problem? Can you verify in your database (and/or UI) that the
"Default" recording profiles associated with your M179 and Air2PC have
auto-transcode configured appropriately?

> 2) Would it make better sense to just have 1 column rather than
> the 2 you created.  The value would indiate one of the following:
> 
> 	* Do not transcode
> 	* Transcode using Autodetect
> 	* Transcode using 'Low Quality'
> 	* Transcode using 'Medium Quality'
> 	* Transcode using 'High Quality'
> 
> I think it would be nice if this could be wrapped into one setting
> on the scheduled recording editor page.  You might not be able to
> keep the recording profile ID in the column, but I think that having
> the 4 different profiles is enough, the same as it is with normal
> recording profiles for bttv and ivtv cards.

I actually started out doing it the way you suggested above, but it
means that it you schedule something to *not* autotranscode, then you
will be unable to transcode it later (since the setting says "do not
transcode").

By separating the boolean "autotranscode" from the actual transcoder
to use when transcoding is actually performed, one can configure a
transcoder to eventually use, without committing to immediate
auto-transcoding. Collapsing the "autotranscode" column with the
"transcoder" column will make this impossible.

Also, later on, I would like for the "Watch Recordings" popup to allow
a just-in-time selection of transcoder to use when choosing "Start
Transcoding"; currently the user has to remember what profile was
selected for the scheduled recording.

Does this make sense? Given the above explanation, do you still want
me to merge the "autotranscode" and "transcoder" columns?

If you agree with everything I say above, then the only thing I think
I need to deal with is the MySQL 3.x stuff. Otherwise, let me know
where you think I am wrong.

Thanks,
--Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20050505/7f82e5cd/attachment.pgp


More information about the mythtv-dev mailing list