Brian J. Murrell wrote: > On Tue, Nov 20, 2001 at 08:54:45AM +0200, Justin Schoeman wrote: > >>The sort of jerkiness you are talking about is typically the result of 1 >>of 2 things: >> >>1) Hard disk speed is too slow. To fix this, use hdparm to optimise your >>drive settings, or use a compression algorithm with higher compression >>ratios. >> > > Well, if I were using an mpeg/divx/div4 bitrate of (say) 1800kbps that > is only 230,400 bytes/s required disk throughput. Even over NFS I can > achieve 6.7 megabytes/s: > > $ time dd if=/dev/zero of=/video/test.avi bs=1024k count=100 > 100+0 records in > 100+0 records out > 0.00user 0.85system 0:14.82elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (144major+25minor)pagefaults 0swaps > [brian@pc NVrec-20011102]$ ls -l /video/test.avi > -rw-rw-r-- 1 brian brian 104857600 Nov 20 03:09 > /video/test.avi > > So disk can hardly be the issue right? Or is there something other > than raw throughput that I am missing?
No - this is more than fast enough. >>You may notice that these two are contradictory - so you need a fast HDD >> or a fast CPU, or preferably, both. >> > > I think I have both. My CPU is an AMD Athlon-800 (Thunderbird). > > >>I have an Athlon 600, and use DIVX4rec with the "-dq3" option. >> > > I tried that just now. I am floored by the quality -- compared to > what I have been getting in the past. I like! I like! I am sure I > tried all of the XXXrec tools in the past and none were working all > that well. Hmmmm. You know now that I think of it, I think the > problem I had with the DIVX*rec tools was that the playback seemed to > "smear" with Mplayer. Any ideas on that? It seems alright now but if > it were to happen again it would help to know what to look for. I am not sure what "smear" you are talking about... It could be interlace problems, in which case using the "-deinterlace" option for DIVX4rec should help. >>It never >>drops any frames, >> > > I only got frame drops when I asked the computer to do something else > simultaneously. :-) > > >>and the quality is still pretty good. >> > > Indeed. > > >>On a PIII-800, >>I use "-dq 5", and the quality is awesome...) >> > > I compared -dq 3 and -dq5 recording from analog cable and I don't > think I see much of a difference. I think to be sure I would need to > encode the same clip from cable twice so I could actually compare side > by side. Who cares though? -dq3 looks good. :-) The quality setting really show when you lower the bitrate. Using "-dq 5", I drop the bitrate to 256kbit/s, and it still looks good (most of the time). > >>mp1e is the best low-cpu option I >>have ever seen, >> > > Indeed! > > >>but I have had many problems with A/V synch. >> > > Me too! I guess we can just hope and wait for RTE to work with > RTErec. > > Something I did notice in going back over the XXXrec tools: DIVX4rec > seems to have an A/V lag. The audio and video seem to be out > somewhere between a half a second to a second. Using DIVXrec seems to > be just fine however. Aargghh.... This is the second time I have received a bug report along these lines, but I have never managed to duplicate it! I use DIVX4rec for day to day VCR usage, as well as continuous live streaming of TV, and never notice any synch offsets (on any of the PCs I use). The last bug report said that the AVI header may be wrong, but I am not clued up enough on AVI to know what is wrong with it... If anybody has any idea what the problem could be please let me know! 8-) -justin _______________________________________________ Video4linux-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/video4linux-list
