openpvr-devel Mailing List for OpenPVR (Page 5)
Brought to you by:
brian_j_murrell,
jfunk
Menu
▾
▴
openpvr-devel — Development of an Open PVR
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(2) |
Feb
|
Mar
(28) |
Apr
(22) |
May
|
Jun
(19) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
(7) |
Dec
|
| 2003 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2004 |
Jan
(4) |
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian J. M. <f21...@in...> - 2002-03-15 05:58:15
|
On Thu, Mar 14, 2002 at 09:46:47PM -0600, Dave Caplinger wrote: >=20 > Yep, I picked it up for $30 (and it has stereo audio and came with the=20 > remote, as well as an FM tuner I don't care about.) Good deal! > I've been trying to keep up with NVrec; it's nice that it puts the same= =20 > front-end (cmd-line) interface on the various encoders since it makes it= =20 > easier to compare, but I haven't played with the recent ones lately. I did the same thing. In CVS there is a utility called "record" which accepts an easy to use, unified list of cmdline switches and translates them into the various native cmdline switches for a handful of encoders -- mainly the ones I have been interested in. That way I can easily switch from one encoder to another without having to try to remember how the switches work. > It figures... I just tried to go to his web site and now I can't reach=20 > it (www.cheema.com/vcr). I added it to the OpenPVR wikki a few weeks=20 > ago; sorry if it's gone forever now. :-( It was a nice web front end to= =20 > view a TV schedule, and click on a program to schedule a recording of=20 > it. Exactly the kind of thing that my wife would have no problem=20 > understanding and using to select shows to record. Also you could see=20 > what was previously recorded and click on it to stream it to your=20 > computer for viewing. (It was designed for a client-server approach to=20 > PVR, and he was/is doing his viewing on a PC, not a TV, but the schedule= =20 > browsing was nice and clean (just text and tables, no distracting=20 > graphics etc). Sounds nice. > Yes, I'm eager to try this out. Let me know what you think. I do have to find some time to get things a little more polished. Like not keeping the xml files in /tmp, and cleaning out some debug, etc. but I use it daily to set up my own recording. It just spits out the 2 weeks worth of recording as "at" commands and I cherry pick them daily and enter them manually -- until I am happy that it is working correctly. > Well I tried framebuffer first but I had all kinds of problems with the= =20 > i810 framebuffer driver. Granted that was several months ago so maybe=20 > things are different now. If I can get it working, you're right that=20 > DirectFB sure looks nice :-) The only thing about DirectFB that I am a bit worried about is overhead. On a card well supported by mplayer, like the G400 or Radeon, the CPU used for video display is negligent. I fear that DirectFB will add some to that. I still have to go back and play with DirectFB some more. Currently I am using mga_vid with mplayer. > Well yes, but in the "X-Files marathon" case there are a TON of X-Files= =20 > episodes that I have in fact seen, but there is no way I'm going to=20 > manually enter 8 seasons worth of data into my PVR just so it won't=20 > won't record them again. ~grin~ http://epguides.com/ It takes some hacking to get it into the seen_programs xml format, but a vim macro or two takes care of it. A perl program to convert all of the episodes of a given program into the xml file should be trivial. > (There's lots of stuff that I've seen in my=20 > lifetime that my PVR will have no clue that I've seen since it never=20 > recorded it.) See above. Now if you have only seen "some" episodes and you want to try to see the ones from previous seasons that you have not seen yet, it gets ugly, but in most cases, for the stuff I watch, if the episode is a year or two old, I don't much care to see it. In other cases, I have been watching the show religiously enough that I can assume I have seen all previous episodes. > Agreed; I just didn't expect this feature as part of the "base=20 > functionality" I am trying to get to. Neither had I. Until I started thinking about it, and then found XMLTV, and then I said what the heck and coded it up. Now it's the best thing I did in this whole adventure. I love it. The only one part about it that does not work well yet is that not all programs (coming from XMLTV which means zap2it in North America) have "sub-titles" (episode names) and they are repeated so you wind up getting the same episode more than once. The scheduler just inserts the "seconds since Jan. 1 1970" Unix time in there. I have been thinking of allowing the user to define a mask to name episodes with if there is no name given. I think being able to use some of the specifiers available in the "date" command could figure this out. So if you know that all of the "untitled" episodes of "Foo" in a given week (Sun-Sat) are the same, you could give a mask of "%U-%Y". Once it had been recorded once that week, it would not be recorded again until next week. Where this breaks is if the programs are repeats from (say) Wed-Tue of the following week. Or if there are two different episodes a week, repated Sun-Wed and Thu-Sat. I need to give this some more thought. > I'd be thrilled to have it of=20 > course. :-) 'Tis nice. :-) b. --=20 Brian J. Murrell |
|
From: Dave C. <de...@co...> - 2002-03-15 03:43:58
|
Brian J. Murrell wrote: >>Capture hardware: Pinnacle Studio Pro PCI (bttv driver) > > Why that one? Cheap? Yep, I picked it up for $30 (and it has stereo audio and came with the remote, as well as an FM tuner I don't care about.) >>Capture software: NuppleVideo (not the best compression, but the a/v >>sync is good, unlike others I've messed with so far) > > CVS versions of mp1e are good. NVrec has great a/v sync for divx, > div4, ffmpeg codecs. I've been trying to keep up with NVrec; it's nice that it puts the same front-end (cmd-line) interface on the various encoders since it makes it easier to compare, but I haven't played with the recent ones lately. >>today, but I have hopes that cheematv's code will be available for this > > ^^^^^^^^ > What is this? It figures... I just tried to go to his web site and now I can't reach it (www.cheema.com/vcr). I added it to the OpenPVR wikki a few weeks ago; sorry if it's gone forever now. :-( It was a nice web front end to view a TV schedule, and click on a program to schedule a recording of it. Exactly the kind of thing that my wife would have no problem understanding and using to select shows to record. Also you could see what was previously recorded and click on it to stream it to your computer for viewing. (It was designed for a client-server approach to PVR, and he was/is doing his viewing on a PC, not a TV, but the schedule browsing was nice and clean (just text and tables, no distracting graphics etc). > Have you looked at my scheduler? It still needs some glue around it > in terms of XMLTV data fed into it, etc. but the benefit is that it > works with repeated programming and preferece settings to resolve > conflicts. Yes, I'm eager to try this out. Right now my recording box is down until I get a new case and hard drive next week.. > Why X? You don't need it. Framebuffer works great, and DirectFB will > probably be even nicer for OSD etc. Well I tried framebuffer first but I had all kinds of problems with the i810 framebuffer driver. Granted that was several months ago so maybe things are different now. If I can get it working, you're right that DirectFB sure looks nice :-) > But if your scheduler knows which programs are repeats, or more > accurately which ones you have seen it won't record them again. My > scheduler has a database of "seen" programs. It does not update it > yet when it records a program however. I do that manually. Well yes, but in the "X-Files marathon" case there are a TON of X-Files episodes that I have in fact seen, but there is no way I'm going to manually enter 8 seasons worth of data into my PVR just so it won't won't record them again. (There's lots of stuff that I've seen in my lifetime that my PVR will have no clue that I've seen since it never recorded it.) > No. Specific timeslots is ugly. I don't want to have to reprogram > everytime they shift the program. Like last night, they decided to > move Survivor to Wednesday from Thursday. If I am not paying > attention and I program by timeslot rather just when something is on > that I have not seen before, I would have missed it. Agreed; I just didn't expect this feature as part of the "base functionality" I am trying to get to. I'd be thrilled to have it of course. :-) - Dave |
|
From: Brian J. M. <1a3...@in...> - 2002-03-14 18:51:11
|
> Is this the version of the scheduler that's on CVS as the .c file? Yes. > That's what I was thinking, until I sat down with a pen and paper and Vis= io > and started to map out the logic of scheduling. I think I might be > overcomplicating it a bit. My idea was to use 1 minute slots for each tu= ner. > Earlier, I was think that this would be a huge waste, but then I noticed= a > few things: 1) a two week pull of guide data using XMLTV was only a 4 m= eg > file. ~800MB if you gzip it. My scheduler uses gnome-xml, which can read gzippd xml files. > 2) 1440 slots per day per tuner * 14 days of guide data is still not > a huge amount (anymore, since we're talking PCs and even 64MB will give us > some elbow room) I'd watch that assumption. My scheduler will grow to 90-90MB of memory usage once the whole XMLTV file is slurped in. > What I don't like about the Tivo is it's insistance that if I put in a > 1-minute "slop" buffer at the end of a program, it's not going to record = the > program that comes after it. I have not used a "slop buffer". I have my machines synced to NTP on the Internet and have been quite surprised at how well timed scheduling is on TV. I don't think I have ever lost a program ending due to not having the slop buffer yet. > Yes, I was thinking of that as an option. I'm going to have to see if the > data is plaintext or if it's encoded in some way. Oh I would be much surprised if it's plain-text. It's a feature/service that Gemstar licenses to make money on. I have only seen it on a couple of brands of TV/VCR like RCA. If it were plain-text (free for all) I am sure every TV being made today would have it. > If you follow the Tivo and Replay model, then essentially they're always > recording on the off chance that 1) You want to pause live TV, or 2) You > want to save the buffer Yeah, I know. I am not doing this yet. I only record programming on demand. > I think that at a minimum we should make sure that there's good sync over= a > 2hour time period. That way you can watch movies. I have no reason to believe that mp1e will drift over 2, 3 or even more hours. There is no evidence of even a hint of drift with 1 hour programs. > I was also thinking about a "hints" file. For example, the Daily show is= on > 4 times a day, but only the one that comes on at 2300EST is the "premiere" > one. The ones that follow in the 24 hour period after that are re-shows.= =20 This is excellent! Repeating of programs is great for scheduling. It increases the odds that you will get everything you want. It is the other reason to only specify programs, not "when" to the scheduler. It will record all of the programs you want at their first opportunity (i.e. greedy), but if there is a conflict will record a repeat of a program when it is next on. > I've looked at the XMLTV data for TDS, and there doesn't appear to be any > coding of which episodes are repeats. Same thing for "Talk Soup", etc. That is what the "seen_programs" database is for. It keeps track of what you have seen (more likely what you have recorded -- what you have seen will depend on the gui keeping track of what you are watching) so that you don't record programs more than once. Right now you have to update seen_programs manually. I will add code to the scheduler to update it when it schedules something soon. Later when the gui for watching is functional, it will update seen_programs when something is watched. > The Tivo has the same problem with its guide data. The way I capture it = now > is to put in a manual recording for TDS that runs M-F, channel 42, 2200-2= 230. > Works great, except TDS doesn't run on Friday, so I need to go in manual= ly > and delete that recording so that I don't get "Comedy Blend". That is exactly the headache I want to avoid. When I first started this project I was just looking for Digital VCR capability (timeslot based recording) but the idea of recording programs instead of timeslots is far superiour. Of course, timeslot recording should still be available, but program recording should be the norm. > I think that the user should choose, and it doesn't have to be anything t= o do > with the categories that come in over the wire with XMLTV. Right. > Are you doing NFS, moving the file over, or something else? NFS. > The Replay 4000's uses straight-up HTTP, sending the file across in chunk= s.=20 > What do you think of this as a streaming method? Sounds good enough. HTTP is just a TCP stream after the handshake and file request. Wow, replay 4000 is just HTTP huh? Any idea what format the file is that it streams to you? Standard MPEG2? Sounds like that would be sweet for building a network of players out of Linux boxes. > Concur. That's why I said far future. Future or now, it doesn't change the privacy problems. > I didn't say all my ideas were good! It was not a bad idea. I am sure there are some people who would give up that privacy aspect to get that kind of information. > That's why I put it in the "Don't think it's important" column. :-) > I was looking at IR as well. Of course, in my visio schematic I have a > decision tree: "Do we need to blast IR?" to take care of external tuners. Yeah, I have thought very briefly about that. I have noise problems on my captures that I think would go away with an external tuner. > I > was looking at the various LIRC projects, and then StreamZap caught my eye > http://www.streamzap.com - the nice thing about the streamzap is that for > $40, you get a USB IR receiver, and a remote that sure looks an awful like > the Tivo peanut. No idea is the USB receiver is supported yet, and I did= n't > see streamzap listed on the LIRC page for remotes they know about. Check out irman: http://www.evation.com/irman/. US$35 and it works with any normal remote. I don't care to buy yet another remote. I want my "universal" to work my PVR as well. > Switched to rocketmail. Thanx! b. --=20 Brian J. Murrell |
|
From: Robert K. <rku...@ro...> - 2002-03-14 14:25:32
|
" > I read your description > of your idea of a brute-force versus optimized scheduler. Good > reading. And the result is very pleasing. I have been able to include much more conflicting programming in the new version of the scheduler than I could in the old version. " Is this the version of the scheduler that's on CVS as the .c file? " > For the scheduling algorithm, have you considered the case where they > may be multiple encoders available? It has occurred to me. It's not coded for right now but adding it should not be difficult. " That's what I was thinking, until I sat down with a pen and paper and Visio and started to map out the logic of scheduling. I think I might be overcomplicating it a bit. My idea was to use 1 minute slots for each tuner. Earlier, I was think that this would be a huge waste, but then I noticed a few things: 1) a two week pull of guide data using XMLTV was only a 4 meg file. 2) 1440 slots per day per tuner * 14 days of guide data is still not a huge amount (anymore, since we're talking PCs and even 64MB will give us some elbow room) I was thinking that each "slot" would simply hold a pointer to a ProgramID Record in the main XMLTV database. So when it comes to scheduling, you have the ability to see how "big" a program is. What I don't like about the Tivo is it's insistance that if I put in a 1-minute "slop" buffer at the end of a program, it's not going to record the program that comes after it. So, Survivor, 1900-2001CST means that "Program X" from 2000 to 2030 is going to get dropped. What if I'm willing to lose the 1 minute from the beginning of Program X? Too bad. " > 3) vbi - there are at least some TVs and VCRs that can obtain guide > data encoded in the video signal Do you mean Guide+? " Yes, I was thinking of that as an option. I'm going to have to see if the data is plaintext or if it's encoded in some way. There are a bunch of Zenith / RCA TV's that tout this feature, but when I googled all I found was complaints about how it sometimes works, sometimes doesn't. Seems to be more dependant on the users cable system and the quality of the signal they're getting. " > o Rock-solid A/V sync. If it can't maintain sync over a long period > of time it's going to be too annoying to use. Right. Recent versions of mp1e seem to be good. I don't usually watch stuff longer than an hour though so if there is drift beyond hour long programs, I wouldn't know. " If you follow the Tivo and Replay model, then essentially they're always recording on the off chance that 1) You want to pause live TV, or 2) You want to save the buffer I think that at a minimum we should make sure that there's good sync over a 2hour time period. That way you can watch movies. " > o Picking programs through the guide instead of manually. Manual > should still be available though. Picking for play or recording? " I was thinking for recording in this instance "Daily Show" vs "Channel 42, M-Th, 2200" like you would on a VCR. I was also thinking about a "hints" file. For example, the Daily show is on 4 times a day, but only the one that comes on at 2300EST is the "premiere" one. The ones that follow in the 24 hour period after that are re-shows. I've looked at the XMLTV data for TDS, and there doesn't appear to be any coding of which episodes are repeats. Same thing for "Talk Soup", etc. The Tivo has the same problem with its guide data. The way I capture it now is to put in a manual recording for TDS that runs M-F, channel 42, 2200-2230. Works great, except TDS doesn't run on Friday, so I need to go in manually and delete that recording so that I don't get "Comedy Blend". " > o Sorting saved programs into categories. Tivo doesn't do this very > well, so everything ends up in one long "What's playing". I don't > have a replay, but I understand that it does this better. Yeah, I have one long list right now. One problem is who catagorizes? What if you don't agree that a program is a drama and think of it more as a sitcom? Maybe when you choose to record it, you pick what catagory it should be filed in? " I think that the user should choose, and it doesn't have to be anything to do with the categories that come in over the wire with XMLTV. I was thinking "Bob's Stuff", "Sci Fi", etc. That way, if I can choose where my programs are going to show up instead of a long list of items that are all jumbled together. " I have separate boxes for my recording and playing. I have the PVR box with TV out and will have the remote, etc. for playback and my desktop workstation does the recording, just because that's the box with the most CPU in it. :-) " Are you doing NFS, moving the file over, or something else? " > o Sharing of programs internally. If you have a bunch of boxes / > tuners as opposed to a super-server, they should be able to share > programs that they've saved either through direct streaming or through > file sharing. Yes. Replay 4000 like. " The Replay 4000's uses straight-up HTTP, sending the file across in chunks. What do you think of this as a streaming method? " > o Adding hard drive space through the LVS. LVS? Do you mean LVM? All my boxes run with LVM. Using PeeCee partitions is just arcane. :-) " Yes, thinko on my part. " > Far future: > o Recommendations based on what others watch. "I see that you like > watching The Simpsons. 88% of viewers that watch The Simpsons also > watch "Farscape". Do you want to add Farscape to your recording > queue? Yeah, that would be neat. There are privacy issues with that. You need to "volunteer" what you watch to a body to coallate the data. I am not sure I want someobdy knowing all of my viewing habits. But I am a bit of a privacy zealot. " Concur. That's why I said far future. I didn't say all my ideas were good! " > o Sharing video over the internet. Like what Replay (Sonic Blue actually) are being sued over by the major networks? " That's why I put it in the "Don't think it's important" column. " I need IR. Once I get that and have a basic functioning system that everybody can use, I will look at more useful features. " I was looking at IR as well. Of course, in my visio schematic I have a decision tree: "Do we need to blast IR?" to take care of external tuners. I was looking at the various LIRC projects, and then StreamZap caught my eye http://www.streamzap.com - the nice thing about the streamzap is that for $40, you get a USB IR receiver, and a remote that sure looks an awful like the Tivo peanut. No idea is the USB receiver is supported yet, and I didn't see streamzap listed on the LIRC page for remotes they know about. " > Note: The information contained in this message may be privileged <etc> Is there any way for you to get rid of this disclaimer? " Nope - corporate puts it into every email message. Thanks, MS Exchange! Switched to rocketmail. __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ |
|
From: Brian J. M. <cc9...@in...> - 2002-03-14 11:25:46
|
On Wed, Mar 13, 2002 at 11:13:07PM -0600, Dave Caplinger wrote:
> Greetings, I'm a lurker on this list but since some discussion has=20
> popped up I thought I'd chime in as well. While I agree with a lot of=20
> the long-term vision stuff, I'm just trying to get basic functionality=20
> first :-)
I hear ya dude. Usable first, pretty second.
> Capture hardware: Pinnacle Studio Pro PCI (bttv driver)
Why that one? Cheap?
> Capture software: NuppleVideo (not the best compression, but the a/v=20
> sync is good, unlike others I've messed with so far)
CVS versions of mp1e are good. NVrec has great a/v sync for divx,
div4, ffmpeg codecs.
> Show selection & record scheduling: XMLTV's tv_grep, bash, and cron=20
> today, but I have hopes that cheematv's code will be available for this
^^^^^^^^
What is this?
Have you looked at my scheduler? It still needs some glue around it
in terms of XMLTV data fed into it, etc. but the benefit is that it
works with repeated programming and preferece settings to resolve
conflicts.
> Playback selection via TV interface: unknown at this point; maybe a=20
> browser-based thing using really big fonts on top of X (with no real=20
> window management to speak of, just one app that takes over the whole X=
=20
> "dekstop")
Why X? You don't need it. Framebuffer works great, and DirectFB will
probably be even nicer for OSD etc.
> Remote control: LIRC with the remote that came with my Pinnacle card.
I have been fighting with a Zoltrix capture card that has a remote on
it but no luck.
> I have a feeling that disk space management is going to have to play a=20
> major role in the ultimate user interface to this project; not just so a=
=20
> user can always know whether there is enough room on the hard drive to=20
> store the show they just asked to record, but especially once the system=
=20
> starts recording shows on it's own.
Disk space management is an issue yes.
> Exlicitly user-specified recordings=20
> are going to have to be of a higher priority (in terms of getting access=
=20
> to the remaining disk space) than speculative recording that the system=
=20
> does on it's own (you sure don't want to miss your "regular" shows=20
> because FX decided to run a two-day marathon of X-Files and filled your=
=20
> hard drive).
But if your scheduler knows which programs are repeats, or more
accurately which ones you have seen it won't record them again. My
scheduler has a database of "seen" programs. It does not update it
yet when it records a program however. I do that manually.
> In any case, I'd be happy at this point if I could just get a system to=
=20
> regularly download listings and always record my short list of specific=
=20
> shows in specific timeslots
No. Specific timeslots is ugly. I don't want to have to reprogram
everytime they shift the program. Like last night, they decided to
move Survivor to Wednesday from Thursday. If I am not paying
attention and I program by timeslot rather just when something is on
that I have not seen before, I would have missed it.
> PS - I really like the idea of having a distributed farm of PVR=20
> devices... if my PVR is busy recording at a specific time and I need to=
=20
> record two shows at the same time, It would be fantastic to borrow time=
=20
> on my neighbor's PVR to record my show if his is free during that=20
> timeslot. (Naturally, I'd be happy to share mine with him as well under=
=20
> the same circumstances.) Would that technically be illegal, though?=20
Well, that is what Sonic Blue is being sued over so I guess we will
know soon enough. :-)
> While I know it happens all the time, is loaning your VHS recording of a=
=20
> TV show to a friend because he forgot to record it himself (probably=20
> because HIS kids watched a tape and forgot to set the VCR back up to=20
> record) actually technically illegal?
The TV networks say yes.
b.
--=20
Brian J. Murrell
|
|
From: Brian J. M. <fd7...@in...> - 2002-03-14 10:55:35
|
On Wed, Mar 13, 2002 at 10:00:26AM -0500, Kulagowski, Robert wrote:
> It's good to see that progress is being made.
Indeed.
> I read your description
> of your idea of a brute-force versus optimized scheduler. Good
> reading.
And the result is very pleasing. I have been able to include much
more conflicting programming in the new version of the scheduler than
I could in the old version.
> If you have the time, can you detail what parts and pieces you are
> considering at this point? Which encoder and encoder technology are
> you going with?
Encoding: definately MPEG(1 for the moment). AVI files are unseekable
unseekable until they are closed (i.e. the capture is
finished). I don't know if there are any good MPEG2
encoders yet -- any that compare to MPEG1 with mp1e, which
brings me to the encoder software I am using.
I am using mp1e, but a recent cvs version from RTE, not the
1.9.2 release. Unfortunately, recent cvs versions are not
working. I have an older CVS version that I am quite
pleased with. mp1e used to have A/V sync problems for me
but it seems to have cleared up.
I would probably perfer to use RTErec from the NVrec package
because Justin's A/V sync is excellent, but RTE is very much
in flux right now and the API has changed and Justin won't
update NVrec until an official RTE release.
Ooooo! Just checked and looks like mp1e is back in order
again. I will build it and test it later today.
mp1e is by far and away the most CPU friendly encoder.
Perhaps the quality of the MPEG file is worse than other
encoders at the same bitrate, but I find mp1e at 5Mb/s is
quite nice. I can even re-encode that to Divx using a 2
pass encoder (I use mencoder) at 1250Mb/s and only see the
difference with very fast moving scenes. I don't watch auto
racing so it's not a big deal for me. :-)
=20
> For the scheduling algorithm, have you considered the case where they
> may be multiple encoders available?
It has occurred to me. It's not coded for right now but adding it
should not be difficult.
> Have you made any consideration of obtaining guide data?
XMLTV.
> Right now
> I'm aware of at least three ways of obtaining guide data:
>=20
> 1) xmltv from sourceforge
> 2) tvlisting at cherrynebula.net
Haven't seen that one. Just checked out the site. Somebody ought to
get that guy over to XMLTV and then get_tv_na could have options on
where to get data from.
> 3) vbi - there are at least some TVs and VCRs that can obtain guide
> data encoded in the video signal
Do you mean Guide+? My mom's TV has an OSD TV guide which is
downloaded over the cable connection. That would be sweet because I
can see the web-based outfits shutting down the "scrapers" due to them
bypassing the ad revenue. But my guess is that the Guide+ data is
proprietary.
Is it really transferred over vbi or some other means? I know some
versions of ATI capture cards come with some Guide+ software, but some
googling seems to indicate in that case, the data is downloaded over
the Internet.
I also wonder if enough data is available with Guide+. The more data
you can feed to the scheduler (I use a running two week window) the
better it will be at resolving conflicts with repated programming.
> o Rock-solid A/V sync. If it can't maintain sync over a long period
> of time it's going to be too annoying to use.
Right. Recent versions of mp1e seem to be good. I don't usually
watch stuff longer than an hour though so if there is drift beyond
hour long programs, I wouldn't know.
> o Set-top / black-box functionality. The wife doesn't want to know
> anything about linux. Needs to connect to a standard TV and look
> decent.
Yup. Got that/working on that. I am using a G400 with a TV hooked to
the 2nd head. I am working on a GUI program "chooser". My first
rough cut at it (a GTK clist with filenames in it) is functional,
although with a mouse, not an IR remote yet.
> o Tivo and Replay-like "trick play". Pausing live TV, FF, RW, etc.
> The PowerVCR II program from CyberLink can do this already using
> MPEG-1 on Windows.
I do that. I use mplayer to play. As long as you are playing MPEG
files, you can FF/REW/Pause the same file you are encoding to.
> o Picking programs through the guide instead of manually. Manual
> should still be available though.
Picking for play or recording?
> o Sorting saved programs into categories. Tivo doesn't do this very
> well, so everything ends up in one long "What's playing". I don't
> have a replay, but I understand that it does this better.
Yeah, I have one long list right now. One problem is who catagorizes?
What if you don't agree that a program is a drama and think of it more
as a sitcom? Maybe when you choose to record it, you pick what
catagory it should be filed in?
> o Multiple tuner support, as long as there's sufficient CPU.
Yes.
> Things that I consider in the future:
> o Seperating capture and display functionality, so that a "super
> server" can sit in a basement near all the coax and a display box can
> be lightweight, diskless/fanless (quiet) in the family room.
I have separate boxes for my recording and playing. I have the PVR
box with TV out and will have the remote, etc. for playback and my
desktop workstation does the recording, just because that's the box
with the most CPU in it. :-)
> o Sharing of programs internally. If you have a bunch of boxes /
> tuners as opposed to a super-server, they should be able to share
> programs that they've saved either through direct streaming or through
> file sharing.
Yes. Replay 4000 like.
> o Conflict resolution amongst numerous boxes. If I need to record
> multiple programs, and there's no tuner available on the box that I'm
> on, then hand off the job to another recorder.
Well, that's just an abstraction of the "multiple tuner" paradigm, but
instead of a second job on the same machine, it's a job on a second
machine.
> o Adding hard drive space through the LVS.
LVS? Do you mean LVM? All my boxes run with LVM. Using PeeCee
partitions is just arcane. :-)
> Far future:
> o Recommendations based on what others watch. "I see that you like
> watching The Simpsons. 88% of viewers that watch The Simpsons also
> watch "Farscape". Do you want to add Farscape to your recording
> queue?
Yeah, that would be neat. There are privacy issues with that. You
need to "volunteer" what you watch to a body to coallate the data. I
am not sure I want someobdy knowing all of my viewing habits. But I
am a bit of a privacy zealot.
> o Sharing video over the internet.
Like what Replay (Sonic Blue actually) are being sued over by the
major networks?
> Of course, being an "Idea guy" is easy. The hard part is
> implementing!
Yes. And finding the time to implement. Testing and evaluating has
chewed up a huge chunk of my time. I am at the integrating stage now.
I need IR. Once I get that and have a basic functioning system that
everybody can use, I will look at more useful features.
> Note: The information contained in this message may be privileged and
> confidential and protected from disclosure. If the reader of this
> message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient, you
> are hereby notified that any dissemination, distribution or copying of
> this communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> the message and deleting it from your computer. Thank you. ThruPoint,
> Inc.
Is there any way for you to get rid of this disclaimer? It gives me
the heebie-jeebies with all that "distribution or copying of this
communication is strictly prohibited" garbage. You are participating
on a mailing list which by it's very nature, copies and distributes
your message to "unnamed recipients" who could easily be construed as
"unintended" recipients.
Thanx,
b.
--=20
Brian J. Murrell
|
|
From: Dave C. <de...@co...> - 2002-03-14 05:10:21
|
Greetings, I'm a lurker on this list but since some discussion has popped up I thought I'd chime in as well. While I agree with a lot of the long-term vision stuff, I'm just trying to get basic functionality first :-) For example, so far my hopes are pinned on the following components: Capture hardware: Pinnacle Studio Pro PCI (bttv driver) Capture software: NuppleVideo (not the best compression, but the a/v sync is good, unlike others I've messed with so far) Listings grabbings: XMLTV's tv_grab_na Show selection & record scheduling: XMLTV's tv_grep, bash, and cron today, but I have hopes that cheematv's code will be available for this Playback software: mplayer (this deals with FF and RW, but I honestly don't need "pause live TV" in the base functionality.) So far, I'm having strange colorspace mismatches between nuvrec and mplayer, however... Playback hardware: a "book PC" i810-based system with TV-out (a play-only system that will live in my entertainment center, while the recording server lives in the basement... I didn't really want client-server, but the Book PC has no PCI slots and thus can't record!!) Playback selection via TV interface: unknown at this point; maybe a browser-based thing using really big fonts on top of X (with no real window management to speak of, just one app that takes over the whole X "dekstop") The "VDR" project has a cool front end, but I haven't looked at extracting it from the DVB-based capture software it's built for. Remote control: LIRC with the remote that came with my Pinnacle card. All of that is required to just get me the basic functionality to emulate a VCR (record only what I specifically tell it to, and then let me view it again later). Later on, obviously, there are plenty of other things to add (many of which have been mentioned) such as "burn this show to a VCD," "keep track of show episodes that I've seen and record unseen ones even if I didn't tell you to," etc. I have a feeling that disk space management is going to have to play a major role in the ultimate user interface to this project; not just so a user can always know whether there is enough room on the hard drive to store the show they just asked to record, but especially once the system starts recording shows on it's own. Exlicitly user-specified recordings are going to have to be of a higher priority (in terms of getting access to the remaining disk space) than speculative recording that the system does on it's own (you sure don't want to miss your "regular" shows because FX decided to run a two-day marathon of X-Files and filled your hard drive). And maybe the "shows I think you might like" kind of speculative recording needs to be at an even lower priority. Assuming that different recording qualities work without sacrificing a/v sync (which naturally implies different disk space requirements), maybe the more speculative recording could be done at a lower quality/disk-requirement setting to help minimize the loss of space for explicit user-specified recording. (Obviously, being able to burn shows to VCD plays a role in disk space management as well, since it gets them off the hard drive without losing them forever. Being able to do this may require some amount of scratch space to be set aside however, so you're never in a position that the hard disk is too full for the system to build a CD image to burn, so therefore you can't free up disk space without losing data.) In any case, I'd be happy at this point if I could just get a system to regularly download listings and always record my short list of specific shows in specific timeslots regardless of whether my kids watched a VHS tape that day and everyone forgot to press "timer rec" when they were done. :-) PS - I really like the idea of having a distributed farm of PVR devices... if my PVR is busy recording at a specific time and I need to record two shows at the same time, It would be fantastic to borrow time on my neighbor's PVR to record my show if his is free during that timeslot. (Naturally, I'd be happy to share mine with him as well under the same circumstances.) Would that technically be illegal, though? While I know it happens all the time, is loaning your VHS recording of a TV show to a friend because he forgot to record it himself (probably because HIS kids watched a tape and forgot to set the VCR back up to record) actually technically illegal? Some other "far future" things I'd like to do are more inline with Internet-on-TV types of functions. For example, weather-on-demand (rather than waiting for The Weather Channel to get around to showing me my forcast) and local movie schedules on demand (with trailers of course). I don't really want to browse the Internet in general from my TV, but those two "data lookup" applications seem to be a good fit for TV display. - Dave |
|
From: Kulagowski, R. <RKu...@Th...> - 2002-03-13 14:58:36
|
It's good to see that progress is being made. I read your description of your idea of a brute-force versus optimized scheduler. Good reading. If you have the time, can you detail what parts and pieces you are considering at this point? Which encoder and encoder technology are you going with? For the scheduling algorithm, have you considered the case where they may be multiple encoders available? Have you made any consideration of obtaining guide data? Right now I'm aware of at least three ways of obtaining guide data: 1) xmltv from sourceforge 2) tvlisting at cherrynebula.net 3) vbi - there are at least some TVs and VCRs that can obtain guide data encoded in the video signal When I was thinking about all the things that I think would be baseline, I thought of these in the following order: o Rock-solid A/V sync. If it can't maintain sync over a long period of time it's going to be too annoying to use. o Set-top / black-box functionality. The wife doesn't want to know anything about linux. Needs to connect to a standard TV and look decent. o Tivo and Replay-like "trick play". Pausing live TV, FF, RW, etc. The PowerVCR II program from CyberLink can do this already using MPEG-1 on Windows. o Picking programs through the guide instead of manually. Manual should still be available though. o Sorting saved programs into categories. Tivo doesn't do this very well, so everything ends up in one long "What's playing". I don't have a replay, but I understand that it does this better. o Multiple tuner support, as long as there's sufficient CPU. Things that I consider in the future: o Seperating capture and display functionality, so that a "super server" can sit in a basement near all the coax and a display box can be lightweight, diskless/fanless (quiet) in the family room. o Sharing of programs internally. If you have a bunch of boxes / tuners as opposed to a super-server, they should be able to share programs that they've saved either through direct streaming or through file sharing. o Conflict resolution amongst numerous boxes. If I need to record multiple programs, and there's no tuner available on the box that I'm on, then hand off the job to another recorder. o Adding hard drive space through the LVS. Far future: o Recommendations based on what others watch. "I see that you like watching The Simpsons. 88% of viewers that watch The Simpsons also watch "Farscape". Do you want to add Farscape to your recording queue? o Expandable storage without shutdown / reboot. I'm thinking of Firewire hard drives that can be chained. Things that I don't consider important: o Totally integrated functionality, like what's being done by ShowShifter on the PC. If I want to play a CD, I'd use my CD player. Same thing for DVDs, etc. o Sharing video over the internet. Of course, being an "Idea guy" is easy. The hard part is implementing! Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ThruPoint, Inc. |
|
From: Brian J. M. <14f...@in...> - 2002-03-13 05:30:11
|
On Tue, Mar 12, 2002 at 06:20:52PM -0500, Robert Kulagowski wrote: > Just curious. I've been catching up on the v4l mail group and > saw the announcement. Doesn't seem to be much activity on the > list though. Nope, I have been busy. Between helping with the baby here and figuring out just what the right solution of hardware and software for a PVR is and writing some code for it. I think my new scheduler is done. Well it needs cleaning up as it still has copious amounts of debug output but it is much more efficient that it's predecessor. I can put lots of syndicated programming into it and it produces a achedule in decent time. I am pretty much zeroed in on my capture hardware and software, as well as output-to-tv hardware. I am still trying to find just the right settings for framebuffer output for NTSC TV. I have started on an OSD for choosing programs to watch. Right now it's just a list of programs on the screen and choosing one, it plays. I have also been playing with a Zoltrix TV Genie capture card with IR remote. The card sorta works with bttv (some channels don't tune) and the IR is not as of yet supported. I need to get it proved (used hardware, who knows if it even works) in windows before I start trying to make LIRC work with it and that has been a trial. I think the card is junk actually. I think I will start to look a different LIRC option -- one that hopefully does not mean my having to build hardware. That is where I am right now. Anything in particular you wanted to discuss? b. --=20 Brian J. Murrell |
|
From: Robert K. <rku...@th...> - 2002-03-12 23:18:28
|
Just curious. I've been catching up on the v4l mail group and saw the announcement. Doesn't seem to be much activity on the list though. |
|
From: James O. <jf...@fu...> - 2002-01-18 04:55:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After a lot of thinking and a lot of playing around with various things I think I can better propose an overall architecture. I encourage anybody to critcise, flame, or what have you. Discussion is a good thing. OpenPVR Daemon: This basically allows anything to talk to anything and handles scheduling. In more detail: - - API: A single interface to pretty much anything available in the daemon itself and in the other components (acting as a proxy). This API can be accessed programmatically, from the command-line, and through a web interface. Think a cross between 'xawtv-remote' and KDE2's 'dcop' command. I recommend reading http://developer.kde.org/documentation/tutorials/automation/index.html (scroll down to the 'DCOP Interfaces' heading to see it in action) - - Events: Anything executed on or in the daemon will generate an event to which you can attach other API calls. This can be used to easily define behaviour. Here's a theoretical example: "A 'change channel' event is created and set to occur whenever 'tv.channelup', 'tv.channeldown', or 'tv.channelset' are executed. The event is also set to execute 'osd.displaycurrentprogram' so that the current program information is displayed." - - Preferences: These can be stored in a database and may be read or set through the API. These preferences may include: program scores (good, bad, okay, kinda cool, if there's nothing else on), topic scores, genre scores, channel scores, desired recording quality, or anything else - - Scheduling: Any internal or external process can be scheduled. This is most important for recording shows, changing channels, or downloading program data. These schedules can be set by events or directly through the API (from an on-screen or web-based interface) I've been playing with a few ways to create this and it looks like the Twisted Framework at http://twistedmatrix.com/ is my favourite at this point because it's easy to develop with, can be modified on the fly, and automatically saves it's state upon exit. The state saving is perfect for something like this. It's quite reminiscent of the factory machine design I used to do in a previous life as an embedded developer. I should note that my use of Python here is for prototyping. Changes can be quickly made and the architecture can be thought through fully before porting to something like C (boo) or C++ (yay). Of course, if it works adequately enough for everyone, it can stay in it's prototype form... Media Player Daemon: This is basically a wrapper for your favourite media player so that the main daemon can play anything at any time (at the user's request, of course). I created a program that runs continuously and wraps Mplayer. After *a lot* of screwing around, I've found that control should be done through a 'fake' LIRC daemon. You can use X events, but they don't work on the framebuffer. Of course, Mplayer could be it's own daemon in the future, but this works for now. I haven't played with GStreamer yet as I have to upgrade to ALSA 0.9, which means I'll have to recompile a ton of other software. I'm not exactly looking forward to that as I'm a total RPM fiend and that's a *lot* of RPMs: rpm -q --whatrequires libasound.so.1 | wc -l 79 That includes KDE, which takes a day or two to compile/package... - From what I see, GStreamer is most likely a *much* better fit for this project, though. I think I'll set it all up this weekend. LIRC (remote control interface): It's probably best to let lircd send remote control events to the OpenPVR daemon which can process them appropriately (thumbs up/thumbs down, for example) and proxy them to applications that already support LIRC such as Mplayer. This requires some minor hacking of lircd but can save the hacking of individual applications later. This we only have to do once. This is what I've been playing with tonight. I'm thinking of creating a fake remote control driver. The interface seems simple enough. (famous last words) V4L: A thin wrapper for v4lctl, in the main daemon. See 'man v4lctl' for more details. Recorder: This is pretty straight forward. Set the channel via V4L and record it. For each program recorded, a corresponding XML metadata file is created containing the XMLTV data. OSD: The on screen stuff is probably the hardest part, but it looks like GStreamer can do a lot of the heavy lifting (overlaying onto live video). What we want the OSD to display: - - Program/channel info - - User interface, widgets and all - - Setup/preferences Of course, it'll have to be themeable. That's all I can think of right now, as it's late and I have to get to bed at some point. Do remember that this is up for discussion and is in *no way* set in stone. If you think I'm on crack, then by all means, tell me. - -- James Oakley jf...@fu... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8R6sOKtn0F7+/lLMRAiKmAJ4kKhdyNze2+Y2VqEDXpAeLSjFFsgCdGp7g sRVpAIhJqpKJT0Ls1hgsdzU= =j/F2 -----END PGP SIGNATURE----- |
|
From: Brian J. M. <317...@in...> - 2002-01-17 05:52:36
|
Hello folks, Let me first appologize for the length of this message. It is messages this long on most other lists that hit 'D' when starting to read. I hope I can be (much!) more brief in the future, but I felt that the issue at heart in this message required some background. If you want to just get to the heart of this issue and decide from there if you want to go back and read the background, skip down to paragraph 9 Sorry about the lack of progress here on OpenPVR but the last month or two has been quite event filled. Of course there were the holidays, which when you are single are a great time to catch up on some hacking, but when you have a family it has exactly the opposite effect. That leads me to the other thing that has been occupying my time since starting OpenPVR. At the beginning of Dec, my son was born and that event had and continues to still occupy a lot of my time. I am fitting in stuff where I can though. I don't know how many of you have looked at the program recording scheduling prototype that I wrote and is in CVS right now, so I will give a brief overview of what it does. It's goal is to simply record as much programming as you are interested in seeing based on program names (i.e. "ER", or "Survivor: Africa", etc.). In order to meet that goal the scheduler uses the XMLTV project to get a two week schedule of programming. Using that programming information, the scheduler tries to search out your programs, when they are on and if they are repeated. This latter item is used to try to schedule as much programming as possible. For instance, if program A is on in timeslot 1 and so is program B, but program A is also shown in timeslot 2, program B will be recorded in timeslot 1 and program A will be recorded in timeslot 2. To determine the best schedule to record as much as possible, I simply try out every combination of programming until I get the schedule that records the most episodes for the two weeks. This is a brute-force search. The mathematics of it are of course exponential. If you have two programs you want to record and each of those two programs is repeated twice, you have to try 4 different scheduling combinations in order to determine which one is best. The numbers of schedules gets very high very fast when you include heavily syndicated programs like "Frasier", and "Friends" (and here in Canada, "Law & Order" and "All in the Family" the latter of which is shown 6 times a day -- 2 episodes back to back, 3 times a day). So I have been thinking about how to reduce the numbers of schedules that need to be "brute-force" searched. I thought, if I can identify programming that will neither cause a conflict or help resolve one (i.e. a program that is repeated during the scheduling cycle but never on at the same time as something else), I can schedule that and remove it from the brute-force scheduling algorithm. That could have dramatic effects at reducing the number of scheduling combinations that needs to be brute-force searched. So in application of this thought, I decided that a list of everything I want to record, sorted by showing time and traversed from beginning to end should identify conflicts (adjacent items whose start time + duration overlap with each other, as well as programs that do not conflict. I can then put the conflicts in one schedule to be searched further and the non-conflicting (easy ones) programs into the recording schedule. But then it occurred to me, do I even have to brute force search for the best possible conflict resolution? What if given the above sorted list of programs, I just schedule everything that does not have a conflict (removing repeated programming from the list as I schedule the earliest showing of it) and then treat conflicting programs in the following manner, assuming the programs that are conflicting (showing in overlapping time windows) are "A" and "B": 1. if either "A" or "B" is repeated, defer scheduling the one that repeats and record the other 2. if neither repeat, use a scoring mechanism to choose the one to record - if the scores are equal, choose one randomly 3. if they both repeat... what? In the case of #1, the repeated program will continue to be deferred until it becomes case #2, or it can be recorded without conflict. This seems like a good scenario. Deferring repeated programming in favour of non-repeated programming is good. In the case of 2, hopefully the user has set up scoring of his programs to be sure that he gets the one he wants. Perhaps some kind of "schedule review" could be set up to show him what he will be missing because of the conflicts and his scoring on his wanted programming. He should be allowed to adjust scores to get the schedule to record what he wants most and sacrifices what he wants least. I think case #3 is what my current "brute-force" search is supposed to work ideally with. If both "A" and "B" repeat, then when choosing which one to record first and which one to defer, one has to look at all of the conflicts to decide if deferring either "A" or "B" helps out in resolving other conflicts and which to defer to help reduce further conflicts to their minimum. Either choice can have (deep) ripple and/or circular effects on further conflict resolution. I see no other way (as good anyway) to resolve the real conflicts than to brute-force search for the best combination of recording. Or am I missing something much more simple here? b. -- Brian J. Murrell |
|
From: Pete W. <hfw...@ya...> - 2001-12-17 15:31:51
|
I found the OpenPVR project and am definitely interested. I have been talking about "building my own TiVo" for about a year now and everyone keeps telling me I am nuts since it would cost 10x more than just buying a TiVo. But I don't think it is about money, it is about the technology. All the technology is there today to build a PC that does all the PVR functionality plus a whole lot more. So what are you trying to accomplish? Pete __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com |
|
From: Brian J. M. <16f...@in...> - 2001-12-09 03:45:42
|
On Sat, Dec 08, 2001 at 11:17:37PM -0400, James Oakley wrote:
> I've placed two files in CVS, xmltv.py and xmltvquery.py.
Cool.
> xmltv.py is basically a Python implementation of XMLTV.pm.
Okie.
> If you type 'python xmltvquery.py' the test will be run.
I am mostly python illiterate. I get:
$ python xmltvquery.py
Traceback (most recent call last):
File "xmltvquery.py", line 20, in ?
import xmltv
File "xmltv.py", line 26, in ?
from xml.utils import qp_xml
ImportError: No module named utils
b.
--
Brian J. Murrell
|
|
From: James O. <jf...@fu...> - 2001-12-09 03:16:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've placed two files in CVS, xmltv.py and xmltvquery.py. xmltv.py is basically a Python implementation of XMLTV.pm. xmltvquery.py is a query API that I wrote today. The most popular searches are currently covered and there are some examples at the bottom, doubling as a test. If you type 'python xmltvquery.py' the test will be run. I think my next step is to create the daemon and the event framework. Comments? - -- James Oakley jf...@fu... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8EtfRKtn0F7+/lLMRAs9QAKDD3mPkQRRybUEDPXHUIKN6ShO1EACg1rNx WE2A4AtHFT+9ABA1CvdgfQQ= =+q0k -----END PGP SIGNATURE----- |
|
From: James O. <jf...@fu...> - 2001-12-04 01:47:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On December 3, 2001 04:38 pm, Brian J. Murrell wrote: > I had a short discussion with somebody in which he pointed out that > buying a Tivo is probably cheaper than buying enough "peecee" hardware > to do the same job. He is probably right if you consider what is in a > Tivo. He'd be right. I almost bought a Tivo a number of times, but I'd rather be part of an effort to design an open one that can do stuff that Tivos can't. This is the point of open source to me. Price has nothing to do with it. > Notice that this includes both MPEG2 encoder and decoders! That stuff *can* get expensive. Ever price a good video-in card? I used to work for a vision systems company and had a Matrox Meteor in my desktop. CDN$905 and that's the cheap stuff. Tivo, the company, make their money on the subscriptions, not the hardware. They could never affor to sell just hardware at their dirt-cheap prices. > Openness. Wouldn't you like to be able to take what your PVR records > and play it wherever you wish not just on your PVR? Want to add > features to your PVR? I said the same thing in another message. The streaming capabilities alone are enough to attract people. > I wonder what the feasibility of using the Tivo hardware platform for > an OpenPVR would be? It certainly would require some device driver > writing. I do recall somebody told me once that Tivo have posted the > source to their kernel changes. I doubt that includes device drivers > for thinks like the MPEG2 encoder and decoder chips or hardware > scaling chip, etc. If somebody wants to do this, I can't stop them. However, Tivo loses money on hardware sales so I will frown on it. Jeremy Allison et al. figured out the Tivo schedule format but didn't release it. Tivo worked hard building what they did *and* played by our rules. Let's not turn around and stab them in the back. - -- James Oakley jf...@fu... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8DCuUKtn0F7+/lLMRAujaAJsFdXo82+IkDN7oEt6lJ+AxfNeEQgCgq0Xv gP4y7Hi1oeXKblhT9rgbVj0= =aHly -----END PGP SIGNATURE----- |
|
From: James O. <jf...@fu...> - 2001-12-04 01:25:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On November 30, 2001 08:58 am, Edward Avis wrote: > >Excellent. I feel much better knowing that we're in agreement here, and > >I think that any XMLTV-based program will generate more interest if > >there are compatible APIs in multiple languages. > > Well at present XMLTV.pm is just an interface for Perl, obviously. If > there's serious interest in a similar API for other languages then I > might rewrite most of it in C or C++ so it will be possible to interface > to it easily. The reason I like XMLRPC and SOAP so much is because you can make an API in one language and use it seamlessly in any other. You can even access one using only bash with telnet, cat, and wc. Check out the last section of this page: http://developer.kde.org/documentation/kde2arch/xmlrpc.html That said, I'm sure that if you made a simple document outlining the functions, then many compatible language interfaces will just show up. I'll be making a Python one anyway (not that I'm adverse to Perl, of course). I don't want OpenPVR to be tied to any language. I'm thinking of doing both an xmltv.pm compatible interface through XMLRPC, possibly allowing a Meerkat-style section. > I don't disagree that such a function is useful. But I think that it > should be written like this: (Perl syntax) > > my @results; > foreach (@programmes) { > if (XMLTV->matches($_, show => 'Simpsons') > or XMLTV->matches($_, time => '17:00:00') { > push @results, $_; > } > } > return @results; > > In other words the matches() routine is the important one, it just tests > an individual programme. Finding a list of programmes is done in the > stupidest possible way by going through all of them and testing each > one. Any more sophisticated technique (such as keeping the > programmes in sorted order and doing a binary search, or maintaining a > separate index of keywords) is not needed given the relatively small > size of the data. Aha! Now it makes perfect sense. It makes creating high-level functions easier. Sounds good to me. > >Locally, yes, but remotely, it depends on the XMLRPC or SOAP > >implementation. It's also neat to be able to browse the API and > >execute methods in a web browser. > > Er, okay, but it's still not something that belongs in XMLTV. If you > want to write a standard for doing introspection over XMLRPC or SOAP, > fair enough. And then the code you write might conform to that > standard. But I don't want things like system.listMethods() being > defined as part of the XMLTV project. Oh, I guess I should have pointed out my intentions at first. I was talking about an interface for OpenPVR/PyTV and I CC'ed you guys to see: 1) Am I on crack or what? 2) Are you guys planning anything that hasn't been implemented yet? > (If it is only your code that implements this listMethods() > functionality, then what is the point of it? Anyone who knows that > listMethods() is available will also know about the other routines you > have documented. An introspection system is useful only if you can get > widespread use of it. So good luck with that, but it's not related to > television listings per se.) Yeah, it's part of the XMLRPC spec, but is not implemented automatically in all of the libraries (including the one I use) so I have to do it myself, which is ridiculously easy to do anyway. Most scripting languages have great introspection abilities. > >This is entirely for daemons, and would be a separate library. It would > >be cool if Jabber could pop up a minute before your favourite show > >comes on. The record event is only useful for a PVR (mp1e is a video > >recorder). > > That description makes sense, although I still don't get the 'event' API > you are defining above. Ah, basically, I would be able to make an XMLRPC call that tells the daemon to do something like: - - "when the recorder has finished recording a show, tell the GUI using this function" - - "when the GUI says 'channel_up' call 'v4lctl setchannel next'" (yes, that command works as expected, on any TV card) - - "at 5:00 PM start the recorder on channel 53" Basically, you could define all functionality this way and even set/change it on the fly (via the GUI, for example). This is basically the same as Qt's signal/slot mechanism. It makes stuff really easy to write. The main difference here is that the senders and receivers are programs (or wrappers) instead of objects. Yes, I'm using XMLRPC as an IPC mechanism, but that gives us the ability to distribute the load across multiple computers: you can watch stuff on another computer using streaming video. Try getting your Tivo to do *that* Thanks, - -- James Oakley jf...@fu... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8DCYyKtn0F7+/lLMRAozGAKClEG0As2BogLnSUXL7Duri/pY30QCdEI2u 0SKKuPxchbK7GbXRJ6I1d1U= =DacF -----END PGP SIGNATURE----- |
|
From: Brian J. M. <3d8...@in...> - 2001-12-03 20:38:26
|
I had a short discussion with somebody in which he pointed out that buying a Tivo is probably cheaper than buying enough "peecee" hardware to do the same job. He is probably right if you consider what is in a Tivo. Here are some pictures inside a Tivo and there is a hardware inventory at the end to the detail of what chips are on their mainboard: http://www.9thtee.com/insidetivo.htm Notice that this includes both MPEG2 encoder and decoders! It might be that an actual Tivo is _the_ right piece of hardware to build an OpenPvr on. But why would I want to change the software on a Tivo if I already own one? Openness. Wouldn't you like to be able to take what your PVR records and play it wherever you wish not just on your PVR? Want to add features to your PVR? I wonder what the feasibility of using the Tivo hardware platform for an OpenPVR would be? It certainly would require some device driver writing. I do recall somebody told me once that Tivo have posted the source to their kernel changes. I doubt that includes device drivers for thinks like the MPEG2 encoder and decoder chips or hardware scaling chip, etc. Here is another link I found on hacking Tivos although it is dealing with hacking them within the boundaries of it's native software. Adding more space for instance. http://tivohack.sourceforge.net/otherdownloads.php3 b. -- Brian J. Murrell |
|
From: Brian J. M. <8b2...@in...> - 2001-12-01 04:18:28
|
On Fri, Nov 30, 2001 at 05:45:44PM -0500, Gregory Gee wrote: > > I'm not sure if this is too early to ask, but what would be the system requirements? Well, I think some consensus might help us draw up some guidelines. I have an AMD (Thunderbird) Athlon 800Mhz. I write over NFS to the server. > How much power would I need just to record? Depends much on what you use to record. > Just for recording, > with mp1e, what have people seen. I love mp1e. I just wish the a/v sync issues were worked out. With mp1e, 29.97 fps, 320x240, 1800kbp/s barely blips my CPU according to the little Gnome taskbar monitor. :-) Seriously, I am recording right now and it seems to be about 10-20% with some spikes but I don't know they are mp1e. Oh I am also playing back at the same time. Time shifting as it has been coined. > I have a K6-233 and a P2-233 available as a server. Those might work. I would be interested in what you find with them. I have a K6-300 I might want to have doing recording with mp1e. I will encode to Divx offline, niced down real low. > Will > either of these do? Give them a try and let us know. > My desktop is more powerful, but I don't want to use my desktop as a > server. My workstation is way more powerful than my server, which is why I use my workstation to record. I may splurge for dedicated hardware at some point but my workstation does a good job. > I don't plan on using the server for playback to the TV. Simultaneous recording and playback on a 200-300 Mhz processor might be pushing it. But please do try it. > Also, what about didk performance. Well, at 1800kbp/s, disk is almost a non-issue. > Would 2 drives in raid-0 be better than a single drive? Not required even if it is. b. -- Brian J. Murrell |
|
From: Gregory G. <gr...@pl...> - 2001-11-30 22:45:54
|
I'm not sure if this is too early to ask, but what would be the system requirements? How much power would I need just to record? Don't include playback yet. Just for recording, with mp1e, what have people seen. I have a K6-233 and a P2-233 available as a server. Will either of these do? My desktop is more powerful, but I don't want to use my desktop as a server. I don't plan on using the server for playback to the TV. Also, what about didk performance. Would 2 drives in raid-0 be better than a single drive? Of does these applications not require that much drive performance? Thanks Greg |
|
From: Brian J. M. <3d9...@in...> - 2001-11-30 04:21:48
|
On Thu, Nov 29, 2001 at 09:37:14PM -0500, Mike Bernson wrote: > I have written a subsystem that works for me. Cool. > It grabs the listing for guide from www.tvguide.com. Have you looked into XMLTV? > It then has a graphic interface for selection which program you want to record. Cool. Does that just select a single show in a single time window (i.e. a "one-off recording) or does it allow one to say "this time/channel/duration every week", or "this show any time is is on", etc. If it does any of the latter does it then perform any schedule conflict resolution? b. -- Brian J. Murrell |
|
From: Mike B. <mi...@ml...> - 2001-11-30 02:37:16
|
I have written a subsystem that works for me. It grabs the listing for guide from www.tvguide.com. It then has a graphic interface for selection which program you want to record. It has recorder program that sched the recording. It uses mysql for handling all the data. It is part of the mjpeg project on source forge. It is missing graphic interface for play the recordings back. I normal use it for making svcd. |
|
From: James O. <jf...@fu...> - 2001-11-30 02:05:10
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm probably more coherent now. I have put together a *proposed* overview that should better communicate what I am thinking, with a diagram and everything. You can view/edit it at: http://www.funktronics.ca/openpvr/wiki/SystemOverview On November 29, 2001 02:47 am, Jerry Veldhuis wrote: > James, your email made me think. I don't like it when > that happens, now I'll have to share my views, its the > only way I'll get to sleep tonight. Bare with me. > > XMLTV certainly could use some more user friendly or integration > friendly tools. I've also thought about this problem quite a bit > in the past, although my interests were unrelated to pvr. This may > change soon though I bought a WinTV card :) > > Although I find the XML very useful, it's rarely a good substitute > for a real database. > > I see tv listing queries falling into one of two categories: > 1. Tell me what's on these channels from hour X to hour Y on day Z > 2. Find me all the programs within "this" time frame that have > these kinds of attributes. > > I see your application (pytv) as fitting into category 1. > You can picture a dynamic schedule site (much like, but > smaller than zap2it) as being in both cateogries. > > Certainly your openpvr project also falls into both of > these as well. I've been thinking about these comments all day. I have decided to separate PyTV from OpenPVR for the most part. Basically, PyTV will be for non-PVR applications such as standalone schedule viewers and the like, but will share some code with OpenPVR. > Trying to implement either of these using the XMLTV dtd > to defined the file format is wrong (IMHO). > > Some may see this as a weekness in XMLTV, but I see this as > something that can be use to "with" XMLTV to achieve goals > outside that of XMLTV. Let XMLTV do what it does best, get > the listings in a consistant, reliable fasion. If I'm reading that paragraph right, we're on the same page, for the most part. > What is missing from XMLTV to support these types > of queries ? > > - nothing, unless you are worried about slow sequential, > possibly memory intensive answers. I've been scraping small amounts of data (1 or 2 days worth) and storing it all in memory. For the amount of data, search speed has been just fine, even though I'm using the absolute slowest data structure for it: nested lists. I have two sides: "get it working, then profile" on regular computers, and "optimise as you go along" on processors like Z80s and PICs. :-)* > - dates are 'loosely based on ISO 8601' (xmltv.dtd), so > some amount of work is required to do EVERY date comparison. It's probably best to store all dates in unix time while in memory. > - channels have no defined order, so you'll have to reorder > the query results (this is probably really minor) No biggie. I haven't had any speed problems and I don't see *any* of these tools trying to handle massive amounts of data anytime soon. > - programmes have no defined order, they don't have to be in > channel order or date order. (XMLTV does have utilities that > sort listings though, but only date ordering, not channel or > otherwise) I was doing that at first, but realised that it doesn't really make a difference > > - no enumerations - want a list of categories ? travers the > entire listing. With such a small amount of data, the speed increase from using more advanced data structures isn't really worth it... at least not yet. > There are most certainly others that didn't come to mind. These > are not necessarily "bugs" in XMLTV, XMLTV's job is to > deliver the listings, not present them they way you want to use > them. That's all I ever wanted. > There has been talk of expanding the set of tools that XMLTV > comes with to fill some of these gaps. Like many other > things in the software world, nobody has the perfect tool > for every job, there's always a need for glue. > > Although not everyone sees the listings data as > relational, I do. This most certainly comes from the fact > that what I want isn't what you want, not exactly anyway. > > I've thought that for most applications (not all) you > want the data in something like mysql. It's client/server, > has interfaces for every language under the sun, and the > client end could certainly convert the results into whatever > the application requires. Without a lot of work I think you > could even get the data into mysql optimized for the most > common queries. I know of at least one XMLTV user who does > just this, in support of his pvr project. (he can step forward > and comment if he likes, I won't force him by mentioning names). For PyTV, a DB is overkill, IMO, but OpenPVR will have to use one anyway for storing details of recorded programs, so if it's there, why not? It's a good idea. > My two cents. I like many others have a lot of things I'd LIKE > to do, and a minimal amount of time to do ONE of them. That said > I'm not sure when I might get around to this project. > Maybe a subproject of XMLTV called tvmysql ? The core of such a thing is not really software, but suggested representations of XMLTV data for various purposes. That's mostly a make-it-up-as-you-go-along thing, IMO. Thanks for the comments, - -- James Oakley jf...@fu... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Bul4kCVJEWdfdCgRAsmDAKCG6cjQqIgP3Crpu6mYifdV2BXoSgCgsDOO EfP5JrUZzbNEV15v92TV+ts= =a2QL -----END PGP SIGNATURE----- |
|
From: Billy B. <ve...@du...> - 2001-11-29 20:14:50
|
Brian J. Murrell (d16...@in...): > > > What's the storage rate in terms of bytes/sec.? > > > > I get on average 50-60% compression from raw Y'CbCr images. > > > > So, say you downsample to 4:2:0, and you're capturing > > 525/59.94-style video. Each frame uncompressed is (720*480*12/8) == > > 518400 bytes. So, I compress down to about 260000 bytes on average > > per frame. > > Wow, that is 26GB/H. Well, that's assuming you want full-frame lossless. Probably more realistic to do some subsampling horizontally and somewhat mimic VHS. For example, when recording from VHS sources, I use 352x480 or 360x480. If we still only use 4:2:0 chroma sampling, that gives about 253440 bytes per uncompressed frame, so only 128000 bytes per compressed frame or so. At 29.97fps that's only 13GB/H. With audio I usually get about 15GB/H before compressing to MPEG2 or what not. If you use RTJPEG compression, you can get this to about 10G/H or so. An 80GB drive would then get you about 8 hours of video which you can record and view in real time. Not too bad without any hardware compression. Too bad about the quality though. 30GB/H would be ideal if you're going to recompress to MPEG2 on a DVD-R, I think. It surprises me that I had to write my own recorder to be able to record full-frame video without dropping frames. :( Doesn't anyone else care about quality? > > Yeah, well, the v4l api sucks. > > Do you mean that to include v4l2 as well or specifically v4l1? I'm not too happy with either, but I can probably live with v4l2. -- Billy Biggs ve...@du... |
|
From: Stephen D. <st...@da...> - 2001-11-29 09:14:17
|
On Thu, 29 Nov 2001, Brian J. Murrell wrote: > One thing that I think could be useful for both the OpenPVR project as > well as for V4L in general is a V4L loopback device. The ability to > (re-)capture through the V4L API the contents of a fie which is an > already captured stream would be useful for a) people to play with V4L > that don't have actual hardware (yet) and b) for doing comparisons of > codecs and encoding parameters. Something like this was just announced on the mplayer list - some v4l "plumbing" such that video output can be captured using v4l. Steve |
