Mailing List Archive: MythTV: Dev

[PATCH] transcoding profiles

Index | Next | Previous | View Threaded

rtsai1111 at comcast

Apr 19, 2005, 7:22 PM

Post #1 of 12 (2039 views)
Permalink

[PATCH] transcoding profiles

Today, HDTV recordings are limited to either no transcoding, or
transcoding to the parameters in the MPEG2 recording profile. They
aren't encoded at capture time, so there is no subsequent option to
save a configurable amount of disk space.

Attached is a patch to allow the configuration of a fixed number of
transcoding profiles ("High Quality", "Medium Quality", and "Low
Quality").

Summary:

- Upgrade DB schema:

- The option to automatically transcode a recording
has been moved out of the recording profile and into
the record (so that the currently-unused
"autotranscode" column is now useful).

When the database is upgraded, recording schedules
using recording profiles with auto-transcode enabled
will have auto-transcode carried over.

- Each record, in addition to a now-used
"autotranscode" option, also gets a new "transcoder"
option, which defaults to "Autodetect".

- Delete the now-unused "autotranscode" option from
the codecparams table.

- Provide some fixed transcoders: "High Quality",
"Medium Quality", and "Low Quality". Unfortunately,
no default values are actually provided, the user
must configure their desired values for these
transcoders. Also unfortunately, there is no UI to
add or remove transcoders (just like there is no UI
to add or remove recording profiles). However,
transcoders may be added to the database and things
should work, if people need more than these three
transcoders.

- The default transcoder for all recordings is "0"
(autodetect) to preserve current behavior.

- Add some logging to indicate when transcoding is
starting/stopping (both to the regular log as well as the
database logs).

- MythFrontend UI changes:

- Remove "automatically transcode" option from
recording profiles; auto-transcode is now a
per-recording option (parallel with per-recording
recording profiles).

- Add auto-transcode and transcoder options to each
recording schedule, configurable at the time the
recording is scheduled. Default values are:

- No auto-transcode.
- "Autodetect" transcoder.

The "Autodetect" transcoder will choose between the
"From MPEG4/RTjpeg" and "From MPEG2" transcoders,
like it does today. Eventually the choice of
transcoder can be made more configuration (e.g.,
select transcoder based on 1080i/720p/480i
resolution of recording). For now, just preserve
behavior.

- Add global settings UI to configure default values
for auto-transcode and transcoder, near default
values for commflagging and userjobs.

- MythTranscode changes:

- Fix a typo in the "help" text. :)

- Add some output to reflect transcoding parameters.
This bit is mostly unnecessary, but can be useful
for identifying exactly what is happening for
"autodetect" transcoder jobs.

Possible breakage:

- I'm not exactly sure how the "Live TV" recording profile is
used when saving "Live TV" during live TV (is this even
possible?). For normally-scheduled recordings that just
happen to be configured with the "Live TV" recording
profile, things are fine. But I'm unsure of the
save-live-TV-on-the-fly implied by this code.

See the diff for libs/libmythtv/tv_rec.cpp.

If this is broken, let me know and I'll fix it; I would make
auto-transcode-saved-live-TV a global option rather than a
per-profile option. Other suggestions are welcome.

Thanks,
--Rob

Attachments:

myth-dev.diff.bz2 (5.37 KB)

rtsai1111 at comcast

Apr 30, 2005, 12:04 PM

Post #2 of 12 (1943 views)
Permalink

Re: [PATCH] transcoding profiles [In reply to]

Version 2 patch attached.

Also:

- Change JobQueue status to sort by inserttime rather than
starttime. Jobs may be manually queued in an order other
than when the recordings were broadcast, and I think the
"Backend Status" page would make more sense to show the job
queue sorted by what has just happened and what is about to
happen.

Short-comings of the current system that have not been addressed by
this patch (e.g., should be no change in behavior or functionality):

- No way to only transcode a show if it was recorded by a
certain device. For example, one might want to only
transcode HDTV recordings, but not analog recordings.

I only have HD-3000 cards, so I can't really work on this aspect of
what I can see as being desired related functionality.

On Tue, Apr 19, 2005 at 10:22:23PM -0400, Robert Tsai wrote:
> Today, HDTV recordings are limited to either no transcoding, or
> transcoding to the parameters in the MPEG2 recording profile. They
> aren't encoded at capture time, so there is no subsequent option to
> save a configurable amount of disk space.
>
> Attached is a patch to allow the configuration of a fixed number of
> transcoding profiles ("High Quality", "Medium Quality", and "Low
> Quality").
>
> Summary:
>
> - Upgrade DB schema:
>
> - The option to automatically transcode a recording
> has been moved out of the recording profile and into
> the record (so that the currently-unused
> "autotranscode" column is now useful).
>
> When the database is upgraded, recording schedules
> using recording profiles with auto-transcode enabled
> will have auto-transcode carried over.
>
> - Each record, in addition to a now-used
> "autotranscode" option, also gets a new "transcoder"
> option, which defaults to "Autodetect".
>
> - Delete the now-unused "autotranscode" option from
> the codecparams table.

for non-"Live TV" profiles.

> - Provide some fixed transcoders: "High Quality",
> "Medium Quality", and "Low Quality". Unfortunately,
> no default values are actually provided, the user
> must configure their desired values for these
> transcoders. Also unfortunately, there is no UI to
> add or remove transcoders (just like there is no UI
> to add or remove recording profiles). However,
> transcoders may be added to the database and things
> should work, if people need more than these three
> transcoders.
>
> - The default transcoder for all recordings is "0"
> (autodetect) to preserve current behavior.
>
> - Add some logging to indicate when transcoding is
> starting/stopping (both to the regular log as well as the
> database logs).
>
> - MythFrontend UI changes:
>
> - Remove "automatically transcode" option from
> recording profiles; auto-transcode is now a
> per-recording option (parallel with per-recording
> recording profiles).
>
> - Add auto-transcode and transcoder options to each
> recording schedule, configurable at the time the
> recording is scheduled. Default values are:
>
> - No auto-transcode.
> - "Autodetect" transcoder.
>
> The "Autodetect" transcoder will choose between the
> "From MPEG4/RTjpeg" and "From MPEG2" transcoders,
> like it does today. Eventually the choice of
> transcoder can be made more configuration (e.g.,
> select transcoder based on 1080i/720p/480i
> resolution of recording). For now, just preserve
> behavior.
>
> - Add global settings UI to configure default values
> for auto-transcode and transcoder, near default
> values for commflagging and userjobs.
>
> - MythTranscode changes:
>
> - Fix a typo in the "help" text. :)

--Rob

Attachments:

mythdev-mythtv.diff.bz2 (7.15 KB)

rtsai1111 at comcast

May 1, 2005, 3:50 PM

Post #3 of 12 (1938 views)
Permalink

Re: [PATCH] transcoding profiles v3 [In reply to]

Version 3 patch attached.

Small diff relative to v2; fixed a corner-case crash involving live TV
and a freshly-installed database with no codecparams for recording
profiles.

On Sat, Apr 30, 2005 at 03:04:39PM -0400, Robert Tsai wrote:
> Version 2 patch attached.
>
> Also:
>
> - Change JobQueue status to sort by inserttime rather than
> starttime. Jobs may be manually queued in an order other
> than when the recordings were broadcast, and I think the
> "Backend Status" page would make more sense to show the job
> queue sorted by what has just happened and what is about to
> happen.
>
> Short-comings of the current system that have not been addressed by
> this patch (e.g., should be no change in behavior or functionality):
>
> - No way to only transcode a show if it was recorded by a
> certain device. For example, one might want to only
> transcode HDTV recordings, but not analog recordings.
>
> I only have HD-3000 cards, so I can't really work on this aspect of
> what I can see as being desired related functionality.
>
> On Tue, Apr 19, 2005 at 10:22:23PM -0400, Robert Tsai wrote:
> > Today, HDTV recordings are limited to either no transcoding, or
> > transcoding to the parameters in the MPEG2 recording profile. They
> > aren't encoded at capture time, so there is no subsequent option to
> > save a configurable amount of disk space.
> >
> > Attached is a patch to allow the configuration of a fixed number of
> > transcoding profiles ("High Quality", "Medium Quality", and "Low
> > Quality").
> >
> > Summary:
> >
> > - Upgrade DB schema:
> >
> > - The option to automatically transcode a recording
> > has been moved out of the recording profile and into
> > the record (so that the currently-unused
> > "autotranscode" column is now useful).
> >
> > When the database is upgraded, recording schedules
> > using recording profiles with auto-transcode enabled
> > will have auto-transcode carried over.
> >
> > - Each record, in addition to a now-used
> > "autotranscode" option, also gets a new "transcoder"
> > option, which defaults to "Autodetect".
> >
> > - Delete the now-unused "autotranscode" option from
> > the codecparams table.
>
> for non-"Live TV" profiles.
>
> > - Provide some fixed transcoders: "High Quality",
> > "Medium Quality", and "Low Quality". Unfortunately,
> > no default values are actually provided, the user
> > must configure their desired values for these
> > transcoders. Also unfortunately, there is no UI to
> > add or remove transcoders (just like there is no UI
> > to add or remove recording profiles). However,
> > transcoders may be added to the database and things
> > should work, if people need more than these three
> > transcoders.
> >
> > - The default transcoder for all recordings is "0"
> > (autodetect) to preserve current behavior.
> >
> > - Add some logging to indicate when transcoding is
> > starting/stopping (both to the regular log as well as the
> > database logs).
> >
> > - MythFrontend UI changes:
> >
> > - Remove "automatically transcode" option from
> > recording profiles; auto-transcode is now a
> > per-recording option (parallel with per-recording
> > recording profiles).
> >
> > - Add auto-transcode and transcoder options to each
> > recording schedule, configurable at the time the
> > recording is scheduled. Default values are:
> >
> > - No auto-transcode.
> > - "Autodetect" transcoder.
> >
> > The "Autodetect" transcoder will choose between the
> > "From MPEG4/RTjpeg" and "From MPEG2" transcoders,
> > like it does today. Eventually the choice of
> > transcoder can be made more configuration (e.g.,
> > select transcoder based on 1080i/720p/480i
> > resolution of recording). For now, just preserve
> > behavior.
> >
> > - Add global settings UI to configure default values
> > for auto-transcode and transcoder, near default
> > values for commflagging and userjobs.
> >
> > - MythTranscode changes:
> >
> > - Fix a typo in the "help" text. :)

--Rob

Attachments:

mythtv.diff.bz2 (5.98 KB)

rtsai1111 at comcast

May 2, 2005, 3:33 PM

Post #4 of 12 (1923 views)
Permalink

Re: [PATCH] transcoding profiles v4 [In reply to]

Version 4 patch attached; this should be final (!).

Small diff relative to v3; supports per-recording-profile,
per-schedule transcoding. This supports the notion of "auto-transcode
this show if it was recorded on an HDTV tuner, but don't transcode if
it was recorded on an analog card". This ended up actually cleaning up
some code in the previous diff.

Thanks,
--Rob

On Sun, May 01, 2005 at 06:50:14PM -0400, Robert Tsai wrote:
> Version 3 patch attached.
>
> Small diff relative to v2; fixed a corner-case crash involving live
> TV and a freshly-installed database with no codecparams for
> recording profiles.
>
> On Sat, Apr 30, 2005 at 03:04:39PM -0400, Robert Tsai wrote:
> > Version 2 patch attached.
> >
> > Also:
> >
> > - Change JobQueue status to sort by inserttime rather than
> > starttime. Jobs may be manually queued in an order other than
> > when the recordings were broadcast, and I think the "Backend
> > Status" page would make more sense to show the job queue
> > sorted by what has just happened and what is about to happen.
> >
> > Short-comings of the current system that have not been addressed
> > by this patch (e.g., should be no change in behavior or
> > functionality):
> >
> > - No way to only transcode a show if it was recorded by a
> > certain device. For example, one might want to only transcode
> > HDTV recordings, but not analog recordings.
> >
> > I only have HD-3000 cards, so I can't really work on this aspect
> > of what I can see as being desired related functionality.
> >
> > On Tue, Apr 19, 2005 at 10:22:23PM -0400, Robert Tsai wrote:
> > > Today, HDTV recordings are limited to either no transcoding, or
> > > transcoding to the parameters in the MPEG2 recording profile.
> > > They aren't encoded at capture time, so there is no subsequent
> > > option to save a configurable amount of disk space.
> > >
> > > Attached is a patch to allow the configuration of a fixed number
> > > of transcoding profiles ("High Quality", "Medium Quality", and
> > > "Low Quality").
> > >
> > > Summary:
> > >
> > > - Upgrade DB schema:
> > >
> > > - The option to automatically transcode a recording
> > > has been moved out of the recording profile and into
> > > the record (so that the currently-unused
> > > "autotranscode" column is now useful).
> > >
> > > When the database is upgraded, recording schedules
> > > using recording profiles with auto-transcode enabled
> > > will have auto-transcode carried over.
> > >
> > > - Each record, in addition to a now-used
> > > "autotranscode" option, also gets a new "transcoder"
> > > option, which defaults to "Autodetect".
> > >
> > > - Delete the now-unused "autotranscode" option from
> > > the codecparams table.
> >
> > for non-"Live TV" profiles.
> >
> > > - Provide some fixed transcoders: "High Quality",
> > > "Medium Quality", and "Low Quality". Unfortunately, no
> > > default values are actually provided, the user must
> > > configure their desired values for these transcoders.
> > > Also unfortunately, there is no UI to add or remove
> > > transcoders (just like there is no UI to add or remove
> > > recording profiles). However, transcoders may be added
> > > to the database and things should work, if people need
> > > more than these three transcoders.
> > >
> > > - The default transcoder for all recordings is "0"
> > > (autodetect) to preserve current behavior.
> > >
> > > - Add some logging to indicate when transcoding is
> > > starting/stopping (both to the regular log as well as the
> > > database logs).
> > >
> > > - MythFrontend UI changes:
> > >
> > > - Add auto-transcode and transcoder options to each
> > > recording schedule, configurable at the time the
> > > recording is scheduled. Default values are:
> > >
> > > - No auto-transcode.
> > > - "Autodetect" transcoder.
> > >
> > > The "Autodetect" transcoder will choose between the
> > > "From MPEG4/RTjpeg" and "From MPEG2" transcoders,
> > > like it does today. Eventually the choice of
> > > transcoder can be made more configuration (e.g.,
> > > select transcoder based on 1080i/720p/480i
> > > resolution of recording). For now, just preserve
> > > behavior.
> > >
> > > - Add global settings UI to configure default values
> > > for auto-transcode and transcoder, near default values
> > > for commflagging and userjobs.
> > >
> > > - MythTranscode changes:
> > >
> > > - Fix a typo in the "help" text. :)

--Rob

Attachments:

mythtv.diff.bz2 (7.12 KB)

cpinkham at bc2va

May 2, 2005, 7:23 PM

Post #5 of 12 (1957 views)
Permalink

Re: Re: [PATCH] transcoding profiles v4 [In reply to]

> Version 4 patch attached; this should be final (!).
>
> Small diff relative to v3; supports per-recording-profile,
> per-schedule transcoding. This supports the notion of "auto-transcode
> this show if it was recorded on an HDTV tuner, but don't transcode if
> it was recorded on an analog card". This ended up actually cleaning up
> some code in the previous diff.
>
> Thanks,
> --Rob

Thanks. I'll try to get the HDTV part tested (since you said you can't
verify it) and applied to CVS in the next couple days.

--
Chris

cpinkham at bc2va

May 2, 2005, 7:52 PM

Post #6 of 12 (1944 views)
Permalink

Re: Re: [PATCH] transcoding profiles v4 [In reply to]

> Version 4 patch attached; this should be final (!).

I'm assuming the mythcdrom-linux.cpp and RingBuffer changes
slipped into your patch by accident.

--
Chris

rtsai1111 at comcast

May 2, 2005, 8:01 PM

Post #7 of 12 (1913 views)
Permalink

Re: Re: [PATCH] transcoding profiles v4 [In reply to]

On Mon, May 02, 2005 at 10:52:06PM -0400, Chris Pinkham wrote:
> > Version 4 patch attached; this should be final (!).
>
> I'm assuming the mythcdrom-linux.cpp and RingBuffer changes
> slipped into your patch by accident.

Oops, yeah. You can leave those out.

--Rob

rtsai1111 at comcast

May 2, 2005, 8:01 PM

Post #8 of 12 (1938 views)
Permalink

Re: Re: [PATCH] transcoding profiles v4 [In reply to]

On Mon, May 02, 2005 at 10:23:10PM -0400, Chris Pinkham wrote:
> > Version 4 patch attached; this should be final (!).
> >
> > Small diff relative to v3; supports per-recording-profile,
> > per-schedule transcoding. This supports the notion of
> > "auto-transcode this show if it was recorded on an HDTV tuner, but
> > don't transcode if it was recorded on an analog card". This ended
> > up actually cleaning up some code in the previous diff.
>
> Thanks. I'll try to get the HDTV part tested (since you said you
> can't verify it) and applied to CVS in the next couple days.

No, the HDTV works fine. I can't verify that things work as intended
for analog cards. My system is HDTV-only.

Thanks,
--Rob

rtsai1111 at comcast

May 2, 2005, 8:11 PM

Post #9 of 12 (1931 views)
Permalink

Re: Re: [PATCH] transcoding profiles v4.1 [In reply to]

On Mon, May 02, 2005 at 11:01:14PM -0400, Robert Tsai wrote:
> On Mon, May 02, 2005 at 10:52:06PM -0400, Chris Pinkham wrote:
> > > Version 4 patch attached; this should be final (!).
> >
> > I'm assuming the mythcdrom-linux.cpp and RingBuffer changes
> > slipped into your patch by accident.
>
> Oops, yeah. You can leave those out.

Just to clarify and avoid ambiguity, I've attached a new patch
attached without any of the unrelated cruft; no changes otherwise.

--Rob

Attachments:

mythtv.diff.bz2 (5.90 KB)

cpinkham at bc2va

May 2, 2005, 8:34 PM

Post #10 of 12 (1924 views)
Permalink

Re: Re: [PATCH] transcoding profiles v4.1 [In reply to]

> On Mon, May 02, 2005 at 11:01:14PM -0400, Robert Tsai wrote:
> > On Mon, May 02, 2005 at 10:52:06PM -0400, Chris Pinkham wrote:
> > > > Version 4 patch attached; this should be final (!).
> > >
> > > I'm assuming the mythcdrom-linux.cpp and RingBuffer changes
> > > slipped into your patch by accident.
> >
> > Oops, yeah. You can leave those out.
>
> Just to clarify and avoid ambiguity, I've attached a new patch
> attached without any of the unrelated cruft; no changes otherwise.

OK, thanks. I'll test on my mixed M179/air2pc setup.

--
Chris

cpinkham at bc2va

May 4, 2005, 9:38 PM

Post #11 of 12 (1921 views)
Permalink

Re: Re: [PATCH] transcoding profiles v4.1 [In reply to]

> 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();
}
}
}
----------------------------------------

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.

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.

--
Chris

rtsai1111 at comcast

May 5, 2005, 8:26 AM

Post #12 of 12 (1904 views)
Permalink

Re: Re: [PATCH] transcoding profiles v4.1 [In reply to]

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

Attachments:

signature.asc (0.18 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads