Hallo
> I have two old 5GB SCSI disks which aren't fast enough to capture to. I also
> have one newer 40GB IDE disk which is fast enough. Does anyone know whether,
> if I put them all together as one logical device under Linux's LVM, the
> resultant disk is likely to be fast enough to capture to?
Derek Fountain wrote:
I have two old 5GB SCSI disks which aren't fast enough to capture to. I also
have one newer 40GB IDE disk which is fast enough. Does anyone know whether,
if I put them all together as one logical device under Linux's LVM, the
resultant disk is likely to be fast enough to c
Well, that's what I get for reading the digest version of the list. I
figured nobody had a chance to get to it so soon. The new CVS version
works fine, my patch just moved the bypass outside the filter routine
altogether, and makes only 3 calls to memcpy. Possibly a little
faster, but I'm sure
> (bad) partial deinterlace. The output looks jerky and it doesn't save
> any bits either.
H, I haven't noticed the jerkiness. Seemed to save some bits
but perhaps not as many as it could.
I never noticed before, but on a high-motion scene play
My system is a 2p Xeon with an Iomega BUZ card. I'm running RH8.0
with custom 2.4.20 kernel. I've compiled and installed driver-zoran,
jpeg-mmx, avifile, quicktime4linux, libmovtar and mjpegtools-1.6.1.
It took me a while to get it right, but it now appears the compile and
install was successful.
I
I was able to produce a Segmentation fault in either yuvscaler or
mpeg2enc. Who/Where would I submit this to?
lav2yuv simpsons1.avi | yuvscaler -n n -O VCD | mpeg2enc -n n -s -r 16 -o
simpsons1.m1v
...
INFO: [mpeg2enc] GOP LENGTH = 12
INFO: [mpeg2enc] Frame start 0 I 0 0
INFO: [mpeg2en
--- "Steven M. Schultz" <[EMAIL PROTECTED]> wrote:
> Hi -
> > From: Richard Ellis <[EMAIL PROTECTED]>
> > > > From: [EMAIL PROTECTED]
> > > > Ok, so I just discovered that yuvmedianfilter has a -I switch for
> > > > interlaced inputs (it switches to separate field filtering).
> >
> > Shouldn't th
Hi -
> From: [EMAIL PROTECTED]
> I never noticed before, but on a high-motion scene played back on the
> TV the slow-motion effect was very prominent.
Interesting. I guess I could take ~10 hours and redo the one movie
that I did yesterday to see if I can spot the difference.
> A
On Tuesday 04 Mar 2003 05:58, Derek Fountain wrote:
> I have two old 5GB SCSI disks which aren't fast enough to capture to. I
> also have one newer 40GB IDE disk which is fast enough. Does anyone know
> whether, if I put them all together as one logical device under Linux's
> LVM, the resultant dis
Hallo
> I was able to produce a Segmentation fault in either yuvscaler or
> mpeg2enc. Who/Where would I submit this to?
The users-list is the right one.
Have you compiled the tools, or did you install a RPM.
Which CPU do you have and with optimization does mpeg2enc think it can
use ?
The lines
Hallo
> I'm now doing test videos - the input source is DirecTV through SVHS.
> xawtv works. lavrec works, and the result can be played back successfully
> using lavplay -p S record.avi (software playback). The playback window
> is very small.
Which value did you use for the -d, 1/2/4 ?
You see t
Hi -
When would a person want to employ mpeg2enc's "-Q" option?
The usage() summary says:
--quantisation-reduction|-Q num
Max. quantisation reduction for highly active blocks
[0.0 .. 5] (default: 0.0)
I take this to mean that if '-q 6' is being used and '-Q 1.0'
On Sun, 22 Dec 2002, Matt Voss wrote:
> Thanks for the recommendation. However I was wondering if a low-end ($400)
> minidv camcorder would do just as good of a job - or if the Canopus will
> even beat a $2000-$3000 camcorder's ability to convert analog to digital.
Talking from my experince only:
Hi Aaron,
On Sun, 22 Dec 2002, Aaron Newsome wrote:
> On Sun, 22 Dec 2002, Steven M. Schultz wrote:
> > > From: "Matt Voss" <[EMAIL PROTECTED]>
> > > I also have the following:
> > > 1) Iomega BUZ in a dual-boot WIN98/Mandrake Linux 466 celeron box.
> > > 2) WINTV Happauge in a WIN2K 800 mhz p3 bo
> softens the picture a lot. Median filtering in general is great for
> noise distributions with long tails (non-gaussian, impulsive noise)
> since it can exclude large outliers rather than averaging them in like
> linear filtering, but the flip-side seems to be that edge detail gets
Hi -
> From: [EMAIL PROTECTED]
> My statement about obliterating edges is only partly correct. My
That's a relief ;) I've been doing captures and encoding from
a few laserdiscs I have left (that haven't and likely will never
be released on DVD) and haven't seen edge obl
16 matches
Mail list logo
