Streaming ty over wireless LAN - how to reduce bandwidth...?

[carlosp_uk]

Firstly, THANK YOU everyone working so hard on direct streaming of ty files from a Tivo. All users are incredibly grateful.

I have a SA Tivo Series 1, turbonet, and a wireless router.

Have tried out vserver/mplayer, which I use to sream direct from tivo. Also, now the TyShow filters to play uploaded ty files in WMP, and can't wait for the vserver filter to stream directly.

Sadly, the sheer bandwidth of the ty files means that, over a 101b wireless network, playback is choppy.

So... CAN BANDWIDTH BE REDUCED AT THE TIVO END? (i.e. server) Could a new vserver RE-ENCODE the stream at a lower bitrate before spewing it out across the network, then it would enable people to trasmit these streams over wireless networks without experiencing playback problems?

I presume a new vserver would be required, which processed and re-encoded the ty files before transmission.

Is this feasible? Does a solution already exist for my problem? Is anyone else having the same issues?

[rung]

That's a tall order - my Pentium 3 can't even reencode at real time. I'm afraid you'll have to move to a 802.11g network if you want streaming video.

[d7o]

Originally posted by carlosp_uk
Firstly, THANK YOU everyone working so hard on direct streaming of ty files from a Tivo. All users are incredibly grateful.

I have a SA Tivo Series 1, turbonet, and a wireless router.

Have tried out vserver/mplayer, which I use to sream direct from tivo. Also, now the TyShow filters to play uploaded ty files in WMP, and can't wait for the vserver filter to stream directly.

Sadly, the sheer bandwidth of the ty files means that, over a 101b wireless network, playback is choppy.

So... CAN BANDWIDTH BE REDUCED AT THE TIVO END? (i.e. server) Could a new vserver RE-ENCODE the stream at a lower bitrate before spewing it out across the network, then it would enable people to trasmit these streams over wireless networks without experiencing playback problems?

I presume a new vserver would be required, which processed and re-encoded the ty files before transmission.

Is this feasible? Does a solution already exist for my problem? Is anyone else having the same issues?

I've actually done a bit of looking into this. My current thoughts on this is that its a latency issue not a bandwidth issue.

For example, I used to have my tivo connected to my pc via 10mbit network for a long time. Typically it would take approximately 18 minutes to extract a 30 minute segment. My tivo would achieve approx 500kbyte/sec in throughput during transfer which for a 512 mbyte file, would take approx 18 minutes.

18 minutes to transfer 30 minutes of video should be sufficient to have playback yet it isn't most of the time.

However, switching to 100mbit makes a dramatic difference. It usually takes me about 5 minutes to transfer 30 minutes of video. Quite a bit of difference.

When mplayer makes a request to vserver, it does so in 128k chunks. Thats the size that the tivo handles its video in. So, a request goes over the wire for that 128k. That 128k is read in from disk and then send out over the wire.

Actually, that description is a bit overly simplified. vserver is a very dumb server. By that I mean that it doesn't implement much intellegence for the client. The client actually reads the MFS structures through vserver, interprets them and decides what ought to be read and reads it through vserver. Unncessary overhead, ihmo.

I did a test server which eliminated that problem but that didn't fix the problem substantially. My next solution to the problem was to read in 2k chunks instead of 128k. The idea was to keep the network doing something while we were trying to retrieve the 128k. This didn't fix the problem substantially but I suspect the way I implemented this may have been flawed and I intend to revisit the problem.

As for recompression, that is simply not feasible as the tivo just doesn't have enough cpu power. However I think it may really be possible to play video over 10mbit I simply think we need to design things better.

d7o

[sanderton]

Depends on how you record stuff too. A UK TiVo at Best is over 720KBytes/sec so however efficient you make vserver that won't work!

[AlphaWolf]

Originally posted by d7o
I've actually done a bit of looking into this. My current thoughts on this is that its a latency issue not a bandwidth issue.

For example, I used to have my tivo connected to my pc via 10mbit network for a long time. Typically it would take approximately 18 minutes to extract a 30 minute segment. My tivo would achieve approx 500kbyte/sec in throughput during transfer which for a 512 mbyte file, would take approx 18 minutes.

18 minutes to transfer 30 minutes of video should be sufficient to have playback yet it isn't most of the time.

However, switching to 100mbit makes a dramatic difference. It usually takes me about 5 minutes to transfer 30 minutes of video. Quite a bit of difference.

When mplayer makes a request to vserver, it does so in 128k chunks. Thats the size that the tivo handles its video in. So, a request goes over the wire for that 128k. That 128k is read in from disk and then send out over the wire.

Actually, that description is a bit overly simplified. vserver is a very dumb server. By that I mean that it doesn't implement much intellegence for the client. The client actually reads the MFS structures through vserver, interprets them and decides what ought to be read and reads it through vserver. Unncessary overhead, ihmo.

I did a test server which eliminated that problem but that didn't fix the problem substantially. My next solution to the problem was to read in 2k chunks instead of 128k. The idea was to keep the network doing something while we were trying to retrieve the 128k. This didn't fix the problem substantially but I suspect the way I implemented this may have been flawed and I intend to revisit the problem.

As for recompression, that is simply not feasible as the tivo just doesn't have enough cpu power. However I think it may really be possible to play video over 10mbit I simply think we need to design things better.

d7o

AFAIK the main reason we get slow download speeds with anything less than 100mbit is due to a MTU bug in the tivos kernel.

http://www.dealdatabase.com/forum/showthread.php?s=&threadid=22596&perpage=15&highlight=mtu%20kernel&pagenumber=2

Unfortunately, we would need a very skilled kernel hacker to be able to do anything about it, as thus far none of the major ones in the scene have been able to.