openpvr-devel Mailing List for OpenPVR (Page 4)
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. <caf...@in...> - 2002-04-12 17:57:25
|
On Fri, Apr 12, 2002 at 12:37:40PM -0500, Steve Headley wrote: > has anyone thought about incorporating SIP protocol in the PVR? That way = we > can issue signaling message from across the INTERNET. It make for a more > innovative approach. I have heard of the acronym (SIP) in the context of digital media but I have not read much more than that. Can you point me to a good (better than RFC, that I could probably find quite easily) description or give a brief description of what SIP is? b. --=20 Brian J. Murrell |
|
From: Steve H. <she...@om...> - 2002-04-12 17:40:32
|
has anyone thought about incorporating SIP protocol in the PVR? That way we can issue signaling message from across the INTERNET. It make for a more innovative approach. Steven H. |
|
From: Brian J. M. <cd3...@in...> - 2002-04-04 06:47:09
|
On Wed, Apr 03, 2002 at 11:17:18PM -0500, Gregory Gee wrote:
>=20
> Seems to be working now.
Good.
> I've been using your record script quite a few times but haven't updated
> it recently from CVS.
I haven't committed recently either though. I should.
> I use mp1e because I have a really slow computer.
I use it because it's a low CPU consumer and allows me to record
640x480, NTSC.
> Also, I made a few changes in the record script to save to a different
> directory with a fully automated file name
Yes, like schedule, those are hard-coded uglies for the moment.
> and also made the channel
> selection manditory
The reason the channel selection is not mandatory is because one
record instance can be followed directly by another to record on the
same channel. I didn't want the "burp" of trying to change a channel
that didn't need changing.
> beacuse I have no idea what it could currently be sitting
> at.
Well, that is record's caller's responsibility. If it is unknown,
then the caller should most certainly include a "--channel n"
directive.
> On the server where it is running, I don't have X running, so I am having
> problems getting v4lctrl to set the channel since X is not running.
Do you have DISPLAY set, possibly because you are remote X'ed (via ssh
or otherwise)? Try making sure DISPLAY is unset and see if you still
have problems. Post the output if you are still unable to get it to
work.
> Did
> I compile it with the wrong options?
Who knows until we can see what you are getting.
> Does it at least do a clean make && make install?
It should do a clean make, but there is no make install yet. schedule
is a standalone utility right now with no dependence on where it
lives. It does require the following files though:
/tmp/tv_data.xml.gz - XMLTV output.
/tmp/wanted_programs.xml.gz - XML file of programs to record.
/tmp/seen_programs.xml.gz - XML file of esposdes seen.
The first file, you know the format of, or don't care. XMLTV will
produce it. I grab 14 days of XMLTV so that conflict resolution can
have the most benefit.
The second file:
<?xml version=3D"1.0" encoding=3D"ISO-8859-1" standalone=3D"yes"?>
<!DOCTYPE my_programs SYSTEM "xmltv.dtd">
<program>
<item title=3D"ER">
<score>60</score>
<new></new>
<date>
<day>Thu</day><time>22:00:00</time>
</date>
</item>
<item title=3D"The Sopranos">
</item>
<item title=3D"Survivor: *">
</item>
</program>
Right now "new" and "date" are ignored. You can include them but they
will have no effect.
The third file:
<?xml version=3D"1.0" encoding=3D"ISO-8859-1" standalone=3D"yes"?>
<!DOCTYPE seen_programs SYSTEM "xmltv.dtd" >
<!-- for episode guides, see http://epguides.com/ -->
<program>
<item title=3D"ER">
<episode>
<number>1</number>
<date>19 Sep 94</date>
<sub-title>24 Hours</sub-title>
</episode>
<episode>
<number>2</number>
<date>19 Sep 94</date>
<sub-title>24 Hours</sub-title>
</episode>
</item>
<item title=3D"Survivor: Africa">
<episode>
<sub-title>Will There Be a Feast Tonight?</sub-title>
</episode>
<episode>
<sub-title>Smoking Out the Snake</sub-title>
</episode>
<episode>
<date>13 Dec 01</date>
<sub-title>Dinner, Movie and a Betrayal</sub-title>
</episode>
</item>
</program>
"number" and "date" are ignored and likely to go away. I am not sure
I can think of much use for them.
Besides debug, the output is a bunch of "at" commands to schedule the
jobs. I don't currently have schedule execute the at commands while I
vet the output. I just cut'n'paste the current day's at commands.
> I'll give it a try once I see what your interface looks like.
Okie.
> Thanks,
NP. Let me/us know how you make out.
b.
--=20
Brian J. Murrell
|
|
From: Gregory G. <gr...@sy...> - 2002-04-04 04:17:22
|
"Brian J. Murrell" wrote: > > On Sun, Mar 31, 2002 at 12:02:53PM -0500, Gregory Gee wrote: > > > > I can't seem to get to the openpvr project page. > > I can get there. > > > Is it down? > > Doesn't seem to be. http://openpvr.sf.net/ > Seems to be working now. > > Playback is an optional builtin component right now for me. I'd > > really like to at least start recording. > > Well checkout CVS and play with the scheduler and "record". What > record/encoder are you planning on using? record supports a handful. I've been using your record script quite a few times but haven't updated it recently from CVS. I use mp1e because I have a really slow computer. Also, I made a few changes in the record script to save to a different directory with a fully automated file name and also made the channel selection manditory beacuse I have no idea what it could currently be sitting at. On the server where it is running, I don't have X running, so I am having problems getting v4lctrl to set the channel since X is not running. Did I compile it with the wrong options? > > > When the project page returns could someone list the order of the components > > that will be completed and there current state. Also some installation notes > > would be handy. > > They would be. I will see if I can get some basic notes going. Does it at least do a clean make && make install? > > > - scheduler > > - recorder > > - playback > > - web frontend to scheduler > > I will likely not be doing a web interface myself, unless I get an > itch. I am not a fan of web interfaces, but if somebody wants to > write one, I will certainly include it if it's useful enough. > I'll give it a try once I see what your interface looks like. Thanks, Greg |
|
From: Brian J. M. <ea1...@in...> - 2002-04-01 05:24:03
|
On Sun, Mar 31, 2002 at 09:07:34PM -0800, Robert Kulagowski wrote: >=20 > I've been giving the database some thought as well. I've implemented a p= erl > program which takes the XMLTV data from tv_grab_na and inserts it into a > MySQL database structure. I think that this is the easiest way to do the > "heavy lifting" involved with getting a database-driven scheduler > operational, like when users start doing wild-card searches, etc. =20 My schedular, completely xml driven so far supports wild-card matches on programs to record. So one can specify "Survivor: *" to get any of the Survivor series episodes". I don't like the idea of a full SQL database like MySQL however. I think that is overkill. > I am currently implementing the "hints" code that will let a scheduler de= cide > when a particular program has mulitple showings so that in case of schedu= ling > conflict it's easy to decide which program to defer and when. You do know there is a scheduler already written that handles wildcard matches as well as full conflict resolution, complete with program scoring for resolving conflicts, right? It sounds like you are working on the same thing. Why not take a look at what's there already and see if you can add to it if it does not meet your needs. > This handles > cases where something like "The Daily Show" will have 5 showings of the s= ame > program a day, but the _first_ showing is at 2300EST, M-Th, so a conflict= for > the 2300 slot can be filled with a showing that comes after that one. I am not sure I followed that but it sounds like the conflict resolution that my scheduler has. b. --=20 Brian J. Murrell |
|
From: Robert K. <rku...@ro...> - 2002-04-01 05:07:36
|
--- "Brian J. Murrell" <5e4...@in...> > > Well, it's still being developed. I am fairly happy with what I have > going right now, but it's hardly complete. I have been giving the > "seen" database some thought. Right now it's updated manually and > it's an XML file. > > I don't think an XML file is the right solution however. A database > (berkely db perhaps, I dunno yet, opinions welcome) I think is the > better vehicle. An XML file would have to be completely read and > rewritten for every update of the database. I've been giving the database some thought as well. I've implemented a perl program which takes the XMLTV data from tv_grab_na and inserts it into a MySQL database structure. I think that this is the easiest way to do the "heavy lifting" involved with getting a database-driven scheduler operational, like when users start doing wild-card searches, etc. I am currently implementing the "hints" code that will let a scheduler decide when a particular program has mulitple showings so that in case of scheduling conflict it's easy to decide which program to defer and when. This handles cases where something like "The Daily Show" will have 5 showings of the same program a day, but the _first_ showing is at 2300EST, M-Th, so a conflict for the 2300 slot can be filled with a showing that comes after that one. I'm working with a relational database guru on normalizing the schema. I'll post code if anyone cares to see it, but it's ugly. Lots of stuff is hardcoded to get it working, but it does work at this time. __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ |
|
From: Brian J. M. <5e4...@in...> - 2002-04-01 00:15:04
|
On Sun, Mar 31, 2002 at 12:02:53PM -0500, Gregory Gee wrote: >=20 > I can't seem to get to the openpvr project page. I can get there. > Is it down? Doesn't seem to be. http://openpvr.sf.net/ > I want to > know what state it is in. Well, it's still being developed. I am fairly happy with what I have going right now, but it's hardly complete. I have been giving the "seen" database some thought. Right now it's updated manually and it's an XML file. I don't think an XML file is the right solution however. A database (berkely db perhaps, I dunno yet, opinions welcome) I think is the better vehicle. An XML file would have to be completely read and rewritten for every update of the database. > I see code in CVS but no information on state. That's because state-wise it's still quite developmental. > Has someone made up a schedule of what components will be done first. Not really. This is a "scratch what itches" type of project, being done on free and available time. My first itch was a scheduler which led to a need to record and playback. My current itch is a user interface. I have written (but not yet committed) a very basic interface using GTK+ for Linux framebuffer. It simply lists the files in my movie directory and when one is selected, it plays it with MPlayer. Before I can make any more progress with the UI I need to get an IR receiving going so that I can interact with the UI. I went out yesterday to buy some IR (lirc) parts but was not successful. I will be back out tomorrow for them. I expect to have a remote in the next couple of days so I can further the selction and playback UI. > It > would be useful if a release was made available with the scheduler and > recording. Nothing is really release-state ready yet. What you can get out of CVS is useful and works (I use it everyday to schedule my recordings) but basic, but "experimentally-unneeded" things like file locations, and command line args parsing and the like are not there. Also I want to have the seen database fully functional before making a release. > Playback is an optional builtin component right now for me. I'd > really like to at least start recording. Well checkout CVS and play with the scheduler and "record". What record/encoder are you planning on using? record supports a handful. > When the project page returns could someone list the order of the compo= nents > that will be completed and there current state. Also some installation n= otes > would be handy. They would be. I will see if I can get some basic notes going. > - scheduler > - recorder > - playback > - web frontend to scheduler I will likely not be doing a web interface myself, unless I get an itch. I am not a fan of web interfaces, but if somebody wants to write one, I will certainly include it if it's useful enough. b. --=20 Brian J. Murrell |
|
From: Gregory G. <gr...@sy...> - 2002-03-31 17:02:55
|
I can't seem to get to the openpvr project page. Is it down? I want to know what state it is in. I see code in CVS but no information on state. Has someone made up a schedule of what components will be done first. It would be useful if a release was made available with the scheduler and recording. Playback is an optional builtin component right now for me. I'd really like to at least start recording. When the project page returns could someone list the order of the components that will be completed and there current state. Also some installation notes would be handy. - scheduler - recorder - playback - web frontend to scheduler It's probably more granular that the above list. Thanks, Greg |
|
From: Billy B. <ve...@du...> - 2002-03-28 05:05:35
|
Brian J. Murrell (153...@in...): > > I don't know the exact numbers off the top of my head, but I believe > > about 2:1 is the best you can really hope for for lossless. > > Wow! That's a lot of space! Are you willing to accept anything less if you're, say, transcoding your VHS tapes to DVD? Personally I'm quite happy to use 30GB/hr as a preprocessing stage, especially with disks so cheap. I think it would be a mistake to do a lossy DCT approximation, or even worse, MPEG quantization, if you can do a better job later. And no, I'm not talking about getting the bitrate smaller. -- Billy Biggs ve...@du... |
|
From: Brian J. M. <153...@in...> - 2002-03-28 04:55:31
|
On Wed, Mar 27, 2002 at 10:39:30PM -0600, Dave Caplinger wrote: >=20 > I don't know the exact numbers off the top of my head, but I believe=20 > about 2:1 is the best you can really hope for for lossless. Wow! That's a lot of space! > I'm thinking of this from a "regular end user" perspective, where they=20 > (i.e. my wife) aren't going to want to have to manually reencode stuff.= =20 Of course not. It would be a background process, niced down to not interfere with current recording and/or playing tasks. > But thinking this through for a moment: if this really was=20 > worthwhile, would it be useful to limit captures to 15 minutes per file?= =20 > The reason I say this is that if you're going to have to filter and=20 > reencode during "idle" times without any user intervention, you're going= =20 > to need scratch disk space set aside for the intermediate files (which=20 > means that space can never be used to record into), Well, the 15 minute files could be useful but not for this. The resulting file is going to be tiny compared to the source files (with numbers like 2:1 for source and 1-2Mb/s for destination files) so intermediate space is a minimal requirement, but it does mean being able to free up the space the source files are taking up at 15 minute chunks, not 1 hour (or more) chunks. i.e. instead of having to wait an hour to recover the space used to source record a program you can recover 25% of the space after only re-encoding 15 minutes. > So if you recorded in 15-minute (or even smaller, like 5-minute?)=20 > segments, and for any segment you were in the process of re-encoding you= =20 > kept the original around until the re-encoding was done, the user can=20 > still play the segment that is being currently re-encoded (by suspending= =20 > the re-encoding and playing the original), and then later the=20 > re-encoding can pick up where it left off. Any single re-encoding task= =20 > isn't going to run for tens of hours tying up tens of GB of disk space,= =20 > but eventually the recoding (and thus disk space savings) will in fact=20 > happen. I think you are saying what I said, which is probably what you said in the first place. :-) > This would all be predicated on the playback agent being able to peice=20 > together the segments (which could be completely different codecs)=20 > without any a/v-sync hiccups so the user would never notice it. :-) > Seems=20 > like a big caveat to me, but I'm no expert at this. Big indeed. > Does this seem feasible? Well, with somebody making a player specifically for this, yes, but I don't know of a player smart enough to do this right now. b. --=20 Brian J. Murrell |
|
From: Dave C. <de...@co...> - 2002-03-28 04:36:09
|
Brian J. Murrell wrote: > On Wed, Mar 27, 2002 at 09:14:24PM -0600, Dave Caplinger wrote: > >>1) Capture video to lossless-compressed AVI (e.g. huffYVUY) > What's the compression ratios like? I don't know the exact numbers off the top of my head, but I believe about 2:1 is the best you can really hope for for lossless. >>Filtering and re-encoding is likely to be time >>consuming, > > I'll say! I record real-time at about 40% CPU with mp1e and > re-encoding with mencoder runs at 7-9fps, twice (2 pass encoding) > which really amounts to 3.5-4.5 fps. I'm thinking of this from a "regular end user" perspective, where they (i.e. my wife) aren't going to want to have to manually reencode stuff. :-) But thinking this through for a moment: if this really was worthwhile, would it be useful to limit captures to 15 minutes per file? The reason I say this is that if you're going to have to filter and reencode during "idle" times without any user intervention, you're going to need scratch disk space set aside for the intermediate files (which means that space can never be used to record into), so you want to minimize the amount of set-aside disk space, and also you want to try to minimize the time spent on the re-encoding because the user might come back (or a scheduled event might trigger) and need to record again, so you want to be able to free up the CPU to do that more important work. So if you recorded in 15-minute (or even smaller, like 5-minute?) segments, and for any segment you were in the process of re-encoding you kept the original around until the re-encoding was done, the user can still play the segment that is being currently re-encoded (by suspending the re-encoding and playing the original), and then later the re-encoding can pick up where it left off. Any single re-encoding task isn't going to run for tens of hours tying up tens of GB of disk space, but eventually the recoding (and thus disk space savings) will in fact happen. This would all be predicated on the playback agent being able to peice together the segments (which could be completely different codecs) without any a/v-sync hiccups so the user would never notice it. Seems like a big caveat to me, but I'm no expert at this. Does this seem feasible? - Dave |
|
From: <ca...@ab...> - 2002-03-28 04:28:00
|
[...] Dave> So my question for everyone else is: does a PVR need filtering? Does Dave> it make sense to record in one format and then filter and re-encode to Dave> another at a later time? Filtering and re-encoding is likely to be Dave> time consuming, but if we ever hope to move stored shows to some Dave> VCD-variant, we have no choice but to do this, right? (unless you're Dave> going to record in 352x240 29.97 frame/sec (NTSC) 1150 kbit/sec CBR Dave> MPEG1 and forsake any chance of xVCD or SVCD). I think it must be a user choice. Always gives better results filtering, at a cost of time and space. (And, again, edit MPEG is a real pain). Canek -- Confession is good for the soul only in the sense that a tweed coat is good for dandruff. -- Peter de Vries |
|
From: Brian J. M. <aa0...@in...> - 2002-03-28 03:34:34
|
On Wed, Mar 27, 2002 at 09:14:24PM -0600, Dave Caplinger wrote: >=20 > 1) Capture video to lossless-compressed AVI (e.g. huffYVUY) What's the compression ratios like? > So my question for everyone else is: does a PVR need filtering? Does it= =20 > make sense to record in one format and then filter and re-encode to=20 > another at a later time? If I get tight on space I will use mencoder to convert my 5Mb/s 640x480 MPEG1 (captured with mp1e) to 1250Kb/s 640x480 files. > Filtering and re-encoding is likely to be time=20 > consuming, I'll say! I record real-time at about 40% CPU with mp1e and re-encoding with mencoder runs at 7-9fps, twice (2 pass encoding) which really amounts to 3.5-4.5 fps. b. --=20 Brian J. Murrell |
|
From: Billy B. <ve...@du...> - 2002-03-28 03:32:38
|
Dave Caplinger (de...@co...): > 1) Capture video to lossless-compressed AVI (e.g. huffYVUY) > 2) Run the stored video through a gamut of filters > 3) Compress to MPEG1, MPEG2, DivX, etc. depending on desired purpose > > [...] > > For some reason I haven't seen this focus on the Linux side (or maybe > I'm just missing it), where everyone trying to make PVR-like devices > appears to be just realtime-lossy-compressing the video stream (or in > the case of DVB, just storing the incoming MPEG2 stream), and later > playing back that same file. I've been busy lately with school, but ... For my pvr I wrote a huffyuv-like lossless codec to compress Y'CbCr images, and my recording app does basically what you describe above. I've been working on high quality resampling filters and have quite a good 3:2 pulldown inversion algorithm. After this last month of school I'll get back to my coding routine (at least, that's the idea). http://dumbterm.net/graphics/compression/ http://sf.net/projects/reetpvr/ > So my question for everyone else is: does a PVR need filtering? Does > it make sense to record in one format and then filter and re-encode to > another at a later time? Filtering and re-encoding is likely to be > time consuming, but if we ever hope to move stored shows to some > VCD-variant, we have no choice but to do this, right? (unless you're > going to record in 352x240 29.97 frame/sec (NTSC) 1150 kbit/sec CBR > MPEG1 and forsake any chance of xVCD or SVCD). I know I want to be able to make high quality recordings of my VHS tapes. This means I need to be able to record without frame drops and also record data from both fields. So, for VHS I record at least at 480x480 per frame, and then spend alot of time post-processing. You can do a much better 3:2 pulldown detection if your phase finding algorithm is multi-pass, for example. The 3:2 pulldown case is one great example of a filter that's better in the offline case, but if you do want to resample your image, you also want to spend alot of time doing it. To do a correct image resample, you need to convert from Y'CbCr to linear RGB space, interpolate there, and convert back. All of this is incredibly expensive to do right. Of course, doing a poor resample is cheap (especially if you're willing to stay in Y'CbCr space), but will have bad artifacts. Depends what you want to do and how much time you have. If you have hardware MPEG2 encoding and playback, building a PVR application is trivial. If you restrict yourself to bttv-style chips, things become much more difficult. -- Billy Biggs ve...@du... |
|
From: Dave C. <de...@co...> - 2002-03-28 03:11:11
|
I've spent the last week or so tied up in work and over on the Dark Side running Windows on my PC rather than Linux (I dual boot), and I've seen a lot of PVR-like things from the Windows perspective now (check out mediabox.org if you haven't already) and as a result I had some comments to see if anyone else is thinking about this too. For example, a lot of the Windows video-related stuff I see seems to imply a workflow like this: 1) Capture video to lossless-compressed AVI (e.g. huffYVUY) 2) Run the stored video through a gamut of filters 3) Compress to MPEG1, MPEG2, DivX, etc. depending on desired purpose The theory seems to be that you filter out noise, crop the overscan area, deinterlace, change frame size, or whatever before trying to MPEG compress because this will help improve the visual quality and also increase the compression's effectiveness. The choice of MPEG1, 2, etc. then depends on whether you want to burn the result on VideoCD (MPEG1), SuperVCD (MPEG2), etc. or if you're storing it to watch later (DivX). (One caveat that I should mention is that a large percentage of the video-related sites for Windows that I've seen seem to be focusing on ripping DVDs to convert to [x](S)VCD, but the same method seems to be used for live captures too.) For some reason I haven't seen this focus on the Linux side (or maybe I'm just missing it), where everyone trying to make PVR-like devices appears to be just realtime-lossy-compressing the video stream (or in the case of DVB, just storing the incoming MPEG2 stream), and later playing back that same file. So my question for everyone else is: does a PVR need filtering? Does it make sense to record in one format and then filter and re-encode to another at a later time? Filtering and re-encoding is likely to be time consuming, but if we ever hope to move stored shows to some VCD-variant, we have no choice but to do this, right? (unless you're going to record in 352x240 29.97 frame/sec (NTSC) 1150 kbit/sec CBR MPEG1 and forsake any chance of xVCD or SVCD). - Dave |
|
From: Robert K. <rku...@ro...> - 2002-03-26 15:19:15
|
> I wonder if we can interest these folks in expanding their project to > include "Show" based recording as well as schedule grabbing with > XMLTV. There's been another message on the VDR list: [From Mike Pieper, who says he needs a few days to setup a website with the code] " On Sunday 17 March 2002 22:52, you wrote: > you wrote, you can see the vdr OSD in your fb device (VGA card). How do > you make this? How to output vdr on an other device than the dvb card? To speed up the OSD for VDR, Klaus Schmiedinger implemented a OSD-class which is sending bitmaps to the DVB-card. I derived from VDR's OSD-class and exchanged the code which sends the bitmap to the DVB-card by code which sends the bitmap via pipe to my application. This application puts the bitmap on the VGA-card then (by using DirectFb). Therefore it looks exactly the same like in the original VDR. " I think that since there's an analog-in recording capability using mp1e [but it doesn't appear well integrated yet] and there's a output to VGA card function about to be integrated, it might be useful to expand the existing project rather than start one from scratch. There might be philosophical issues though; their EPG comes over the air, and since they do all their encoding in hardware there have been people talking about having 3 and 4 MPEG cards in Celeron 400's. I think we're going to need every CPU cycle we have if we're capturing and encoding in software. They also chunk into 2GB sections, and if I recall, the maintainer didn't want to accept a "big file" patch that could handle bigger chunks. Shows hierarchies are arranged by creating subdirectory structures. I've been working on a show-name scheduler and working on determining clusters of identical shows that are available for recording in case of conflict based on XMLTV data. The logical flow is pretty scoped out, so the next part is to see how it codes. __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ |
|
From: Brian J. M. <c9f...@in...> - 2002-03-18 19:16:10
|
On Sat, Mar 16, 2002 at 10:33:24PM -0500, Gregory Gee wrote: >=20 > I understand why you don't want a web-based UI, but could this be > secondary interface if I don't have access to the console? Indeed, yes. As a secondary "via a computer" access idealogy, this is fine, but I don't want it on the "via the TV and remote" access. > A web interface > would be nice if I am away and forgot to record something. I could just > find the nearest internet connected computer and connect to the server > at home to schedule a new program. You are right on there. b. --=20 Brian J. Murrell |
|
From: Gregory G. <gr...@sy...> - 2002-03-17 03:33:42
|
"Brian J. Murrell" wrote: > > > There's also a web-based controller. See > > http://www.linvdr.org/download/vdradmin/shots/ for screen shots. > > Yuck. I am not even entertaining a web-based interface. It will look > like crap on a TV and take up too much real-estate. Besides, I am not > planning on using X, but rather the framebuffer. gtk-framebuffer > works just fine and DirectFB looks even more promising. > I understand why you don't want a web-based UI, but could this be secondary interface if I don't have access to the console? A web interface would be nice if I am away and forgot to record something. I could just find the nearest internet connected computer and connect to the server at home to schedule a new program. Greg |
|
From: Robert K. <rku...@ro...> - 2002-03-16 18:07:35
|
--- "Brian J. Murrell" <bff...@in...> wrote: > > They do have all the "trick play" functionality working, along with > > multi-speed FF and REW. > What are they "playing back" with? MPlayer? Right now they're using the functionality of the MPEG card. Apparently there are two different kinds, one of which they refer to as "full featured", which I take to mean record and playback, but not simultaneously. The other one is playback only. Also, it looks like the card itself produces analog video out; there are some docs on modifying a jumper and rewiring the card to add an SVideo output. There is a streaming patch that allows Mplayer to be the recipient of RTP packets coming from the encoder, but it only works for live video. http://www.cadsoft.de/people/kls/vdr/index.htm is the actual VDR project. The linuxtv.org site seems to focus on the DVB drivers. The VDR mailing list is searchable from the linuxtv.org site. __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ |
|
From: Robert K. <rku...@ro...> - 2002-03-16 18:01:42
|
> > One interesting thing that they did is the "SDRVP" protocol. It uses
> > ascii-text like commands, so that control of the VDR is possible through
> > telnet. It might be an interesting idea to crib, and could be used
> > between a group of PVRs as a means of scheduling, etc.
> Pointers to the concise specs?
> > One interesting thing that they did is the "SDRVP" protocol. It uses
> > ascii-text like commands, so that control of the VDR is possible through
> > telnet. It might be an interesting idea to crib, and could be used
> > between a group of PVRs as a means of scheduling, etc.
> Pointers to the concise specs?
Here's the help text from the svdrpc.c file:
const char *HelpPages[] = {
"CHAN [ + | - | <number> | <name> ]\n"
" Switch channel up, down or to the given channel number or name.\n"
" Without option (or after successfully switching to the channel)\n"
" it returns the current channel number and name.",
"DELC <number>\n"
" Delete channel.",
"DELR <number>\n"
" Delete the recording with the given number. Before a recording can
be\n"
" deleted, an LSTR command must have been executed in order to
retrieve\n"
" the recording numbers. The numbers don't change during subsequent
DELR\n"
" commands. CAUTION: THERE IS NO CONFIRMATION PROMPT WHEN DELETING A\n"
" RECORDING - BE SURE YOU KNOW WHAT YOU ARE DOING!",
"DELT <number>\n"
" Delete timer.",
"GRAB <filename> [ jpeg | pnm [ <quality> [ <sizex> <sizey> ] ] ]\n"
" Grab the current frame and save it to the given file. Images can\n"
" be stored as JPEG (default) or PNM, at the given quality (default\n"
" is 'maximum', only applies to JPEG) and size (default is full
screen).",
"HELP [ <topic> ]\n"
" The HELP command gives help info.",
"HITK [ <key> ]\n"
" Hit the given remote control key. Without option a list of all\n"
" valid key names is given.",
"LSTC [ <number> | <name> ]\n"
" List channels. Without option, all channels are listed. Otherwise\n"
" only the given channel is listed. If a name is given, all channels\n"
" containing the given string as part of their name are listed.",
"LSTE\n"
" List EPG data.",
"LSTR [ <number> ]\n"
" List recordings. Without option, all recordings are listed.
Otherwise\n"
" the summary for the given recording is listed.",
"LSTT [ <number> ]\n"
" List timers. Without option, all timers are listed. Otherwise\n"
" only the given timer is listed.",
"MESG [ <message> ]\n"
" Displays the given message on the OSD. If message is omitted, the\n"
" currently pending message (if any) will be returned. The message\n"
" will be displayed for a few seconds as soon as the OSD has become\n"
" idle. If a new MESG command is entered while the previous message\n"
" has not yet been displayed, the old message will be overwritten.",
"MODC <number> <settings>\n"
" Modify a channel. Settings must be in the same format as returned\n"
" by the LSTC command.",
"MODT <number> on | off | <settings>\n"
" Modify a timer. Settings must be in the same format as returned\n"
" by the LSTT command. The special keywords 'on' and 'off' can be\n"
" used to easily activate or deactivate a timer.",
"MOVC <number> <to>\n"
" Move a channel to a new position.",
"MOVT <number> <to>\n"
" Move a timer to a new position.",
"NEWC <settings>\n"
" Create a new channel. Settings must be in the same format as
returned\n"
" by the LSTC command.",
"NEWT <settings>\n"
" Create a new timer. Settings must be in the same format as returned\n"
" by the LSTT command. It is an error if a timer with the same
channel,\n"
" day, start and stop time already exists.",
"NEXT [ abs | rel ]\n"
" Show the next timer event. If no option is given, the output will
be\n"
" in human readable form. With option 'abs' the absolute time of the
next\n"
" event will be given as the number of seconds since the epoch
(time_t\n"
" format), while with option 'rel' the relative time will be given as
the\n"
" number of seconds from now until the event. If the absolute time
given\n"
" is smaller than the current time, or if the relative time is less
than\n"
" zero, this means that the timer is currently recording and has
started\n"
" at the given time. The first value in the resulting line is the
number\n"
" of the timer.",
"PUTE\n"
" Put data into the EPG list. The data entered has to strictly follow
the\n"
" format defined in VDR/FORMATS for the 'epg.data' file. A '.' on a
line\n"
" by itself terminates the input and starts processing of the data
(all\n"
" entered data is buffered until the terminating '.' is seen).",
"UPDT <settings>\n"
" Updates a timer. Settings must be in the same format as returned\n"
" by the LSTT command. If a timer with the same channel, day, start\n"
" and stop time does not yet exists, it will be created.",
"QUIT\n"
" Exit vdr (SVDRP).\n"
" You can also hit Ctrl-D to exit.",
NULL
};
/* SVDRP Reply Codes:
214 Help message
215 EPG data record
220 VDR service ready
221 VDR service closing transmission channel
250 Requested VDR action okay, completed
354 Start sending EPG data
451 Requested action aborted: local error in processing
500 Syntax error, command unrecognized
501 Syntax error in parameters or arguments
502 Command not implemented
504 Command parameter not implemented
550 Requested action not taken
554 Transaction failed
*/
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
|
|
From: Brian J. M. <5e2...@in...> - 2002-03-16 06:07:59
|
On Fri, Mar 15, 2002 at 03:16:57PM -0800, Robert Kulagowski wrote: > Interesting item from the VDR newsgroup: >=20 > http://www.linuxtv.org/mailinglists/vdr/2002/02-2002/msg01056.html >=20 > The thread was talking about adding analog video in. Cool. > I'm just curious if we can leverage some of the stuff that's already been > done at the DVR project instead of reinventing the wheel. Perhaps. I am a great fan of using tools that are already made (read: lazy :-). I wonder if we can interest these folks in expanding their project to include "Show" based recording as well as schedule grabbing with XMLTV. b. --=20 Brian J. Murrell |
|
From: Brian J. M. <bff...@in...> - 2002-03-16 06:04:30
|
On Fri, Mar 15, 2002 at 02:40:19PM -0800, Robert Kulagowski wrote: > Hrmm. Really? Almost 1 GB? Ooops. I mean 800KB. :-) > Do we want to start discussing the algorithm for scheduling? While I may= not > be able to crank on the C code like Brian has I'd still like to feel like= I > can contribute. >=20 > I guess there are two possible cases to consider: > 1) The single tuner model > 2) The multiple tuner model, where the tuners may not necessarily be in = the > same PC >=20 > To me, I think it's pretty important to consider the multiple tuner model. It is. > I've been taking a look at the LinuxTV project over at http://www.linuxtv= .org > and http://www.cadsoft.de/people/kls/vdr/index.htm to see what they've co= me > up with. Their project is tightly tied to MPEG2 hardware encoder cards, = and > appears to be a mostly European project. Yes, my findings as well. I would like to try an MPEG2 card, but trying to get one from Germany just seems like a PIA. I wish support for the Hauppage card with the kfir2 chip on it would move forward. It would be nice to be able to make encoder machines that did not need 1+GHz processors. > One interesting thing that they did is the "SDRVP" protocol. It uses > ascii-text like commands, so that control of the VDR is possible through > telnet. It might be an interesting idea to crib, and could be used betwe= en a > group of PVRs as a means of scheduling, etc. Pointers to the concise specs? > The way they handle the multiple tuner model is to have a primary and then > slaves. That would be the way to do it, at least initially. I am not sure this is an application for full fault tolerant clustering or anything. > The primary is used as the main tuner, and it's what's displayed > onscreen. If there's a program recording coming up, it gets put to one of > the secondary tuner cards. If there are no secondaries available, then t= he > primary is used. Collisions are handled through on-screen prompts, and a > timeout. If the timeout expires (user isn't watching TV), then a priority > scheme is used to decide what gets recorded. The priority scheme is also > used to decide what gets deleted when disk space is running out. Interesting. > If the primary is recording something, and a channel change command gets > sent, and there is a free tuner available, the recording job gets handed = off > to a secondary card and the primary then changes channels. They state th= at > this isn't a clean transfer in the sense that there's going to be a gap, = so > the docs recommend changing channels during a commercial break. Yucky. > They do have all the "trick play" functionality working, along with > multi-speed FF and REW. What are they "playing back" with? MPlayer? > What they don't seem to have is a good scheduling mechanism. The EPG is > derived from in-band EPG data - no XMLTV or other scrapers are used. The= y do > have a flexible means of setting recordings, but it's still time-slot rat= her > than Show name based. Their program picker lets you choose a repeating > program that may not run M-F, like The Daily Show, for example, so you can > say that the show is on M-Th only. Still too much like a traditional VCR for me in that respect. > They also have a pretty good OSD. I can't tell whether the DVB cards that > they use provide analog video out, or if they're using a TV-out video car= d. Which project at linuxtv.org are you refering to with all of this? > Recording is done in 2GB chunks. They have an editing mechanism that all= ows > cutting commercials out of recording through mark-in and mark-out points. Cool. > There's also a web-based controller. See > http://www.linvdr.org/download/vdradmin/shots/ for screen shots. Yuck. I am not even entertaining a web-based interface. It will look like crap on a TV and take up too much real-estate. Besides, I am not planning on using X, but rather the framebuffer. gtk-framebuffer works just fine and DirectFB looks even more promising. > I'm curious as to how something like the Replay 4000 is able to determine > where the commercials are. Likely "black frames". > The Replay doesn't have a lot of CPU horsepower, > so I'm assuming that it's monitoring what the video encoder is doing, and > when it starts recording a whole lot of black (or fade to black) it recor= ds > an entry into an index file that says "possible commercial start at block= X". >=20 > The .ndx file is also used for executing forward and backwards skips. I > believe that the .ndx file is keeping track of the GOPs so that it knows > where the I frames are. That sounds feasible. b. --=20 Brian J. Murrell |
|
From: Robert K. <rku...@ro...> - 2002-03-15 23:16:57
|
Interesting item from the VDR newsgroup: http://www.linuxtv.org/mailinglists/vdr/2002/02-2002/msg01056.html The thread was talking about adding analog video in. " So, after this has been clarified, fire up you video grabber, get mp1e ready and enjoin a whole new quality of TV. Oh, of course you also have to apply a small patch and edit your setup.conf manualy. Add the line: AnalogInCmd = nice -n -20 /home/aschultz/zap/rte/mp1e/mp1e -a 0 -b 5000 -p /dev/dsp -m 3 -s 720x576 -r 6,100 Set the paramters to whatever mp1e paramters you need. Patch at http://www.cs.uni-magdeburg.de/~aschultz/dvd/vdr-1.0.0pre1-analog.diff.bz2 IMPORTANT NOTE: This is a first rough cut of analog input support. I will *NOT* spend any more time on it. If someone wants it perfect, he has to do it himself! Have fun " In another message, I've read that someone has added streaming support through the use of mplayer using rtp. I'm just curious if we can leverage some of the stuff that's already been done at the DVR project instead of reinventing the wheel. __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ |
|
From: Robert K. <rku...@ro...> - 2002-03-15 23:04:32
|
--- Robert Kulagowski <rku...@ro...> wrote: > Hrmm. Really? Almost 1 GB? I just did a 14 week download of my headend Please ignore the fact that i thinko'd weeks and days. __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ |
|
From: Robert K. <rku...@ro...> - 2002-03-15 22:40:19
|
> > 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. > ~800MB if you gzip it. My scheduler uses gnome-xml, which can read > gzippd xml files. Hrmm. Really? Almost 1 GB? I just did a 14 week download of my headend and it was 8 megs. (My earlier 4 megs estimation was because I forgot that the default for _grab_na is 7 days.) Are you downloading something like a DirecTV headend? What are other people getting? > > 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. Do we want to start discussing the algorithm for scheduling? While I may not be able to crank on the C code like Brian has I'd still like to feel like I can contribute. I guess there are two possible cases to consider: 1) The single tuner model 2) The multiple tuner model, where the tuners may not necessarily be in the same PC To me, I think it's pretty important to consider the multiple tuner model. Also, to see what others have done in this area, I've been poking around. The cheema.com site seems gone, and neither google nor the wayback machine have anything for the site. Too bad. I've been taking a look at the LinuxTV project over at http://www.linuxtv.org and http://www.cadsoft.de/people/kls/vdr/index.htm to see what they've come up with. Their project is tightly tied to MPEG2 hardware encoder cards, and appears to be a mostly European project. One interesting thing that they did is the "SDRVP" protocol. It uses ascii-text like commands, so that control of the VDR is possible through telnet. It might be an interesting idea to crib, and could be used between a group of PVRs as a means of scheduling, etc. The way they handle the multiple tuner model is to have a primary and then slaves. The primary is used as the main tuner, and it's what's displayed onscreen. If there's a program recording coming up, it gets put to one of the secondary tuner cards. If there are no secondaries available, then the primary is used. Collisions are handled through on-screen prompts, and a timeout. If the timeout expires (user isn't watching TV), then a priority scheme is used to decide what gets recorded. The priority scheme is also used to decide what gets deleted when disk space is running out. If the primary is recording something, and a channel change command gets sent, and there is a free tuner available, the recording job gets handed off to a secondary card and the primary then changes channels. They state that this isn't a clean transfer in the sense that there's going to be a gap, so the docs recommend changing channels during a commercial break. They do have all the "trick play" functionality working, along with multi-speed FF and REW. What they don't seem to have is a good scheduling mechanism. The EPG is derived from in-band EPG data - no XMLTV or other scrapers are used. They do have a flexible means of setting recordings, but it's still time-slot rather than Show name based. Their program picker lets you choose a repeating program that may not run M-F, like The Daily Show, for example, so you can say that the show is on M-Th only. They also have a pretty good OSD. I can't tell whether the DVB cards that they use provide analog video out, or if they're using a TV-out video card. Recording is done in 2GB chunks. They have an editing mechanism that allows cutting commercials out of recording through mark-in and mark-out points. There's also a web-based controller. See http://www.linvdr.org/download/vdradmin/shots/ for screen shots. Other stuff: I'm curious as to how something like the Replay 4000 is able to determine where the commercials are. The Replay doesn't have a lot of CPU horsepower, so I'm assuming that it's monitoring what the video encoder is doing, and when it starts recording a whole lot of black (or fade to black) it records an entry into an index file that says "possible commercial start at block X". The .ndx file is also used for executing forward and backwards skips. I believe that the .ndx file is keeping track of the GOPs so that it knows where the I frames are. __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ |
