Re: [Openpvr-devel] Re: ongoing development, ideas, etc
Brought to you by:
brian_j_murrell,
jfunk
From: Brian J. M. <bff...@in...> - 2002-03-16 06:04:30
|
On Fri, Mar 15, 2002 at 02:40:19PM -0800, Robert Kulagowski wrote: > Hrmm. Really? Almost 1 GB? Ooops. I mean 800KB. :-) > Do we want to start discussing the algorithm for scheduling? While I may= not > be able to crank on the C code like Brian has I'd still like to feel like= I > can contribute. >=20 > I guess there are two possible cases to consider: > 1) The single tuner model > 2) The multiple tuner model, where the tuners may not necessarily be in = the > same PC >=20 > To me, I think it's pretty important to consider the multiple tuner model. It is. > I've been taking a look at the LinuxTV project over at http://www.linuxtv= .org > and http://www.cadsoft.de/people/kls/vdr/index.htm to see what they've co= me > up with. Their project is tightly tied to MPEG2 hardware encoder cards, = and > appears to be a mostly European project. Yes, my findings as well. I would like to try an MPEG2 card, but trying to get one from Germany just seems like a PIA. I wish support for the Hauppage card with the kfir2 chip on it would move forward. It would be nice to be able to make encoder machines that did not need 1+GHz processors. > One interesting thing that they did is the "SDRVP" protocol. It uses > ascii-text like commands, so that control of the VDR is possible through > telnet. It might be an interesting idea to crib, and could be used betwe= en a > group of PVRs as a means of scheduling, etc. Pointers to the concise specs? > The way they handle the multiple tuner model is to have a primary and then > slaves. That would be the way to do it, at least initially. I am not sure this is an application for full fault tolerant clustering or anything. > The primary is used as the main tuner, and it's what's displayed > onscreen. If there's a program recording coming up, it gets put to one of > the secondary tuner cards. If there are no secondaries available, then t= he > primary is used. Collisions are handled through on-screen prompts, and a > timeout. If the timeout expires (user isn't watching TV), then a priority > scheme is used to decide what gets recorded. The priority scheme is also > used to decide what gets deleted when disk space is running out. Interesting. > If the primary is recording something, and a channel change command gets > sent, and there is a free tuner available, the recording job gets handed = off > to a secondary card and the primary then changes channels. They state th= at > this isn't a clean transfer in the sense that there's going to be a gap, = so > the docs recommend changing channels during a commercial break. Yucky. > They do have all the "trick play" functionality working, along with > multi-speed FF and REW. What are they "playing back" with? MPlayer? > What they don't seem to have is a good scheduling mechanism. The EPG is > derived from in-band EPG data - no XMLTV or other scrapers are used. The= y do > have a flexible means of setting recordings, but it's still time-slot rat= her > than Show name based. Their program picker lets you choose a repeating > program that may not run M-F, like The Daily Show, for example, so you can > say that the show is on M-Th only. Still too much like a traditional VCR for me in that respect. > They also have a pretty good OSD. I can't tell whether the DVB cards that > they use provide analog video out, or if they're using a TV-out video car= d. Which project at linuxtv.org are you refering to with all of this? > Recording is done in 2GB chunks. They have an editing mechanism that all= ows > cutting commercials out of recording through mark-in and mark-out points. Cool. > There's also a web-based controller. See > http://www.linvdr.org/download/vdradmin/shots/ for screen shots. Yuck. I am not even entertaining a web-based interface. It will look like crap on a TV and take up too much real-estate. Besides, I am not planning on using X, but rather the framebuffer. gtk-framebuffer works just fine and DirectFB looks even more promising. > I'm curious as to how something like the Replay 4000 is able to determine > where the commercials are. Likely "black frames". > The Replay doesn't have a lot of CPU horsepower, > so I'm assuming that it's monitoring what the video encoder is doing, and > when it starts recording a whole lot of black (or fade to black) it recor= ds > an entry into an index file that says "possible commercial start at block= X". >=20 > The .ndx file is also used for executing forward and backwards skips. I > believe that the .ndx file is keeping track of the GOPs so that it knows > where the I frames are. That sounds feasible. b. --=20 Brian J. Murrell |