-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My longest chapter was left to process overnight. This morning I found:
INFO: [mplex] rough-guess multiplexed stream data rate: 7889048
INFO: [mplex] target data-rate specified : 1008
INFO: [mplex] Setting specified spe
Hallo
> >> MSI-6368 Intel 845D, Celeron 2.4G/400, Fedora Core 3
> > I'm A bit confused, according to MSI the board uses a VIA Chipset an no
> > Intel chipset. Older Via chipsets are known to cause problems with Zoran
> > based cards.
>
> Sorry, you're right, my fault. It's a 6398 (845 Ultra ARU)
On Wed, 29 Dec 2004, Anne Wilson wrote:
> My longest chapter was left to process overnight. This morning I found:
>
>INFO: [mplex] rough-guess multiplexed stream data rate: 7889048
>INFO: [mplex] target data-rate specified : 1008
>INFO: [mplex] Setting specifie
On Mon, 2004-12-27 at 13:41, Trevor Cordes wrote:
> lavrec -f a -i N -d 1 -a 16 -s -l 95 -R l -q 80 z.avi
[..]
> when I playback with lavplay I get lots of:
> Corrupt JPEG data: 13199 extraneous bytes before marker 0xd9
It means data was incompletely delivered by the card. Try recording at
-d2, or
On 29 Dec, Ronald S. Bultje wrote:
> It means data was incompletely delivered by the card. Try recording at
> -d2, or try a lower quality (both mentioned in the FAQ btw), to get an
I tried -d2 and -d4 along with -q from 100 down to 0 in increments of
10. The "extraneous bytes" gets reduced from 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 29 Dec 2004 17:59, Steven M. Schultz wrote:
> On Wed, 29 Dec 2004, Anne Wilson wrote:
> > My longest chapter was left to process overnight. This morning I found:
> >
> >INFO: [mplex] rough-guess multiplexed stream data rate: 78890
I've encoded several things since successfully compiling from CVS last week and it seems to me
the quality has noticeably improved. I originally built from CVS wanting to try y4mdenoise, but
it is just too slow for me to use. However I do use y4mspatialfilter right before yuvdenoise, so
my cha
On Wed, 29 Dec 2004, Ray Cole wrote:
Hi!
> I've encoded several things since successfully compiling from CVS last week
> and it seems to me the quality has noticeably improved. I originally built
Do a cvs update and rebuild now - changes since last week might get
a (tiny) fra
Do a cvs update and rebuild now - changes since last week might get
a (tiny) fraction more quality ;)
I did that last night, but haven't done any serious encoding yet.
Hmmm, the 'yuvycsnoise' filter could probably be dropped - even when I
was using a Bt878 card that
I tried recording at 704x480 and 720x480, and you are correct that if I put a
piece of paper to measure the size of some objects there is a measurable
difference. So I suppose I'll start using 704x480 :-) Not that I'll re-record
all the stuff I've recorded before since 2% is really hard to see
Hi -
On Wed, 29 Dec 2004, Ray Cole wrote:
Possible to hit the key once in a while? :-)
> > Hmmm, the 'yuvycsnoise' filter could probably be dropped - even when I
>
> I noticed a big difference in quality with my Bt878 card, particularly with
> credits and other white text that app
On Wed, 29 Dec 2004, Ray Cole wrote:
> I tried recording at 704x480 and 720x480, and you are correct that if I put
> a piece of paper to measure the size of some objects there is a measurable
> difference. So I suppose I'll start using 704x480 :-) Not that
The thing to try is find s
Looks like nuppelrec is probably handling it correctly. If I record at 720,
704, or 640x480 the image turns out measuring the same every time. My recent
post saying there was a difference is because I'm testing it by recording a
football game on ESPN. They periodically put a bar at the bottom
On Wed, 29 Dec 2004, Ray Cole wrote:
> So looks like I'm OK staying with a capture of 720x480.
If you don't mind getting 16 pixels that aren't part of the signal. ;)
720x480 does not represent a 4/3 image.
Interesting reading can be found at
http://www.mir.co
On Wed, 29 Dec 2004, Ray Cole wrote:
>
> a single frame in probably > 200 hours of recording). I tell it to capture
> at 720x480 and I haven't noticed any distortion. Should I really be
> capturing at 704x480 instead? I don't do any scaling beyond the capture
> phase and it all looks fine to me
On Wed, 29 Dec 2004, Trent Piepho wrote:
> See this, http://www.arachnotron.nl/videocap/site/capture_area2.html
Ah yes - forgot about that, been a while since I visited that site.
> bt848 datasheet. 52.15 is used by VCDs, DVDs in 704x480 mode, and 640x480
> square pixel capture
Hello,
I'm trying to get a a DC10plus card running on my i386 machine running Debian
(unstable) with a 2.6.7 kernel that I've compiled using the Debian kernel package
(including the Debian patches). I'm not using LKM for security reasons, so I'd like to
compile the DC10plus drivers into t
17 matches
Mail list logo
