MythTV Transcode Proxy and libcmyth Developments

[Chase Douglas-4]

Hello again,

I've been diligently working on MTP and my iPhone streaming  
application. When I first announced the code there were lots of things  
I had not even implemented let alone tested yet. Since then I've  
gotten things like program changes and seeking to function correctly.  
I can also stream at reasonable quality over 3G cellular without any  
need to pause to buffer. In fact, the entire architecture of MTP has  
changed from single threaded to multi-threaded, just to deal with live  
tv program changes (it's complicated... the MythTV protocol doesn't  
help either).

However, Apple today announced an update to its iPhone OS. Since my  
project is directed at the iPhone, relevant changes could affect my  
course of action with respect to my frontend, MTP, and related  
libcmyth changes. In fact, the new OS has support for true streaming,  
albeit very limited. I've weighed the pros and cons of my current  
approach and what I can do with the new OS. Here's a sampling:

Pros (of iPhone OS 3.0 built-in streaming with respect to what I had  
been implementing in my frontend):
* HW video decoding, meaning higher bitrates and greater resolution  
while using less battery and processor cycles
* Better streaming support (MythTV protocol was certainly never  
designed to be used across 800 ms single-hop latency cellular networks)
* I don't have to reimplement an A/V demuxer, video decoder, or media  
player (ffmpeg does not work well in strictly single-threaded  
environments)

Cons:
* Only the built-in video playback interface is allowed, no controls  
may be overlayed so no ch+ or ch- or anything other than vol+/-, play/
pause, and seeking
* Commercial skipping is all or nothing
* Will never be able to do anything that Apple doesn't implement in  
their video player, like playback at different speeds

I'm having to weigh these to figure out what I want to do. If it  
weren't for the commercial skipping issue with the iPhone OS streaming  
I would almost definitely choose the built-in support. If that's the  
case, MTP and my libcmyth changes would become practically irrelevant  
for my project.

I know that MTP is an interesting concept and may be very useful for  
dealing with HD captured content and MVPMC, so no matter what all my  
work to date will be put up on my repos for everyone to see and work  
on. However, if I do go with the built-in iPhone OS streaming support,  
I won't be maintaining MTP myself anymore. I will send another note to  
this list when I make a decision as to which way I go.

Thanks,
Chase Douglas

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Tom Metro-9]

Chase Douglas wrote:
> ...Apple today announced an update to its iPhone OS. Since my  
> project is directed at the iPhone, relevant changes could affect my  
> course of action with respect to my frontend, MTP, and related  
> libcmyth changes. In fact, the new OS has support for true streaming,  
> albeit very limited.
...
> If it weren't for the commercial skipping issue with the iPhone OS
> streaming I would almost definitely choose the built-in support. If
> that's the case, MTP and my libcmyth changes would become practically
> irrelevant for my project.

I'm not following. It sounds like you are describing a video player
client that is now available for the iPhone. If so, how will that payer
connect to your MythTV back-end. It's safe to assume it doesn't provide
a MythTV client, so it would be using some established streaming
protocol, like RTSP, HTTP, or UPnP. And only the latter is somewhat
supported by MythTV (unless you're thinking of Flash playback through
MythWeb), so would you still need some server-side glue to support this
other iPhone front-end?


> * HW video decoding, meaning higher bitrates and greater resolution  
> while using less battery and processor cycles
> * I don't have to reimplement an A/V demuxer, video decoder, or media  
> player (ffmpeg does not work well in strictly single-threaded  
> environments)

That all sounds good...


> * Only the built-in video playback interface is allowed...

I gather they didn't provide libraries for this functionality so you
could build your own enhanced UI on top of it?


> * Better streaming support (MythTV protocol was certainly never  
> designed to be used across 800 ms single-hop latency cellular networks)

While there is a MythTV protocol for controlling a MythTV server, the
video streaming itself isn't much more than spewing encoded video over a
TCP socket - no? So the suitability for high latency networks is more
dependent on the encoding chosen, which MythTV lets you vary, and your
MTP gives you even greater options. Unless you want to do something like
RTSP over UDP, and if so, I don't see why MTP couldn't provide that.

  -Tom


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Chase Douglas-4]

On Mar 17, 2009, at 9:59 PM, Tom Metro wrote:

> Chase Douglas wrote:
>> ...Apple today announced an update to its iPhone OS. Since my  
>> project is directed at the iPhone, relevant changes could affect  
>> my  course of action with respect to my frontend, MTP, and related  
>> libcmyth changes. In fact, the new OS has support for true  
>> streaming,  albeit very limited.
> ...
>> If it weren't for the commercial skipping issue with the iPhone OS
>> streaming I would almost definitely choose the built-in support. If
>> that's the case, MTP and my libcmyth changes would become practically
>> irrelevant for my project.
>
> I'm not following. It sounds like you are describing a video player  
> client that is now available for the iPhone. If so, how will that  
> payer connect to your MythTV back-end. It's safe to assume it  
> doesn't provide a MythTV client, so it would be using some  
> established streaming protocol, like RTSP, HTTP, or UPnP. And only  
> the latter is somewhat supported by MythTV (unless you're thinking  
> of Flash playback through MythWeb), so would you still need some  
> server-side glue to support this other iPhone front-end?

Please bear with me as I'm having to walk a fine line due to the pre-
release NDA for the new OS. I think I can reasonably state that it's a  
very slight extension to an existing protocol that is not natively  
supported by MythTV. However, just as with MTP, I could easily create  
a proxy in between the iPhone and the backend to transcode the video  
stream into the requested format without too much hassle. The  
difference is that it would no longer use the normal MythTV streaming  
protocol, and because I would no longer be able to support seeking or  
anything else using the normal protocol, it would cease to really be a  
MythTV proxy. It would be more of just a MythTV Channel and Recording  
Streamer which doesn't really proxy MythTV commands from a frontend  
but instead translates frontend requests into MythTV protocol requests.

>> * HW video decoding, meaning higher bitrates and greater  
>> resolution  while using less battery and processor cycles
>> * I don't have to reimplement an A/V demuxer, video decoder, or  
>> media  player (ffmpeg does not work well in strictly single-
>> threaded  environments)
>
> That all sounds good...
>
>
>> * Only the built-in video playback interface is allowed...
>
> I gather they didn't provide libraries for this functionality so you  
> could build your own enhanced UI on top of it?

The media player is unfortunately not a "UI element" like the rest of  
an iPhone app. It's an object that when you send it the "play" message  
it opens full screen and begins to play. It doesn't get embedded  
anywhere in your UI view hierarchy, it sits on top of all of that.  
There's no way to overlay anything on top of it.

>> * Better streaming support (MythTV protocol was certainly never  
>> designed to be used across 800 ms single-hop latency cellular  
>> networks)
>
> While there is a MythTV protocol for controlling a MythTV server,  
> the video streaming itself isn't much more than spewing encoded  
> video over a TCP socket - no? So the suitability for high latency  
> networks is more dependent on the encoding chosen, which MythTV lets  
> you vary, and your MTP gives you even greater options. Unless you  
> want to do something like RTSP over UDP, and if so, I don't see why  
> MTP couldn't provide that.

This is true, and I've actually gotten this to work over the cellular  
network. However, the issue is that you have to request data from the  
server, get a response, and then start to read data on the data  
socket. Thus, if the RTT of a response is 800 ms then you better be  
sure you are requesting over 800 ms worth of video each time.  
Otherwise you'll never get your video stream fast enough. on top of  
that, the ACKs and such of TCP don't help with bandwidth. A "best"  
solution would probably to implement full RTP over UDP, but since I've  
gotten this to work with regular TCP streaming I haven't looked into  
it too much.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel