[mythtv] dynamic transcoding / multiple simultaneous quality levels

[Joseph A. Caputo]

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