Multicast video server

[d7o]

I'm trying to work on a solution for watching live tv off my tivo from windows. I've thought of several ways of going about this. This idea is I think would be the pie in the sky but I'm not much of a linux kernel programmer so I'm hoping someone might be able to help me out.

What I would like is a kernel module that monitors all chunk writes to the MFS. When it detects a write to a live buffer it multicasts that chunk. It would have to detect multiple live buffers so that it sends chunks written to one live buffer to one multicast address and chunks writter to the second live buffer to a second multicast address.

Obviously this is going to impact video extraction so there should be ioctls to turn it on and off.

The zen of live buffer viewing right?

My feeling is that hijacking the ioctls tivo uses to send video to the hard drive would be rather trivial. Multicasting it from a kernel module probably wouldn't be hard either. The hard part is going to be determining if the chunk is destined for a live buffer and if so, which one.

Any ideas or thoughts?

d7o

[Lost Dog]

I'm trying to work on a solution for watching live tv off my tivo from windows. I've thought of several ways of going about this. This idea is I think would be the pie in the sky but I'm not much of a linux kernel programmer so I'm hoping someone might be able to help me out.

Any ideas or thoughts?

d7o

I've been playing with this idea too...

I've been poking around to see if I can figure out if the recording buffer has an FSID associated with it. If it does, it should not be too much of a trick to have it listed in the "Now Showing" of TivowebPlus... Then you could use vserver to stream it to your PC.

Hmm... Maybe poking around in the thread for increasing the live buffer would give a place to start.... That would at least shed some light on how the live buffer is handled and from there you may be able to reference it to allow streaming.

[compwiz312]

I might be missing something, but when I connect using mplayer to my Tivo and do a list option, one of the items on the list is "Live" and as far as I can tell, it is the live buffer. Wouldn't you be able to just connect to that to watch livetv?

Justin

[Lost Dog]

I might be missing something, but when I connect using mplayer to my Tivo and do a list option, one of the items on the list is "Live" and as far as I can tell, it is the live buffer. Wouldn't you be able to just connect to that to watch livetv?

Justin

Huh. Who'd of thunk.

I guess I should take a look at mplayer! I've never used it so it's no wonder I missed that option!

[rc3105]

d7o:

here's a module that intercepts reads, should be easy enough to adapt for intercepting writes

alternatly, you could "core sample" a buffer to determine write position & trail along just behind - not really difficult, I've implemented that as a mfs_ftp patch to dl/broadcast recordings in progress



Lost Dog:

http://my_tivo/mfs/Recording/InProgress lists the buffers. the right twp config even has links to stream the buffers to mplayer or wmp...


nothing new under the sun. tridge & company started doin this sorta stuff years ago. search for vplay / playitsam

[TheWickedPriest]

The latest version of TyShow is supposed to support playing from the live buffer, and without running out the way MPlayer does.

[alldeadhomiez]

What's the advantage to intercepting (tystream-formatted) writes to the disk, over intercepting the PES going to the decoders?

I would imagine that the standards-based CS22 or BCM7020 hardware is comparable to whatever decoder software you're running on the PC side.

[JohnSorTivo]

I might be missing something, but when I connect using mplayer to my Tivo and do a list option, one of the items on the list is "Live" and as far as I can tell, it is the live buffer. Wouldn't you be able to just connect to that to watch livetv?

Justin

That'll put you to the beginning of the buffer, which can be as much as 30 mintues behind live tv. The only way to circumvent this is to change channels to "dump" the buffer, then change back, before streaming, which will get you "closer" to live tv on the channel you want to watch.

I was assuming that the proposed solution referenced in the topic of this thread was to enable you to essentially start streaming as close to live tv as possible, as opposed to the beginning of the buffer, without a workaround...

[rc3105]

d7o is talking about multicasting video data in realtime, lil bit different

say you have 3 sdtivos on a 100-switched home network and all 3 are broadcasting both tuners. network activity lights will be pretty berzerk but you'll still have plenty of bandwidth (more likely the multicast daemon would only begin broadcasting after a client request - why load tivo down with processes if nothing's watching it?)

multiple clients could watch the same tuner w/o any network performance penalty (hdtivo/hdtv + xbox/hdtv == 2(hdtivo/hdtv) )

multiple pc's could display both tivo tuners live or even do a pip display

mencoder could capture ty->divx 24/7

a myth box could treat the tivo as a network mpeg2 encoder & just issue channel change commands. (even hd streams are < 3 megabytes / sec)


lotta possibilities...

[FredThompson]

The latest version of TyShow is supposed to support playing from the live buffer, and without running out the way MPlayer does.

The beta on SourceForge deinterlaces (bleech) which cuts your effective frame rate in half and it wasn't playing nice with the standard interfaces. Lots of potential there, however.

To expand: interlaced NTSC is really ~60 fps composed of 2 interleaved sets of scan lines. Deinterlacing attempts to convert that to ~30 fps. A decent software viewer should actually convert to progressive 60 fps and display it that way on a monitor.

Even so, it would be better to serve interlaced data so the process is controlled by the viewer's hardware and software. Suppose you've got an ATi or Matrox card which supports a TV monitor as a second display device. Sure would be nice to send streamed video to that and still be able to use the primary monitor for comptuer stuff. http://www.omegadrivers.net/ might be a good place to get Win tech help for this sort of thing. I assume there are similar Linux drivers floating around.

[d7o]

d7o is talking about multicasting video data in realtime, lil bit different

lotta possibilities...

My thoughts exactly.

What's the advantage to intercepting (tystream-formatted) writes to the disk, over intercepting the PES going to the decoders?

I would imagine that the standards-based CS22 or BCM7020 hardware is comparable to whatever decoder software you're running on the PC side.

That would almost work too except that capturing data to the decoder only gives what the tivo is playing vs what the tivo is recording.

alternatly, you could "core sample" a buffer to determine write position & trail along just behind - not really difficult, I've implemented that as a mfs_ftp patch to dl/broadcast recordings in progress
...
nothing new under the sun. tridge & company started doin this sorta stuff years ago. search for vplay / playitsam

I'll look at the module, thanks. Can you explain what you mean be "core sample" a buffer?

I'll look for the vplay/playitsam stuff as well.

Thanks for the input.

d7o

[rc3105]

read & cache each chunk descriptor table (tiny amount of data) from the buffer fsid

repeat

compare lists


if you start with the last chunk, read/cache say 256, then start another "thread" doing the same thing you only have to keep 256 chunk descriptors in memory & the first change found pinpoints the current write location

--
btw:

the way mfs_ftp currently allocates new recordings they have a red dot in nowplaying and appear in /Recording/InProgress until transfer completes

that can fool the tivowebplus info module, mplayer, ccxstream, etc, into thinking there are more than 2 tuners recording

the "core sample" tracking method allows for extract / multicast / remote-playback of an insert while it's still inserting!


with intelligent overwrite (prolly topic for another thread) a client tivo with a nowplaying item consisting of a single fsid can pull video from a remote buffer/recording. for instance, each tivo could have nowplaying entrys for each tuner buffer avail on the local network

[d7o]

the way mfs_ftp currently allocates new recordings they have a red dot in nowplaying and appear in /Recording/InProgress until transfer completes

that can fool the tivowebplus info module, mplayer, ccxstream, etc, into thinking there are more than 2 tuners recording

Currently what I've got working is the kernel module that tracks all TY writes to the MFS and a userland piece that will take those write addresses and tell me which fsid they came from out of the entries in /Recording/InProgress. I've got some work left to do in the user space codel; some things are hard coded and I need to work on the communication between the kernel module and the user space daemon. Once that's done, though, all that will be left is the multicasting.

with intelligent overwrite (prolly topic for another thread) a client tivo with a nowplaying item consisting of a single fsid can pull video from a remote buffer/recording. for instance, each tivo could have nowplaying entrys for each tuner buffer avail on the local network

Hmm. Maybe I should buy another dtivo.

[mshook]

That'll put you to the beginning of the buffer, which can be as much as 30 mintues behind live tv. The only way to circumvent this is to change channels to "dump" the buffer, then change back, before streaming, which will get you "closer" to live tv on the channel you want to watch.

I've patched my version of player (you just need to comment/uncomment few lines of code) so I can easily go backward or forward (in this case). The only bug i haven't looked at nor fixed is when you reach the end of the buffer, ie mplayer doesn't know the buffer is circular.

[SpoonsJTD]

Sorry to resurrect an old thread, but was there any progress on this?