On Mon, 2003-12-15 at 21:08, Richard Ellis wrote:
What program are you using to monitor CPU usage while mpeg2enc runs?
Some versions of top (if you are using top) report percentages as a
roll-up of the whole SMP machine, so that 3x33% usage really means
99% utilization of the machine, where
On Mon, 2003-12-15 at 20:27, Steven M. Schultz wrote:
On Mon, 15 Dec 2003, Slepp Lukwai wrote:
faster to begin with. However, in both cases, after multiple tests and
trying different things, I can't get the SMP modes to be fast at all. In
fact, they're slower than the non-SMP modes.
On Mon, 2003-12-15 at 22:44, Bernhard Praschinger wrote:
Hallo
I was doing some testing of both the older version (1.6.1.90) and the
newer version of mpeg2enc (1.6.1.92). First off, the .92 was somewhat
faster to begin with. However, in both cases, after multiple tests and
trying
Am Dienstag, 16. Dezember 2003 01:53 schrieb Steven M. Schultz:
demuxing tool (I use mpgtx but transcode might have a tool for that
also).
tcextract -i test.mpg -x mpeg2 -d 1 test.m2v
tcextract -i test.mpg -x mp2 -d 1 test.mp2
Al
Hello,
Im trying to encode a bit stream using the command: mpeg2enc
-b 7500
q5 outputfile; Id like to know why the maximum bit rate obtained never reaches
the desired 7500 kbit/s. The maximum reached was
1000kbit/s.
There
is anything I could do to make the mjpegtools reach the bit
Does anybody have scripts/tools they use to do this? It is possible,
right?
...
Off the top of my head (finger memory) you'll want the latest
y4mscaler (0.6.1), a recent (preferably cvs) mpeg2dec (decoder) and
...
I'd recommend scaling down from 480x480 to 352x480
On Tue, 16 Dec 2003, Daniel Silva wrote:
Hello,
I'm trying to encode a bit stream using the command:
mpeg2enc . -b 7500 -q5 outputfile; I'd like to know why the maximum bit rate
obtained never reaches the desired 7500 kbit/s. The maximum reached was
1000kbit/s.
On Tue, 16 Dec 2003, Matto Marjanovic wrote:
mpeg2dec -s -o pgmpipe input.mpg | pgmtoy4m -i t -a 15:11 | \
y4mscaler -S option=sinc:8 -O sar=20:11 -O size=352x480 | \
mpegenc -f 8 -E -8 -K tmpgenc -4 2 -2 1 -o output.m2v
Yes, and the new -O preset=CVD will take care of all of
Huh? All that pgmtoy4m does is unpack the data from mpeg2dec -o
pgmpipe and slap a YUV4MPEG2 header on it (and FRAME markers). No
conversion done at all.
Ooops... I misread it as ppmtoy4m. Disregard everything I wrote.
This reminds me, maybe a better name for pgmtoy4m
On Tue, 16 Dec 2003, Matto Marjanovic wrote:
Ooops... I misread it as ppmtoy4m. Disregard everything I wrote.
Ok - consider it disregarded ;)
This reminds me, maybe a better name for pgmtoy4m is pgmpipetoy4m
--- because the current name makes it sound like it takes a PGM
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 has to do with the -I setting...
Sorry, upon further testing, I
This reminds me, maybe a better name for pgmtoy4m is pgmpipetoy4m
--- because the current name makes it sound like it takes a PGM (portable
gray map, a la NetPBM) as input, which it does not.
Technically it is a gray map - you can take the output of '-o pgm'
and view it
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 reference frame (prediction and DCT
transform) and the predecessor (bit
Hallo
Top output of the 3 running mpeg2enc with mjpegtools 1.6.1.92 on the
Dual Athlon MP 2100+. That's with -M3. Top usage is 2% and the decoder
is only about 10% intermittent. So, I'm neglecting those for the moment.
I'm using transcode, by the way (though I found the same results when
not
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.
And again, son
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 cpu's trying to eat at the same
On Tue, 16 Dec 2003, 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 reference frame
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 theory.
Yes, but just one 720x480 DVD quality frame is larger than 256k in
size, so a 256k cache per CPU
On Tue, 16 Dec 2003, Steven M. Schultz wrote:
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 reference frame
Steven M. Schultz:
the encoded frame size of a standard SVCD is 480x480. Legal sizes for
DVDs are 720x480, 704x480, 352x480 MPEG-2, and 352x240 MPEG-1
I'd recommend scaling down from 480x480 to 352x480 rather than up to
704x480.
I think I got it right - SVCDs have a SAR of 15:11 but the
Hi Steven, Trent,
But what about bit allocation? You need to know how big the last GOP was
to figure out how many bits you can use for the next GOP.
Actually, this is not such a big deal provided the GOPs are well seperated.
Simplifying a little, you just need to ensure that you have = the
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 theory.
Yes, but just one 720x480 DVD
Which matrix would you use for (S)VHS-sources?
# TMPEGEnc NON-INTRA table
16,17,18,19,20,21,22,23
17,18,19,20,21,22,23,24
18,19,20,21,22,23,24,25
19,20,21,22,23,24,26,27
20,21,22,23,25,26,27,28
21,22,23,24,26,27,28,30
22,23,24,26,27,28,30,31
23,24,25,27,28,30,31,33
-K tmpgenc?
Al
On Wed, 17 Dec 2003, Al Bogner wrote:
Which matrix would you use for (S)VHS-sources?
-K tmpgenc?
That'll work fine.That is a good middle ground between the
default tables and the kvcd (-K kvcd) tables.
Which one to use is a matter of playtime and quality.
Hallo
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
25 matches
Mail list logo
