Menu
▾
▴
nvrec-devel — A place for everybody to meet and discuss the project.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
(43) |
Aug
(40) |
Sep
(10) |
Oct
(8) |
Nov
(11) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(22) |
Mar
(22) |
Apr
(11) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(20) |
Sep
(4) |
Oct
(2) |
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
(4) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
|
From: Heikki L. <hol...@cs...> - 2007-11-24 07:54:39
|
Same drill, different target: Divxfile support was unmaintained, non-working, and obsoleted by ffmpeg. In order to clean up the nvrec code base, support for avifile divx has been removed from the SVN. Users needing divxrec should use older releases. -- Heikki Lindholm |
|
From: Heikki L. <hol...@cs...> - 2007-11-20 10:13:04
|
Librte support was unmaintained, non-working, and in my opinion obsoleted by ffmpeg. In order to clean up nvrec code base, support for librte has been removed from the SVN. Users needing rterec should use older releases. -- Heikki Lindholm |
|
From: Antonio B. M. <ant...@li...> - 2007-09-14 09:10:59
|
El vie, 14-09-2007 a las 10:48 +0200, Ralf Hoffmann escribió: > Hi, > > On 2007-09-14 10:29, Antonio Beamud Montero wrote: > Okay, it works now except for v4lgen_core.c: > > http://nvrec.cvs.sourceforge.net/nvrec/nvrec/v4lgen_core.c?r1=1.9&r2=1.10 > > There's a syntax error in the second part of the diff, I guess you also > want to comment the line > > (v4l2tuner.type & V4L2_TUNER_RADIO)) { Fixed. > Best Regards, > > Ralf Hoffmann > |
|
From: Ralf H. <ra...@bo...> - 2007-09-14 08:47:11
|
Hi, On 2007-09-14 10:29, Antonio Beamud Montero wrote: > Yes, I've solved also with disable-x86_mmx. I'll try to fix it in next > weeks... Okay, it works now except for v4lgen_core.c: http://nvrec.cvs.sourceforge.net/nvrec/nvrec/v4lgen_core.c?r1=1.9&r2=1.10 There's a syntax error in the second part of the diff, I guess you also want to comment the line (v4l2tuner.type & V4L2_TUNER_RADIO)) { Best Regards, Ralf Hoffmann -- Homepage: http://www.boomerangsworld.de E-Mail: Ralf Hoffmann <ra...@bo...> English or German |
|
From: Antonio B. M. <ant...@li...> - 2007-09-14 08:29:31
|
El vie, 14-09-2007 a las 10:08 +0200, Ralf Hoffmann escribió: > Hi, > > On 2007-09-14 09:31, Antonio Beamud Montero wrote: > > I've submitted this two patches, but i've problems to compile the > > source. Can be problems with my distro (Ubuntu 6.10).. I'll test it > > later. > > > > Can you check it out and try it...? > > The (new) files write_thread.[ch] are missing in the cvs archive so I > can't build the whole package. Ok. fixed. > But I experienced a problem compiling > RTjpegN. It works with gcc3 but not gcc4, it might be a problem with the > MMX code, disabling it with "--disable-X86_MMX" seems to work (with a > lot of warnings). Yes, I've solved also with disable-x86_mmx. I'll try to fix it in next weeks... Greetings. |
|
From: Ralf H. <ra...@bo...> - 2007-09-14 08:07:12
|
Hi, On 2007-09-14 09:31, Antonio Beamud Montero wrote: > I've submitted this two patches, but i've problems to compile the > source. Can be problems with my distro (Ubuntu 6.10).. I'll test it > later. > > Can you check it out and try it...? The (new) files write_thread.[ch] are missing in the cvs archive so I can't build the whole package. But I experienced a problem compiling RTjpegN. It works with gcc3 but not gcc4, it might be a problem with the MMX code, disabling it with "--disable-X86_MMX" seems to work (with a lot of warnings). Best Regards, Ralf Hoffmann -- Homepage: http://www.boomerangsworld.de E-Mail: Ralf Hoffmann <ra...@bo...> English or German |
|
From: Antonio B. M. <ant...@li...> - 2007-09-14 07:31:59
|
El jue, 13-09-2007 a las 20:55 +0200, Ralf Hoffmann escribió: > Hi, > > On 2007-09-13 16:44, Antonio Beamud Montero wrote: > > Yes, I'm still maintaining it. > > Your patches are welcome. > > Great to hear. I attached two patches. The first one slightly changes > the cpu test, fixes a small problem with a NULL pointer and it changes > to status line to use fixed fields. Ok. > The actual improvement is in the second patch. It adds a simple write > thread to the nuppelvideo core. I experienced some frame drops once in a > while (every 1-5 minutes) although my system should be fast enough > (Athlon X2 2GHz). I looked into it and found out that for whatever > reason a write operation in the nuvfile_core takes up to half a second. > Since there are only 6 buffers available with my saa7134 based tv card > it will drop some frames. Now all write operations are done by the write > thread so it won't stop the main thread. It does so by copying every > buffer which might be a problem on slow systems. There's a define which > restores the old behaviour if this is a performance problem. > > I could add a configure option to explicitly enable the write thread if > you think this is a better way. For now, it's enough with the define directive. I've submitted this two patches, but i've problems to compile the source. Can be problems with my distro (Ubuntu 6.10).. I'll test it later. Can you check it out and try it...? Greetings. |
|
From: Ralf H. <ra...@bo...> - 2007-09-13 19:00:11
|
Hi, On 2007-09-13 16:44, Antonio Beamud Montero wrote: > Yes, I'm still maintaining it. > Your patches are welcome. Great to hear. I attached two patches. The first one slightly changes the cpu test, fixes a small problem with a NULL pointer and it changes to status line to use fixed fields. The actual improvement is in the second patch. It adds a simple write thread to the nuppelvideo core. I experienced some frame drops once in a while (every 1-5 minutes) although my system should be fast enough (Athlon X2 2GHz). I looked into it and found out that for whatever reason a write operation in the nuvfile_core takes up to half a second. Since there are only 6 buffers available with my saa7134 based tv card it will drop some frames. Now all write operations are done by the write thread so it won't stop the main thread. It does so by copying every buffer which might be a problem on slow systems. There's a define which restores the old behaviour if this is a performance problem. I could add a configure option to explicitly enable the write thread if you think this is a better way. Best Regards, Ralf Hoffmann -- Homepage: http://www.boomerangsworld.de E-Mail: Ralf Hoffmann <ra...@bo...> English or German |
|
From: Antonio B. M. <ant...@li...> - 2007-09-13 14:44:58
|
El jue, 13-09-2007 a las 16:37 +0200, Ralf Hoffmann escribió: > Hi, > > Is there still some development going on in this project? I've done some > improvements in the nuppelvideo backend to avoid frame drops and would > like to contribute them. It is still a very good cli tool for capturing > video with excellent A/V sync. Yes, I'm still maintaining it. Your patches are welcome. Greetings. |
|
From: Ralf H. <ra...@bo...> - 2007-09-13 14:36:20
|
Hi, Is there still some development going on in this project? I've done some improvements in the nuppelvideo backend to avoid frame drops and would like to contribute them. It is still a very good cli tool for capturing video with excellent A/V sync. Best Regards, Ralf Hoffmann -- Homepage: http://www.boomerangsworld.de E-Mail: Ralf Hoffmann <ra...@bo...> English or German |
|
From: Merna M. <fbr...@ez...> - 2004-06-11 02:19:19
|
again build you pie planning appeared anxious, possess concentrate cause short? window easy stretch used human"
O N L I N E U N I V E R S I T Y D I P L O M A S D E G R E E S
Obtain Diploma, Degree, Master
We send the certificate to all countries (WORLDWIDE)
Consider a prosperous future, money earning power
No tests, study, coursework, or interviews required.
Discrete and affordable.
Everyone eligible.
Call now - your diploma awaits you!!!
212-330-8202 (24 hours on call)
Calls returned promptly.
Confidentiality assured.
CALL NOW ----->>> 212-330-8202 (24 hours on call)
notice across men bent late. safety wild occur must brilliant save.
|
|
From: Ginette W. <wri...@os...> - 2004-05-30 11:56:06
|
mother meant parents beautiful not ways appearance. our continued describe remember object out" brother barely places happened handwriting decided.
O N L I N E U N I V E R S I T Y D I P L O M A S D E G R E E S
Obtain Diploma, Degree, Master
We send the certificate to all countries (WORLDWIDE)
Consider a prosperous future, money earning power
No tests, study, coursework, or interviews required.
Discrete and affordable.
Everyone eligible.
Call now - your diploma awaits you!!!
1-915-975-6783 (24 hours on call)
Calls returned promptly.
Confidentiality assured.
CALL NOW ----->>> 1-915-975-6783 (24 hours on call)
left state your appearance same! guilty even through other bring sugar welcome proceeded expression has.
|
|
From: Phung T. <dmw...@vo...> - 2004-05-28 21:56:46
|
socrates kafiri coscoroba untenanted czarevna susan violator melanoplus chiltern unspoilt tirailleur abase merge clamour doet miscount affricate |
|
From: Jessika L. <axs...@cy...> - 2004-05-17 20:43:56
|
corporeal dream feet annulment airbag ignorantly blowtorch rebbe moroccan autoplasty smokey desertion asmodeus vestal riotous bluishness substrata merlangus myotis firsthand shutvulgar effleurer unsettled rati scandium conocarpus camden sarong spergula unscramble asomatous |
|
From: Rosalee S. <fug...@vo...> - 2004-05-15 09:26:43
|
walked explode minniebush chambers sojourner djibouti closeup amaryllis frustrated expertness ancien ugandan enforcer caecilian preanal monestrous karate colubridae castigator casually veinal acquiring |
|
From: Antonio B. M. <ant...@li...> - 2004-04-30 15:19:08
|
Hi all: I have problems when trying to use de xvid library to encode video... It seems a broken backward compatibility in xvid-1.0.0.=20 I'm going to patch the code to fix this... Is anybody doing this yet? Thanks. |
|
From: Justin S. <ju...@ex...> - 2004-02-05 07:14:11
|
Unfortunately, I don't have much time to work on nvrec at the moment. I even have a number of patches in my inbox that I haven't even looked at yet :-( So if anybody else wants to volunteer for the updates (we need ffmpeg and divx4linux), please do! -justin Andy Gombos wrote: > Hello all, > > You can compile nvrec with the 0.4.8 tree by adding #define FRAME_RATE_BASE > DEFAULT_FRAME_RATE_BASE/100-10 in ffmpegfile_core.c > > However, startup is very slow, and my frame rate is listed as 299990.00 fps > for NTSC. Grepping through the the 0.4.6 source, FRAME_RATE_BASE is equal > to 10000, and so is my modification. > > Has any work been done on this? I would like to use some of the > formats/codecs/etc available in 0.4.8. > > Thanks, > Andy > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Nvrec-devel mailing list > Nvr...@li... > https://lists.sourceforge.net/lists/listinfo/nvrec-devel > |
|
From: Andy G. <gom...@ea...> - 2004-02-04 22:42:34
|
Hello all, You can compile nvrec with the 0.4.8 tree by adding #define FRAME_RATE_BASE DEFAULT_FRAME_RATE_BASE/100-10 in ffmpegfile_core.c However, startup is very slow, and my frame rate is listed as 299990.00 fps for NTSC. Grepping through the the 0.4.6 source, FRAME_RATE_BASE is equal to 10000, and so is my modification. Has any work been done on this? I would like to use some of the formats/codecs/etc available in 0.4.8. Thanks, Andy |
|
From: Marc L. <mar...@ie...> - 2003-10-30 06:36:50
|
I will have a look at this one of these days. Work on this got put off due to marriage related stuff X) --=20 greetz, marc |
|
From: Mike M. <che...@ya...> - 2003-10-30 01:51:20
|
#!/dev/null # Here is my second go at a howto build/install, I'm using debian but you don't have to. cvs -z3 -d:pserver:ano...@cv...:/cvsroot/nvrec co -d nvrec-current nvrec || exit 1 cd nvrec-current # First step is to autoconf, there is a script called bootstrap. These are what I use to satisfy # it's dependancys. # ii autoconf 2.57-10 automatic configure script builder # ii automake1.7 1.7.8-1 A tool for generating GNU Standards-complian # I remove any other auto* package. # This will get alsa built. I only use divx4rec, so can some one post all the *-dev(s)? apt-get -yf install libasound2-dev # I also had to satisfy debian builddeps, dpkg-buildpackage will help there. ./bootstrap && ./configure && make && # Also don't forget the patch in my previous posting "2003-08-22 12:00" chmod +x debian/rules dpkg-buildpackage -uc -b -nc; # This don't do much exept duilddeps untill [ -x debian/rules ]. cd .. dpkg -i nvrec_20030310-3_i386.deb exit $? __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ |
|
From: Justin S. <ju...@ex...> - 2003-09-06 12:33:20
|
Hi everybody! There have been a number of patches posted to the list over the past few months, which I have had no time to look at. At the moment I have _some_ time available, so if everybody could resubmit their patches, I can look at including them. So far, I am working from Friday's CVS, and have added Heikki Lindholm's alsa core (will not add his sst patch, and am still looking at the epoch work). Any other patches/submissions, please email them to me when you get a chance (yes, I know they are in the list archive, but I don't have that much time that I can go sort through all of that!). Thanks, -justin |
|
From: Justin S. <ju...@ex...> - 2003-09-05 07:43:19
|
Heikki Lindholm wrote: > Hullo, > could anyone clarify how the audio dropping algo is supposed to work. > There's one thing I don't like: video is dropped only because there's > difference between cheap capture cards clock (which value can't be read) > and system clock used to take timestamps. I get frame drops every 60000 > frames or so and would definitely like to capture more without drops. My > solution was to add epoch to video capture core (capture, say, 1000 frames > and then virtually start over). That should detect real frame drops nicely > while not getting confused by system clock vs. video clock drift. The > audio dropping algo however seems to use the constant 'real world' frame > period as a sort of frame counter, so obviously audio capture would also > need to be modified, but I just wondered why doesn't the frame estimator > (fvtime calculation) ask number of frames from video capture core? The whole problem is Linux's multimedia support. nvrec was written when there was still the intention of adding a system timer to Linux. The source of the timer was to be configurable (i.e. system time, or multimedia I/O, etc.). So I designed around 1 authoratative timer, and force everything else to match that timer. In the ideal world, this timer would have been configured to be that of the video capture core. Linux never got the timer support, so I never went any further with these plans... As for epoch support for audio, I would need to know exactly how you did the video support... > btw. I also made an ALSA core and could put it somewhere if anyone's > interested. Very interested! If you could submit a patch against the latest CVS of nvrec, I would appreciate it! -justin |
|
From: Heikki L. <hol...@ni...> - 2003-09-04 08:02:44
|
Hullo, could anyone clarify how the audio dropping algo is supposed to work. There's one thing I don't like: video is dropped only because there's difference between cheap capture cards clock (which value can't be read) and system clock used to take timestamps. I get frame drops every 60000 frames or so and would definitely like to capture more without drops. My solution was to add epoch to video capture core (capture, say, 1000 frames and then virtually start over). That should detect real frame drops nicely while not getting confused by system clock vs. video clock drift. The audio dropping algo however seems to use the constant 'real world' frame period as a sort of frame counter, so obviously audio capture would also need to be modified, but I just wondered why doesn't the frame estimator (fvtime calculation) ask number of frames from video capture core? btw. I also made an ALSA core and could put it somewhere if anyone's interested. -- hl |
|
From: Markku T. <ta...@ik...> - 2003-09-01 02:08:25
|
Markku Tavasti <ta...@ik...> writes: > On the other hand, maybe the quality might be better with rtjpeg->divx > than mpeg1->divx? But then I need more disk... Ok. I found out that my computers used to display video are too slow for divx. So I'll go with mpeg2. I record with nuppelrec, and then pack with transcode. Packing takes time, but no problem. Or that's what I was thinking... Then yesterday I had several short recordings. Looked 'I have enough disk space', and all encodings were running nice -20. Who cares if there are 3 mpeg2enc's running? Then last, really wanted recording didn't get enough CPU, and ended after 6 minutes, or at least I think that might be the problem. Nuppelrec is suid-root, so it would be capable to set it's priority high enough, but maybe it did not do it since it was running with nice -2, since it was at job. Or are both threads/processes runnign with higher priority? Maybe encoding to rtjpeg did not get enough time, since it was nice -2 still? -- M. Tavasti / ta...@ik... / +358-40-5078254 |
|
From: Justin S. <ju...@ex...> - 2003-08-29 08:11:08
|
Markku Tavasti wrote: > Justin Schoeman <ju...@ex...> writes: > > >>Encoding and writing out are done in a single thread. > > > This may be the problem. If file write is blocking for one second, > encoding is stopped for second? And with tight CPU, frames drop. Yeah, that is becomming a problem these days. Up till recently, the whole system stalled on blocked writes, so it never made a difference. With the IO subsystem improvements, it may be worth looking into this again. >>>bits 100G/hour. Too much for me! >> >>That is always the dilema for high quality video processing. Any >>volunteers to add huffyuv support? > > > Apparently huffyuv is lossless compression? But how much video can be > compressed losslessly, and how much cpu it needs? I would bet for 'too > much CPU'. I hear it is pretty light on CPU, but does not compress too much. Do a bit of googling - there is some info out there somewhere! -justin |
3 messages has been excluded from this view by a project administrator.
