[mythtv] Live transcode while recording

[Chase Douglas]

On Dec 1, 2008, at 1:11 PM, Rob Smith wrote:
> On Mon, Dec 1, 2008 at 5:57 AM, Chase Douglas
> <chasedouglas.lists at gmail.com> wrote:
>> It remains to be seen how this will affect battery life since only
>> Apple has access to the hw decoding capabilities of the iPhone. The
>> best I have been able to do with sw decoding is a 256x256 recording
>> (scaled to the correct aspect ratio) at 15 fps mpeg2 200 kbps. I  
>> think
>> that leaves just enough headroom for audio decoding and network
>> streaming.
>
> That's fairly limited when I can play back 640x480x30 h264 at 700kbit
> using the current streaming in mythweb, just have to pre-encode the
> video. Is orb also only streaming mpeg-2 to their custom player?

When you transcode your videos to h264 for the iphone, the iphone  
plays it using the built-in support for the hardware h264 decoding  
chip in the iPhone. However, the built-in support does not work for  
streaming files. The difference between what you think of as streaming  
through a transcoded file from mythweb and real streaming is that the  
transcoded video has a complete header and file info that the iphone  
can consume. I'm not sure exactly what the iPhone wants to have, but  
say the iPhone wants to read some data at the beginning of your video,  
then determines it needs to see something at the end of the video.  
With your transcoded video it can do that. It just requests from the  
web server the portion of the video at the end that it wants data for.

With real streaming, the video is of indefinite length. Some of the  
data the iPhone wants is not available in the same way when "real"  
streaming. Now, my description of what the iPhone really wants may be  
wrong, but the gist is that real streaming is different than streaming  
a static file.

So that all means that we can't use the iPhone SDK's media playing  
capabilities as it doesn't like "real" streams. Unfortunately, there's  
no other access to the hw decoder on the iPhone available in the SDK.  
Thus, third party apps are relegated to software decoding.

Also, scaled 256x256 at 15 fps mpeg2 doesn't sound very good. BUT, you  
are looking at a 3.5" screen and just wanting to play something in a  
convenient or on-the-go fashion. In reality, what I'm seeing through  
some of my test video files is that this encoding is quite reasonable,  
especially if you are wanting to stream over a cellular 3G network.

Now, you can always transcode your recordings to h264 that the iPhone  
can play back, and the iPhone frontend could play those back using the  
hw decoder, but you'll forgo niceties like commercial skipping. I  
imagine that the frontend will detect if it can play the recording  
using the built-in player and do so, and otherwise fall back to sw  
decoding with commercial skipping. In essence, you are deciding at  
transcode time how you want the iPhone to play back the recording.