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, wher
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 rea
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
> > tryi
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 rea
>> 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 352x
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 al
> 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 "p
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
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'
> a
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
>
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,
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 sam
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 fram
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
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
On Tue, 16 Dec 2003, Trent Piepho wrote:
> 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.
Well, you know the maximum bitrate allowed (via the -b option) - could
encode each GOP with tha
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 1/2
> Produces this (approximately 1010 frames), encoding times (real time /
> user time, gives a bit of a view as to how busy the CPUs were during the
> real time, optimal should be 1m realtime, 2m user time, right? and
> average system time was 3.0s, with +/- 0.2s for all tests):
...
Yep. You sh
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 >= t
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
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)
>
28 matches
Mail list logo
