18 Nov
2014
18 Nov
'14
2:10 p.m.
I just redid some benchmarks to find out if the new 12Bit processing causes any
performance degradation. On two machines, Mac and Windows, 1.76.12 is even slightly faster
than 1.69.
Carl, is the 12Bit processing always on, or only with content >8Bit?
- Carsten
18 Nov
18 Nov
2:48 p.m.
On Tue, 18 Nov 2014 15:10:35 +0100
Carsten Kurz <audiovisual(a)t-online.de> wrote:
I just redid some benchmarks to find out if the new
12Bit processing
causes any performance degradation. On two machines, Mac and Windows,
1.76.12 is even slightly faster than 1.69.
Carl, is the 12Bit processing always on, or only with content >8Bit?
Hi Carsten,
Thanks very much for doing that. I've been meaning to check. 12-bit is
always on: frame images are converted from whatever to 48-bit RGB
(16:16:16) (as FFmpeg does not seem to have a 12bpp RGB type) and then
truncated to 12bpp before the gamma correction and RGB->XYZ conversion.
I'm a bit surprised there isn't a noticeable hit, but then most of the
time is spent in J2K encoding anyway.
There were a few small performance optimisations around 1.70.0 that
might be having an effect here.
Regards,
Carl
2:56 p.m.
Am 18.11.2014 um 15:48 schrieb Carl Hetherington:
I'm a bit surprised there isn't a noticeable
hit, but then most of the
time is spent in J2K encoding anyway.
There were a few small performance optimisations around 1.70.0 that
might be having an effect here.
Yes, that could be the slight improvement I am seeing. However, this was just a quick
check on some rather slow machines with only a few threads. I guess with a higher number
of threads on modern CPUs, the memory usage could come into play. Next test is network
clients, I am sure this will see a real hit because of the necessary bandwidth.
I guess with modern CPUs, handling 8Bit data is rarely a real advantage, as they have
native and optimized ways to deal with 16, 32 bit,... data.
I will try to repeat the same test on the same Mac network I used for my previous network
test. Let's see...
- Carsten
3:26 p.m.
On Tue, 18 Nov 2014 15:56:39 +0100
Carsten Kurz <audiovisual(a)t-online.de> wrote:
Am 18.11.2014 um 15:48 schrieb Carl Hetherington:
It shouldn't cause too many problems because frames are sent across the
network in their original format and scaled / colourspace converted on
the encode server. It would be good to find out what happens in
reality though :)
Cheers,
Carl
I'm a bit surprised there isn't a
noticeable hit, but then most of
the time is spent in J2K encoding anyway.
There were a few small performance optimisations around 1.70.0 that
might be having an effect here.
Yes, that could be the slight improvement I am seeing. However, this
was just a quick check on some rather slow machines with only a few
threads. I guess with a higher number of threads on modern CPUs, the
memory usage could come into play. Next test is network clients, I am
sure this will see a real hit because of the necessary bandwidth.
3:30 p.m.
Am 18.11.2014 um 16:26 schrieb Carl Hetherington:
It shouldn't cause too many problems because frames are sent across the
network in their original format and scaled / colourspace converted on
the encode server. It would be good to find out what happens in
reality though :)
Of course, it wouldn't mean more traffic for 8Bit content, that is true, but for real
12Bit native sources, the network saturation would occur sooner, that is, at lower
encoding frame rates.
I will have to prepare some test-footage.
- Carsten
3814
days inactive
3814
days old
4 comments
2 participants
participants (2)
-
Carl Hetherington -
Carsten Kurz