[mythtv] iPhone streaming implementation

[Chase Douglas]

On Mar 23, 2009, at 4:02 PM, Rob Smith wrote:
> On Mon, Mar 23, 2009 at 10:45 AM, Chase Douglas
> <chasedouglas.lists at gmail.com> wrote:
>> You're missing the point. ffmpeg can probably do all the  
>> transcoding needed
>> for most clients. However, it does not provide much in the way of  
>> stream
>> transport. It claims support of rtp for instance, but I've never  
>> gotten it
>> to work. Your solution works fine if the client just expects a  
>> streaming
>> media file hosted over http, but not all clients can operate this  
>> way.
>>
>> In summation, there's three main parts to streaming live tv:
>>
>> 1. Control - Can use and extend MythTV protocol, can probably also be
>> universal
>> 2. Transcoding - Includes reencoding and remuxing, can probably  
>> also be
>> universal given ffmpeg is so good at transcoding
>> 3. Transport - Definitely not universal, and the method preferred  
>> by each
>> client will be different. For instance, some clients that handle  
>> transport
>> almost exactly the same may differ just in how they seek. One  
>> client's video
>> player may be able to seek on the stream, while another client's  
>> video
>> player may not and thus would need to request a seek all the way to  
>> the
>> MythTV server. It's practically impossible to support all clients  
>> in a
>> one-size-fits-all approach, and it probably makes the most sense to  
>> have a
>> plugin architecture due to the number of different transport  
>> implementations
>> I foresee. Maybe plugins aren't absolutely necessary if each  
>> transport
>> implementation can be enabled or disabled at configure time.
>
> So you asked about specific iphone streaming, which supports http just
> fine, I answered that this will work just fine with a few small
> tweaks, and now you're asking about general plugin arch? I'm all for a
> general streaming engine built into the backend, but I fail to see how
> I'm missing the point when the point started as a iphone specific
> method which is what I answered about...

The iPhone cannot "live" stream a file hosted on a website. It can  
only progressively stream a static file. This means the iPhone can  
stream a complete transcoding of an episode, but not live tv. The  
problem lies in streaming transport. I can tell you for certain right  
now (assuming Apple doesn't change their mind this late in the game)  
that the iPhone "live" streaming implementation requires more than  
just throwing up an encoded file on a website. Aside from Apple's  
implementation, if hosting a streaming file on a website adequately  
dealt with every stream transport issue then we would have no need for  
protocols like rtp, rtsp, or mms.

Note that everything hinges on the fact that this is "live" streaming.