[moving to mythtv-dev]
On Thu, Apr 14, 2005 at 08:54:02AM -0400, Donavan Stanley wrote:
> On 4/13/05, Robert Tsai <[EMAIL PROTECTED]> wrote:
> > - I set up a recording to use the "Low Quality" recording
> > profile, with commercial flagging disabled, and to
> > automaticalliy transcode.
>
> HDTV capture cards don't use recording profiles to determine any of
> thier parameters. The bitrate and what not are all set by the
> broadcaster, not Myth.
>
> That being said, you can transcode your recordings. But no, you
> can't use different quality settings.
I think this is something I think I can "fix" (and want to fix), but I
have to completely understand what is going on first.
Following is a little bit of mail someone sent to me off-list; I'm
attributing the ideas to that person, but preserving their anonymity
(they can re-identify themselves on-list if they want).
Can someone confirm my understanding of the recording/transcoders
profiles feature before I start work on it (apologies for the length)?
I think the source of confusion (at least for me) is that the
Recording Profiles adds a profile per "capture card", which is
generally correct, except that "Hardware HDTV" shouldn't show up (at
least not for HD-3000).
I imagine this is an artifact of the following use case, dominated by
analog users (e.g., PVR-x50):
- Set up recording profiles for desired target bitrate.
- Associate recording profile with a recording schedule.
- Watch encoded recorded material.
- Delete.
In essence, for analog-only users, the "recording profiles" really are
just "transcoding profiles", except done in real-time (in hardware?)
rather than as a post-processing step.
The "transcoders" recording profile, for analog-only users, then, is
really only used for archival purposes (e.g., RTjpeg/MPEG-4 is used
for archiving TV shows to DVD, and MPEG-2 is used for downsampling
DVDs, or is that MythDVD?), where the target transcoding bitrate
should be less than or equal to the original recording bitrate (hmm,
is this why people on the users list sometimes complain about
exploding disk space usage when they transcode a recorded show to a
higher target bitrate than originally recorded?).
Do I have that right? A lot of the above is pure inference because I
have only a combined frontend/backend HD-3000-only system.
So I think what would need to be done to accommodate HD-only users
wishing to select different downsampled transcodes of their shows,
without breaking analog-only users, is to split up the "Recording
Profiles" category into separate "Recording Profiles" (only applicable
to analog-captured recordings) and "Transcoding Profiles" (applicable
to everyone).
When setting up a schedule, in addition to the option to choose a
recording profile (which really should only be enabled for a show that
might be recorded on an analog card), there needs to be a new option
to choose a transcoding profile (or "none"). The option to
"automatically transcode" probably should be moved out of where it
currently is in the recording profile and into the schedule
parameters. In the "Watch Recordings" screen, the recording "Job
options" pop-up menu could then split up the "Begin Transcoding" job
option to allow the user to select a "transcoding profile" (with the
default set to what was originally configured).
> The transcode is long known to be something that needs a re-do to
> accomodate the varying resolutions of Digital TV and mixed
> analog/Digital systems. I believe it can be set to transcode
> without downsampling at all, which is something, but if you want it
> to downsample it only gets one setting.
Yes, I think this is what I saw. At the default "from RTjpeg/MPEG-4"
transcoders profile (2200kbps), my HD shows went from 7.5GB/hr to
about 6.5GB/hr, for which the math works out (2200kbps @ 640x480 is
approximately 1GB/hr, scaled upwards for 1920x1080 which is 6.75x of
640x480 = 6.7GB/hr).
> Eventually somebody (how about you?) will get around to coding a
> system where you can have a series of multiple transcoding profiles
> for mpeg2 to mpeg4, and the profile is chosen by some means.
For now, I've been contenting myself with just submitting small
patches for stuff like compiler warnings and 64-bit issues. But this
is something that might bother me enough into trying something more.
--Rob
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
