On Tue, 2003-12-16 at 12:57, Bernhard Praschinger wrote:
> Could you run a few test (please). Get some frames (100-1000) as yuv
> format. I gues that should be possible even with transcode. ;)
> (I do not use transcode so I can't help, or get the test streams on
> mjpeg.sf.net)
With about 1010 fr
On Tue, 2003-12-16 at 12:33, Andrew Stevens wrote:
> Hi all,
>
> First off a bit of background to the multi-threading in the current stable
> branch. First off:
>
> - Parallelism is primarily frame-by-frame. This means that the final phases
> of the encoding lock on completion of the referenc
On Tue, 2003-12-16 at 13:15, Richard Ellis wrote:
> On Tue, Dec 16, 2003 at 12:33:52AM -0700, Slepp Lukwai wrote:
> >.. It's a dual Athlon, which inherently means 266FSB (DDR 266),
> > though the memory is actually Hynix PC3200 w/ timings set as low as
> > they go on this board (2-2-2), which gives
Just a side note, I find it interesting your name is Andrew Stevens,
whereby mine is Stephen Andrew (middle name).
On Tue, 2003-12-16 at 14:41, Andrew Stevens wrote:
> Yep. You should (in theory) get a lot closer to that with the current
> MPEG_DEVEL branch mpeg2enc. However, your scaling is
On Tue, 2003-12-16 at 10:27, Steven M. Schultz wrote:
> On Tue, 16 Dec 2003, Slepp Lukwai wrote:
>
> > Tried it without any options, same effect. I'm definitely seeing nowhere
> > near 40% speedup, which is what boggles me. I expected at least
> > reasonable gains of 25%.
>
> I think that h
On Tue, 2003-12-16 at 23:17, Bernhard Praschinger wrote:
> > -M 0: 2m 11.9s
> > -M 1: 2m 10.6s, -1.3s
> > -M 2: 1m 27.7s, -44.2s
> > -M 3: 1m 26.5s, -45.4s
> That values look much better. :-)
> Now you have seen the mpeg2enc can go faster.
It's like it used to be. :> I'm going to try it on a full
On Tue, Dec 16, 2003 at 06:54:22PM -0700, Slepp Lukwai wrote:
> As a side note, I'm also using a 200Hz timer, instead of the standard
> 100Hz. Though I don't see this doing anything but making it quicker, as
> it reduces latency on scheduling, while slightly increasing scheduler
> overhead and cont
Hallo
> On Tue, 2003-12-16 at 23:17, Bernhard Praschinger wrote:
> > > -M 0: 2m 11.9s
> > > -M 1: 2m 10.6s, -1.3s
> > > -M 2: 1m 27.7s, -44.2s
> > > -M 3: 1m 26.5s, -45.4s
> > That values look much better. :-)
> > Now you have seen the mpeg2enc can go faster.
Sorry but I got your other mail with
I have Verbatim DataLifePlus - CD-R - 700 MB - 80min media.
Usually, if I use vcdimager to make a bin/cue image from, say 10 MPG1 files totalling
upto 800MB, I can burn the bin/cue image just fine.
But yesterday I created a bin/cue image from 35 MPEG1 files totalling 760MB and the
bin file cr
Hi!
On Wednesday 17 December 2003 1:42 pm, [EMAIL PROTECTED] wrote:
> I posted this question on vcdhelp.com forums and got the following answer:
>
> --x---
> The problem of "bloating" is almost certainly because your MPEG files
> weren't multiplexed in the way that VCDImager wants them. This leads
Hi all.
> It's why I came up with the pgmtoy4m program. The YUV4MPEG output
> from mpeg2enc was a local hack (I think Andrew did it eons ago to
> an old version of mpeg2dec).
Its actually *really* easy to do. I don't think mpeg2dec has changed all
that much in quite a
On Thu, 18 Dec 2003, Andrew Stevens wrote:
> Its actually *really* easy to do. I don't think mpeg2dec has changed all
True, especially if the scaling part is left out. No need for YUVs,
YUVh, and so on.
On the other hand having a forked copy of mpeg2dec to maintain
Hallo
> > Its actually *really* easy to do. I don't think mpeg2dec has changed all
> True, especially if the scaling part is left out. No need for YUVs,
> YUVh, and so on.
That has historic reasons, because they were written at a time no scaler
(yuvscaler or Matto's scaler) exi
13 matches
Mail list logo
