Thread: [Openpvr-devel] On-going development; ideas, etc.
Brought to you by:
brian_j_murrell,
jfunk
Menu
▾
▴
openpvr-devel
|
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: 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: 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: 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. <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: 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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X