For a while it has seemed to me that negative width and height values
given to yuvdenoise on the -b parameter have not in fact created a
black border on the bottom and/or right of a filtered image. So I
started looking around in the code to see what was up.
The man page says that the -b paramete
On Tue, Sep 30, 2003 at 10:05:07AM -0700, Steven M. Schultz wrote:
>
> On Tue, 30 Sep 2003, Richard Ellis wrote:
>
> > Note the w: and h: sizes. The border was specified as -b
> > 4,4,-4,-4, and when a -4 signed int is stuffed into an unsigned
> > int variable, 6
Does anyone on the list have one of the latest and greatest AMD
Athlon 64's? If so, how does it stack up speed wise running mpeg2enc
vs. Intel's P4 chips?
This article:
http://www.pcworld.com/resource/printable/article/0,aid,112749,00.asp
part way down contains this statement:
"Once video e
Has anyone tried the current cvs mpeg2enc lately? I pulled the
current cvs on Nov. 4 because I wanted to see for myself how well the
new "no B frames please" option worked. But my copy of mpeg2enc
compiled from the source I pulled that day takes a segfault while
it's processing the first frame (
On Fri, Nov 07, 2003 at 04:20:13PM +0100, Bernhard Praschinger wrote:
> Hallo
>
> > Has anyone tried the current cvs mpeg2enc lately? I pulled the
> > current cvs on Nov. 4 because I wanted to see for myself how well the
> > new "no B frames please" option worked. But my copy of mpeg2enc
> > com
On Fri, Nov 07, 2003 at 09:30:05AM -0800, Steven M. Schultz wrote:
>
> On Fri, 7 Nov 2003, Richard Ellis wrote:
>
> > lav2yuv t.cut | mpeg2enc.cvs.2003.11.04 -M 0 -f 5 -n n -a 2 -V 230 -B
> > 224 -S 8000 -b 9576 -q 10 -I 1 -G 54 -H -N 0.0 -X 200 -Q 4.0 -d -4 4
&
On Fri, Nov 07, 2003 at 10:28:40AM -0800, Steven M. Schultz wrote:
>
> On Fri, 7 Nov 2003, Richard Ellis wrote:
>
> > switch. Using gop length of 54 shrinks the resultant video size
> > a wee bit due to fewer I frames. The command line is what I use
> > for
>
>
On Fri, Nov 07, 2003 at 07:24:08PM +0100, Bernhard Praschinger wrote:
> > > q_scale_type=1, satlim=2047, nonsat_mquant=0x41b5d02c)
> > > at quantize_x86.c:309
> > > 309 mulps_m2r( *(mmx_t*)&piqf[0], xmm2 );
> I forgot to ask, wihch version of NASM do you use ?
> I have N
On Fri, Nov 07, 2003 at 10:40:06AM -0800, Steven M. Schultz wrote:
>
> On Fri, 7 Nov 2003, Bernhard Praschinger wrote:
>
> > Could it be a memory problem ?
> > On my machine mpeg2enc buffers 111 Frames. That is about 100MB
>
> That's a possibility I suppose. The other thing that might cause
>
On Fri, Nov 07, 2003 at 11:49:03AM -0800, Steven M. Schultz wrote:
>
> On Fri, 7 Nov 2003, Richard Ellis wrote:
>
> > It's been so long since I bumped up to -G 54 for timeshifting I
> > don't remember, but when I tested it the reduction was worth
> > en
I've got a second real world example now:
76,643 MJPEG frames, for 42.6220 minutes of video.
GOP 54 343,248,122 bytes
GOP 18 357,706,821 bytes
A 4.042% reduction in size.
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November i
On Wed, Nov 26, 2003 at 11:21:37AM -0800, Florin Andrei wrote:
>
> I actually thought the total max mandated by the DVD standard is
> 10.08 Mbps or something like that (and it's the sum of the actively
> played tracks, not of all the stuff in the VOB). So that would
> leave, above a 9800 kbps ceil
e editing to include mpeg2enc libs on the
final mpeg2enc link call. It wasn't hard to do, but it did take a
bit of investigating to determine which libs should link in.
On Fri, Nov 07, 2003 at 09:22:44AM -0500, Richard Ellis wrote:
>
> Has anyone tried the current cvs mpeg2enc lately?
On Mon, Dec 01, 2003 at 08:37:14AM -0800, Steven M. Schultz wrote:
>
> On Mon, 1 Dec 2003, Ronald Bultje wrote:
>
> > On Mon, 2003-12-01 at 00:06, Steven M. Schultz wrote:
> > > As a temporary measure you can try editing the compat function
> > > posix_memalign to return an aligned address.
Has anyone noticed mpeg2enc rc92 creating odd "flashing" artifacts on
what should be otherwise generally smooth color backgrounds? I've
attached a small jpeg (29k) showing an example of the artifact. If
you look to the right of the tall actor's shoulder, you can see very
clearly what I'm talking
On Wed, Dec 03, 2003 at 09:39:18PM -0800, Steven M. Schultz wrote:
>
> On Wed, 3 Dec 2003, Richard Ellis wrote:
>
> > attached a small jpeg (29k) showing an example of the artifact.
> > If you look to the right of the tall actor's shoulder, you can
> > see ver
On Thu, Dec 04, 2003 at 04:18:36PM -0800, Steven M. Schultz wrote:
>
> On Thu, 4 Dec 2003, Richard Ellis wrote:
>
> > splotches less intense, but they are still there. If you want, I
> > can lavtrans out the first 30 or 60 seconds of the capture and
> > set it up
>
On Mon, Dec 15, 2003 at 01:46:32AM -0700, Slepp Lukwai wrote:
> ...
>
> Of course the -M 3 changes to 2 and 0 in testing. I also tested it
> with and without the buffer program in the list. Another notable
> thing, is that with the newest version .92, -M3 causes three 33%
> usage processes to exis
On Tue, Dec 16, 2003 at 09:27:53AM -0800, Steven M. Schultz wrote:
>
> Perhaps Richard Ellis could chime in with his experiences with -Q
> ;)
It seems that with the right set of options, and the right set of
input data, -Q can help to create some really nasty looking
artifacts.
>
On Tue, Dec 16, 2003 at 12:33:52AM -0700, Slepp Lukwai wrote:
> On Mon, 2003-12-15 at 21:08, Richard Ellis wrote:
> > Additionally, why kind of memory do you have attached to the cpu's?
> > Mpeg encoding is very memory bandwidth hungry to begin with, and with
> > two
On Tue, Dec 16, 2003 at 12:45:48PM -0800, Trent Piepho wrote:
> On Tue, 16 Dec 2003, Richard Ellis wrote:
> > > 6 or 8GB/s L2. The cache size is 256k/CPU, 64k L1. At 550MB/s,
> > > it SHOULD be able to push enough to keep the frames encoding at
> > > 100% CPU, in
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
On Fri, Dec 19, 2003 at 01:34:38AM -0800, Trent Piepho wrote:
> On Fri, 19 Dec 2003, Andrew Stevens wrote:
> > The next bottlenecks would be the run-length coding and the use
> > of variance instead of SAD in motion compensation mode and DCT
> > mode selection. Sadly
>
> Is SAD really any faster
On Mon, Jan 05, 2004 at 08:35:31AM -0800, Steven M. Schultz wrote:
>
> On Mon, 5 Jan 2004, Dik Takken wrote:
>
> > Will version 1.6.2 be compilable on gcc 2.96? I have posted problem
> > reports about 1.6.1, which appears to be compilable only on gcc 3.x.
>
> gcc 2.95.{3,4} was able to compile m
On Mon, Jan 05, 2004 at 07:53:54PM +0100, Dik Takken wrote:
> On Mon, 5 Jan 2004, Richard Ellis wrote:
>
> > No one should be using 2.96. That was never an official gcc
> > release, but instead was a redhat invention (which redhat release
> > I do not know) made by pulli
101 - 125 of 125 matches
Mail list logo
