[mythtv] iPhone streaming implementation

[Chase Douglas]

On Mar 23, 2009, at 6:51 PM, Rob Smith wrote:
> On Mon, Mar 23, 2009 at 3:24 PM, Chase Douglas
> <chasedouglas.lists at gmail.com> wrote:
>> Yes, that is exactly what I am talking about. However, the fact  
>> that you
>> even know of "HTTP Live Streaming" as it's called suggests that you  
>> have
>> access to the 3.0 dev docs? The only place I've seen a link to the  
>> actual
>> docs is inside Apple's confidential development forum. The fact  
>> that the
>> standard is not available outside of their site leads me to believe  
>> this is
>> covered by the NDA. Because of that, I'm still not going to go into
>> specifics yet.
>>
>> If you can post a link to the docs and it is publicly accessible,  
>> it would
>> make things that much easier, but I haven't been able to find it.
>>
>> Now, for those who are familiar with the iPhone's streaming  
>> capabilities,
>> there are further issues such as: what do you do when one tv program
>> finishes and the next one begins? Again, I don't want to discuss what
>> problems there are due to Apple's implementation here, so if anyone  
>> wants to
>> converse about specifics they can e-mail me off-list or we can meet  
>> in the
>> Apple dev forums. However, I can state that ffmpeg can't do it all  
>> alone if
>> you want a fully integrated experience.
>
> I do not have 3.0 developer access, nor have I signed a NDA, I googled
> for it, and found a link to them. I wasn't aware they were under NDA.
> With that in mind we shall drop the topic, and I fail to see why you
> are posting here if you are going to take it to the apple developer
> zone.

Can you point to how you found the docs? If they are public, and not  
just sloppy web server administration leaking a private directory,  
then the NDA doesn't apply to them. It would make future conversations  
much easier.

My point with all of this is to try to figure out how to best  
integrate streaming into MythTV. Side issues about exact iPhone  
implementations are really just side issues. The greater context of  
implementing streaming in MythTV is a more open issue, and I want to  
determine the best ways to implement it without building one  
implementation from scratch and having it shot down by the devs for  
architectural issues.

Here's one interface idea I've been playing with for live tv streaming:

This handles transcoding:
QUERY_RECORDER SPAWN_LIVETV etc..., get back a response with the  
recorder id
QUERY_TRANSCODER SPAWN_TRANSCODER[]:[]RECORDER[]:[]<recorder id>[]: 
[]<transcoder profile>, returns transcoder information like mythtv url  
for file

This handles streaming:
QUERY_STREAMER SPAWN_STREAMER[]:[]<streaming profile>[]:[]<mythtv url  
for file>, returns stream location

The SPAWN_TRANSCODER command would start up a transcoding. It would  
transcode files from the live tv chain into a file in the recordings  
directory like "<livetv chain id>.<transcoder profile>.<extension  
(mpg, m4v, etc.)>". The SPAWN_STREAMER command would start streaming  
the file according to a given profile. This profile would be something  
like "iPhone" or "rtsp", or "mms", or "rtsp-android" if the android  
movie player had quirks that needed to be accounted for.

The transcoder profiles would be user defined. It would have things  
like encoder and muxer selection, bitrates, ffmpeg flags, etc. The  
data would be kept in the mysql db of course. The streaming profiles  
would be hardcoded, with an ability to specify some options. Each  
streaming profile would need to be implemented separately. If you  
wanted to, you could implement an "ffmpeg" streaming profile to use  
ffmpeg's built in rtp, http, udp, etc., streaming support.

If you wanted to do live transcoding and streaming of a recording:

QUERY_TRANSCODER SPAWN_TRANSCODER[]:[]FILE[]:[]<mythtv url for  
recording file>[]:[]<transcoder profile>
QUERY_STREAMER SPAWN_STREAMER[]:[]<streaming profile>[]:[]<mythtv url  
for file>

Note that with QUERY_STREAMER, the file to be streamed doesn't have to  
be a transcoded file. It could be a recording file straight from the  
tuner card.

Thanks