Following tests are based on latest libav git. built with same
configurations. The result is even stranger than gst-ffmpeg with sync.
time avconv -i nfsroot2/bitstreams/720p/Source.Code.2011.BluRay.720p.DTS.x264-CHD.mkv
-t 0:1:0 -f s16le a.pcm
panda -- 8.345s
mx53 -- 54.678s
time avconv -i nfsroot2/bitstreams/720p/Source.Code.2011.BluRay.720p.DTS.x264-CHD.mkv
-t 0:1:0 -f s32le b.pcm
panda -- 9.419s
mx53 -- 63.294s
mru, how can I enable profile instruments in libav, any configuration options?
Why native gcc in linaro releases can't support neon instructions? I
think both above platforms support neon.
--
Wei.Feng (irc wei_feng)
Linaro Multimedia Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi,
we are looking at landing more and more full stack test cases for our
automated board support status tracking efforts.
While for some hardware ports it's hard to test whether a port really gets a
proper signal etc, we feel for audio this might be
relatively straight forward: we got the idea that we could connect a cable
from jack out to jack in in the lab and then have
a testcase that plays something using aplay and checks that he gets proper
input/signal on the jack in.
This could be done on alsa level and later pa level (for ubuntu).
A more advanced idea that came up when discussing options was to use
opensource speech recognition like sphinx to even
go one step further and see if the output we produce yields roughly the same
input. For that we could play one or two words,
use speech recognition to parse it and check if the resulting text is
stable/expected.
What do you think?
Would MMWG be able to take experimenting and implementing such end-to-end
audio test into their 11.10 work list?
Thanks for your support!
--
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi folks
I was just told that for any release tarballs, we should avoid a "+"
character in the tarball name. We should use "-" instead.
Please take note of this in future releases
thanks
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
I did some quick and dirty profiling of libpng decoding on a Beagle-xm.
This is the result with one image:
46.18% pngbench pngbench [.] inflate_fast
26.12% pngbench pngbench [.] png_read_filter_row
7.81% pngbench pngbench [.] inflate
5.65% pngbench pngbench [.] memcpy
4.26% pngbench pngbench [.] adler32
2.39% pngbench pngbench [.] crc32
1.78% pngbench [kernel.kallsyms] [k] __copy_to_user
1.76% pngbench [kernel.kallsyms] [k] __do_softirq
1.40% pngbench pngbench [.] inflate_table
1.02% pngbench [kernel.kallsyms] [k] __memzero
And another:
64.79% pngbench pngbench [.] inflate_fast
8.61% pngbench pngbench [.] memcpy
7.46% pngbench pngbench [.] adler32
5.10% pngbench pngbench [.] crc32
3.49% pngbench pngbench [.] inflate
3.16% pngbench [kernel.kallsyms] [k] __copy_to_user
1.33% pngbench [kernel.kallsyms] [k] __memzero
And a third:
47.00% pngbench pngbench [.] png_read_filter_row
28.52% pngbench pngbench [.] inflate_fast
5.12% pngbench pngbench [.] memcpy
4.23% pngbench pngbench [.] crc32
3.85% pngbench pngbench [.] adler32
1.60% pngbench [kernel.kallsyms] [k] __memzero
1.56% pngbench pngbench [.] inflate_table
1.50% pngbench [kernel.kallsyms] [k] __copy_to_user
1.38% pngbench [kernel.kallsyms] [k] __do_softirq
0.78% pngbench pngbench [.] inflate
Two of these are coded using a predictive filter resulting in
png_read_filter_row()
using a substantial amount of decoding time. Multiple filters are available,
thus the different amounts of time seen in that function above. When no such
filter is used, decoding time is dominated by zlib decompression.
Two checksum functions feature in these profiles. Adler32 is the checksum
used by zlib to verify data integrity, and crc32 is used by PNG.
Optimising the png_read_filter_row function in NEON is possible in
principle, the
effort of hooking this up in libpng might however be non-trivial. Assuming a
speedup of 4x for this function, the overall decoding performance
improvement would
be up to ~1.6x depending on the image. This should definitely be investigated
further.
A worryingly large amount of time is also spent in memcpy(). If some
of these calls
could be eliminated, a further 10% speed might be gained. This is likely to be
quite difficult.
Optimising zlib is of course also possible in theory, but is probably even more
difficult.
--
Mans Rullgard / mru
Hi folks
related to the 1109 blueprints, I would like to request you to spend
some time this week to do 2 things
1. add the headline and acceptance parts in each of the blueprints that
aim to release/complete for 1109.
One thing that I have asked you is to make the headline and acceptance
palatable for laypersons who may not know the internal workings of your
components. Think of talking to someone who does not know about your
work - how would you present your headlines in a concise and simple
manner which can make it understood why that work is important and what
benefits it brings? At the same time we cannot be too concise: for
example, acceptance criteria like "it works" or "it builds" mean very
little.
2. Improve the Blueprint titles (mind you **only the title** not the
name of the blueprint). There are some blueprints for 1109 which have a
generic title "Component xyz - Ongoing work for 11.09". I think we could
do a better job at naming those blueprints. So review your blueprints
for 1109 and if needed change those generic titles to something more
descriptive. Perhaps in doing so the headline will be easier to write also.
There is no good example in Linaro on how to do this. So we will need to
experiment. Pls spend time this week to make these changes and I will be
reviewing them and asking for improvements where necessary.
If you have any difficulty in these items ping me either on IRC or email
to have a chat.
thanks,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Hi folks
Multimedia has now its own project group. The linaro-multimedia-wg which
used to be a project is now a project group:
https://launchpad.net/linaro-multimedia-wg
As such it can be used as an "umbrella" for all multimedia projects. For
now there is a general project registered
https://launchpad.net/linaro-multimedia-project. This generic project
can be used to track milestones which do not necessarily release
binaries to our LEBs or upstream.
I have associated this generic project and libjpeg-turbo with
linaro-multimedia-wg project group. Also I will go on creating any
projects which will be releasing binaries for the future releases - the
current understanding is to create the following projects
- x264-arm-optimizations (yang zhang)
- speech-codec-arm-optimizations (rony nandy)
- ucm-audio-integration (wei feng)
One thing to consider is whether we want to merge the first two in 1
project codec-arm-optimizations in order to simplify the discovery of
binary tarball releases through 1 project rather than many - I leave
this decision to you and Kurt. We can take the decision in the meeting
today.
A couple of details to note about the milestones
1. they are marked as YYYY.mm instead of YY.mm (for example 2011.09
instead of 11.09). This is following suite with other projects and
milestones in other WGs.
2. the milestones dates must be exactly 1 week BEFORE the official
release deadline (you can see the official release deadlines in
https://launchpad.net/linaro/11.11), so that we are releasing in time
for the release candidate and the testing process to go ahead prior to
the official release.
Please ask away any questions you may have or voice your concerns.
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
