On Sunday 20 February 2005 8:03, Ed Wildgoose wrote: > > >Unfortunately, the current requirement for a fairly heavy-duty system to > >decode HDTV means that front ends connected to standard televisions will be > >comparatively expensive as well as ruling out some very interesting > >possible front ends (such as the Mac Mini). > > > > > > I could be wrong, but I think it's mainly heavy duty because you are > decoding to such high resolutions. I suspect that if you run the > frontend at a low resolution then it will need far less CPU? > > I don't have HDTV so can't offer to test. But depending on the > implementation of the decoding it seems likely that there is a CPU > saving if you drop the resolution...
Nope; regardless of your display resolution, you still have to decode the full HD stream, *plus* you have to scale it (though the scaling is done in hw if you're using Xv, the norm). The only way to reduce the effort it takes to decode the video in software (we're assuming a frontend w/out HD-capable hw-assisted decoding) is to transcode the stream down to a lower resolution in advance. Since transcoding from HD -> SD in real-time is not currently viable at the consumer level, other options must be explored. I like Paul's idea of multiple simultaneous 'quality copies' of a program. Basically, the automatic transcoding function would be extended to allow a single source program to be transcoded into multiple different recording profiles, optionally keeping the original as well. The 'Watch Recordings' screen would filter out the duplicates, and when playback is requested would select the maximum-quality copy that the current frontend is capable of decoding (or capable of streaming, say for remote frontends with lots of horsepower but limited network bandwidth, like 802.11b). Obviously the drawbacks to this approach are (1) some frontends will not be able to watch a program until transcoding is finished, but that's not really a problem since presumably they couldn't watch the program at all without this capability, and (2) multiple copies of programs eat up disk space. As an initial step, it would probably be relatively trivial to add the following: add an option to keep both the original and the transcoded copies of a program and insert metadata for *both* copies into the database. Update the recordings screen with a method to view info about a program's recording parameters (resolution, bitrate, codec). As for allowing transcoding into multiple targets, this should also be easy with the new JobQueue facilities. The final piece of the puzzle would be the UI modifications for things like: delete (does delete remove *all* copies of a program?) and 'clutter' (i.e., a mechanism to filter duplicate programs from the list and only show the single 'best' copy a frontend is capable of). So, now someone just needs to volunteer to code it... I only have a single combined frontend/backend, so it's not my itch to scratch :-) -JAC _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
