On Mon, 2002-12-30 at 21:32, Steven M. Schultz wrote:
>
> Ah, ok - I thought I had seen programs with tons of options before
> but transcode is in a class by itself ;)
:-)
> Possible. I have seen a player (JVC as I recall) that claimed
> to support SVCDs but in order to
> From: Trent Piepho <[EMAIL PROTECTED]>
> > -rw-rw-r-- 1 sms wse 144355260 Dec 30 18:55 chicken-y4mscaler.mpg
> > -rw-rw-r-- 1 sms wse 146821024 Dec 30 16:45 chicken-yuvscaler.mpg
> >
> > Not bad at all!
>
> Does the smaller output size actually mean y4mscaler is "better"? Running
> You rang? ;)
>
> 14000 frames (~8 minutes) of data captured (by another Canopus convert)
> from a VHS tape and on its way to SVCD.
>
> 1)
> smil2yuv -a $N.wav $N.smil | \
> y4mshift -n -6 | \
> yuvdenoise -S 0 -r 16 -t 5 -l 3 -b 20,56,
Hi -
> From: Florin Andrei <[EMAIL PROTECTED]>
> > > transcode -i ../dv -F 4,"-a 2 -I 1 -S ${maxfs}" -b 128 -V \
> > > -g 720x480 -B 0,15,16 -x dv,avi -y mpeg2enc,mp2enc \
> > > -E 44100 -J resample -o ${name}
> >
> Actually, -g means the _input_ image size. I think it's redundant (my
> D
On Mon, 2002-12-30 at 20:56, Steven M. Schultz wrote:
>
> > From: Florin Andrei <[EMAIL PROTECTED]>
> > I'm creating what i think are _standard_ SVCDs, that is, i'm observing
> > the SVCD specifications exactly. I would expect that to be playable on
>
> _standard_ SVCDs are encoded (in NTSC
On Mon, 30 Dec 2002, Steven M. Schultz wrote:
>
> The two .mpg files:
>
> -rw-rw-r-- 1 sms wse 144355260 Dec 30 18:55 chicken-y4mscaler.mpg
> -rw-rw-r-- 1 sms wse 146821024 Dec 30 16:45 chicken-yuvscaler.mpg
>
> Not bad at all!
Does the smaller output size actually mean y4m
--- [EMAIL PROTECTED] wrote:
> On Mon, Dec 30, 2002 at 10:16:18AM -0800, Trent Piepho wrote:
> >
> > If you just want a PVR, then why not keep the recording in mjpeg form?
>
> I have not tried any of those. I am doing a straight
>
> $ lav2yuv | mpeg2enc
>
> > Those steps are very cpu intensiv
Hi -
> From: Florin Andrei <[EMAIL PROTECTED]>
> I'm creating what i think are _standard_ SVCDs, that is, i'm observing
> the SVCD specifications exactly. I would expect that to be playable on
_standard_ SVCDs are encoded (in NTSC countries) as 480x480 - it
looks from the command
I'm creating what i think are _standard_ SVCDs, that is, i'm observing
the SVCD specifications exactly. I would expect that to be playable on
every DVD player that knows the SVCD standard.
Well, not. A friend of mine has a Panasonic DVD player that was able to
play just fine some non-standard SVCDs
> From: Matto Marjanovic <[EMAIL PROTECTED]>
> yuvscaler, but, yes, it also seems to do be able to do a better job
> of downscaling --- i.e. less junk in the high-frequency bands. I'd
> be curious to see the results of an independent real-life comparison
> of MPEG encoding bit usage using the
Hi all!
I just wanted to say kudos to the developers of these drivers. I just
got an old Iomega Buz working and have been using it for video dumps of
the short movie I just made. It is amazing what one can do with cheap
hardware and open source software (and I get great quality out!). Now
all I ne
On Tuesday 31 December 2002 03:20, Trent Piepho wrote:
> On Mon, 30 Dec 2002 [EMAIL PROTECTED] wrote:
> > At the difference in space usage, disk. I have a 5:27s clip here
> > that I was testing with. It is 720x480, default lavrec jpeg quality
> > (50% I think it is isn't it?). It is 917MB in siz
I still don't see what the big hype is about PVRs. First of all, you can't
get the MPEG recorded material OFF the PVR without first capturing from
its own outputs. So you still need a VCR or Hauppage or DC10+ to capture
AGAIN what you captured on the PVR. Three wasted steps with what you could
do
On Mon, 30 Dec 2002 [EMAIL PROTECTED] wrote:
> At the difference in space usage, disk. I have a 5:27s clip here
> that I was testing with. It is 720x480, default lavrec jpeg quality
> (50% I think it is isn't it?). It is 917MB in size. I converted it
Try lowering the resolution and quality the
On Mon, Dec 30, 2002 at 10:16:18AM -0800, Trent Piepho wrote:
>
> If you just want a PVR, then why not keep the recording in mjpeg form?
Several reasons...
> Sure
> it takes up more space then mpeg2,
Way more!
> but what costs more, a 100GB+ ide drive or
> a hardware mpeg2 compression card?
A
>Version 0.2.0 of y4mscaler is now available on-line at:
>
> http://www.mir.com/DMG/Software/y4mscaler.html
In case anyone has downloaded this since my last message, please do it
again...
The previous version was compiled without any optimization enabled.
I just uploaded a "-O2" version.
Version 0.2.0 of y4mscaler is now available on-line at:
http://www.mir.com/DMG/Software/y4mscaler.html
The webpage now has a preliminary spectral comparison of the various
scaling kernels that are available.
(In response to a question from sms: yes, y4mscaler is slower than
yuvscaler, but,
On Montag, 30. Dezember 2002 03:31, John Ribera wrote:
> By the way: I am attempting to compile everything on cygwin. I have had to
> download and try to install the following:
>
> SDL-1.2.5: success (I was suprised at this)
> avifile0.7-0.7-22: failed
> glib-2.0.7: requires libiconv and pkgconfig
On Mon, 30 Dec 2002 [EMAIL PROTECTED] wrote:
> > It's time consuming, definately, but the results are worth it.
>
> For material that you want to keep on a long term basis this might be
> true. But I am looking for PVR functionality here. Record a one-hour
> television show, watch it, delete it.
Hi Jacob,
On Mon, 2002-12-30 at 18:43, Jacob Levine wrote:
> Perhaps it is unrelated, but in ./configure'ing mjpegtools I received
> the following errors:
[..]
> even though I've installed all of these (libmovtar-0.1.3,
> avifile-0.7.22-20021129, SDL-1.2.5-1) according to the instructions in
> the
On Mon, Dec 30, 2002 at 05:59:00PM +0100, Ronald Bultje wrote:
> Hi Brian,
Hi Ronald,
> Not that difficult, I guess... I'm not familiar with the ffmpeg internal
> interface,
mp1e is from the zapping/rte folks. I don't know if the lineage of
that goes back to ffmpeg though.
> but it shouldn't b
lav_io.c: In function `check_DV2_input':
lav_io.c:1385: too many arguments to function `dv_decoder_new'
lav_io.c:1415: warning: implicit declaration of function `dv_decoder_free'
make[2]: *** [lav_io.lo] Error 1
make[2]: Leaving directory `/home/jake/misc/mjpegtools-1.6.1/lavtools'
make[1]: *** [al
Hi Brian,
On Mon, 2002-12-30 at 16:42, [EMAIL PROTECTED] wrote:
> I guess this is one situation where mpeg2enc fails: being able to
> specify lower quality for faster encoding time. mp1e fills this void
> very well (although only with MPEG1, not MPEG2) but does not (AFAIK)
> fit in a "lav2yuv" pi
On Mon, Dec 30, 2002 at 10:55:35AM +0100, Ronald Bultje wrote:
> Hey Brian,
Hi Ronald,
> Apart from the fact that the PVR isn't supported under linux
With an OpenSource driver, no I don't think so (yet). From what I
have been able to determine, there is a "reference" driver available
with all k
Hey Brian,
On Mon, 2002-12-30 at 02:40, [EMAIL PROTECTED] wrote:
> So it seems. It's just so disappointing. I mean considering mp1e can
> encode mpeg1 realtime @ 640x480 on this hardware, I was just hoping
> for (a sight!) better than 2-4fps from mpeg2enc. It makes me
> seriously doubt the feas
25 matches
Mail list logo
