Hi!
> From: Alexei Dets <[EMAIL PROTECTED]>
> I've decided to investigate a bit a dependence of mpeg2enc encoding speed from
> the value of its -M (--multithread) encoding option & the type of the kernel
> (UP/SMP) the system runs on the Pentium 4 with hyperthreading support.
> For the tests with UP kernel hyperthreading was disabled in BIOS, for SMP -
> enabled.
The "HT" isn't a full/complete cpu (dual core cpus are in the process
of being developed by Intel (and others)). So enabling/disabling
Hype(r)Threading (it's mostly "hype" by Intel) is not the same
as actually having a 2nd cpu.
But of course you knew that already :-)
> Testing platform:
> System: Pentium-4 2,4Gz with hyperthreading support, i865PE, 256M RAM
> (single-channel mode)
> OS: Linux, Fedora Core 1, kernel-2.4.22-1.2194.nptl (and its SMP version)
> Software version: mjpegtools-1.6.2
Ah, but no 2nd cpu. That's where SMP will actually take effect - the
partial cpu that Intel put in isn't really a good test of SMP
efficiency - for that a full 2nd cpu is needed.
> Testing command:
> time cat stream.yuv | yuvscaler -n n -O SVCD 2> /dev/null | mpeg2enc -f 4 -F 1
> Results:
> 1. Hyperthreading disabled, UP kernel:
> -M 0 1m42.133s
> -M 1 1m41.043s *
> -M 2 1m44.355s
> -M 3 1m46.544s
> -M 4 1m43.633s ???
> -M 5 1m51.273s
Those look to be Insignificant variations. As expected.
> 2. Hyperthreading enabled, SMP kernel:
> -M 0 1m53.083s
> -M 1 1m47.157s
> -M 2 1m37.317s
> -M 3 1m31.565s
> -M 4 1m31.379s *
> -M 5 1m31.832s
> So, the results show that encoding with hyperthreading enabled is about 10%
> faster and the optimal thread number for uniprocessor P4 system without
I've very suprised to see those results! When I enabled HT the
entire system slowed down and encoding ran about 15-20% *SLOWER*. That
was on a real dual P4/Xeon. With HT enabled the system showed
4 "cpus" (of which only 2 were the real/heavy ones and 2 were the
partial/lightweight ones). The kernel treated all 4 pretty much
the same and scheduled processes accordingly - and that is something
which causes an overall slowdown because the extra "cpus" weren't
executing threads from the same process (which is where any benefits
of HT come from).
>BTW, also the results showed that on a such system it is possible to encode to
>SVCD resolution in real time, even faster - the video fragment is ~ 2min. :-)
As long as no filtering is needed...
Place a yuvdenoise, yuvmedianfilter, or y4mdenoise in the pipeline and
see what happens :-)
That's where a real 2nd cpu comes in handy - I keep both cpus busy
by using a 6 or 7 stage pipeline prior to the encoder. The speed of
the encoder actually doesn't matter since the preceeding stages are
the limiting factors.
> I also tried the -R 2 switch (since the default -R 0 is known to produce
> artifacts sometimes & --no-dualprime-mpeg2 switch is not available in 1.6.2
Oh, you're not running the CVS version. That's where changes/fixes
would be made if bottlenecks/bugs are found and fixed as a result of
testing/profiling/etc...
One thing I should mention here in case the notice in the -developer
list was missed: The default in the CVS version is now to NOT
use DPME (DualPrimeMotionEstimation) - if you want DP then the
option is now --dualprime-mpeg2.
> Encoding without hyperthreading is ~7% faster in this case - "-R 2" perfomance
> hit is terrible for the system with hyperthreading (or to any SMP system?) -
You do know that 1) B frames are computationally expensive and 2)
there's been a buglet in mpeg2enc for quite a while that accidentally
serializes the processing in a way that renders -M mostly meaningless
when B frames are used.
> nearly half ot the perfomance is lost :-( BTW, the resulting file is also a
> bit bigger :-(
I've noticed that too - there are few cases I have seen where using
B frames reduces the bitrate. Even with clean sources (D8 or DV
camcorder) not using B frames seems to give a lower bitrate. The
size difference between B and P frames with mpeg2enc is often fairly
small - and at that point skipping the B frames gives a smaller file
(lower bitrate). On the other hand I have seen commercial encodings
where the size difference between the B and P frames is substantial
(the B frames are _much_ smaller) - in that case using B frames is
a Good Thing.
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
