[mythtv] Playback profiles?
Kyle Rose
krose+mythtv at krose.org
Thu Dec 30 16:48:54 UTC 2004
Something I'm struggling with is the difference in vibrance between
ATSC and NTSC recordings, and between monitors (DLP vs. LCD vs. CRT,
in my case). NTSC recordings at the default PVR input levels look
very washed-out compared to ATSC recordings of the same material, but
I can modify the Xv picture settings to compensate for the most part.
However, the Xv picture settings are specific to frontend, not to
channel or recording. A similar but opposite problem exists for
"outputfilters", which are channel-specific, but should be
(recording,frontend)-specific. Furthermore, I don't find input
filters very useful at all because they presume that you want the
input filtered the same way for every potential playback device; but
this doesn't work when some devices are interlaced and some aren't, or
when some are more vibrant than others.
I don't see an easy solution to this. I think an architecture change
is in order, which can roughly be described as a "playback profile."
The playback profile is determined by a tuple (recordid, frontend
name) so that one can fine-tune specific types of recordings to
particular frontends. In my case, a washed out (say) ST:TNG scheduled
recording will be associated with
frontend DLP:
outputfilters: bobdeint, denoise3d, unsharp (when it exists :)
outputpicture: brightness:54 contrast:64 color:67
frontend LCD:
outputfilters: bobdeint, denoise3d, unsharp
outputpicture: brightness:50 contrast:64 color:60
frontend CRT:
outputfilters: none
outputpicture: default
while 720p football will be associated with
frontend DLP:
outputfilters: none
outputpicture: default
frontend LCD:
outputfilters: none
outputpicture: default
frontend CRT:
outputfilters: smart-interlace ( :) )
outputpicture: brightness:45 contrast:40 color:40
or something.
At this point, it's probably worthwhile to launch into the rathole re:
live TV and how it fits into the recording architecture. Live TV
should probably act like a recording with some default profile based
on the format, resolution, and interlacedness.
Just wondering what kinds of comments you guys have on implementing
something like this. It's important that it degrade into something
reasonable for those who don't see the need to tweak on a
per-recordid basis. I'm willing to look into the feasability of
implementing something like this, but (a) I need to know that this is
something that others are looking for and (b) I'd like to know what
problems others have foreseen in integrating the tvtime postprocessor
into the Myth architecture.
Cheers,
Kyle
More information about the mythtv-dev
mailing list