[FFmpeg-devel] libavcodec for iPhone
Wed Mar 11 12:30:47 CET 2009
"Kvikant, Christian \(Scilla\)" <kvide at scilla.tv> writes:
> M?ns wrote:
>> Which translates into losing a lot of performance.
>> Have you tried the ffmpeg4iphone patches at all?
> Static builds of ffmpeg4iphone works out of the box on jailbreaked
> Compiling against trunc: Outside the libavcodec/arm directory there
> are two files that need modification: define sig_atomic_t in
> ffmpeg.c and modify the FASTDIV macro in libavutil/internal.h.
What is the problem with FASTDIV?
> In the arm directory nearly all assembly needs rewriting using older
> syntax and rewriting so that e.g. macros are flattened out. Current
> ffmpeg4iphone patch (ffmpeg4iphone-svn-2009-30-01-v0.0.4.patch) is
> against r16838 and not much arm code has been changed since then I
> As the company I'm working for is targeting official distribution we
> have to have our implementation to use shared libraries. As
> discussed earlier Apple's dynamic linker is not capable of correctly
> relocating static data in the text segments. For this reason we have
> had to rewrite simple_idct_armv6.S. It's not as optimized as M?ns'
> code but probably faster than what gcc would generate from the c
> code anyway. I will post this code here as soon as it is cleaned up
> a bit. Further optimizations are welcome.
I don't see anything that would need relocations there. Do you have
some more details?
> Also, it is worth noting that Apple recently released sample code on
> how to decode aac, amr and mp3 in hardware... In our testes doing
> audio decoding in hardware makes up for what is lost in giving a bit
> of slack in the idct optimizations.
Hardware audio decoding is all good, of course, but losing video
optimisations still means you can't play some videos you otherwise
>> Assembler aside, is there anything you feel could be
>> made simpler?
> If I understand the idea behind the ifdefs in dsputil_arm.c only one
> set of arm instructions are actually used. But the Makefile includes
> all arm flavors whether they are used or not. IMHO this could be
Not all functions are optimised for all variants. The current code
ensures that the best available function is used.
> (Also there is a comment in dsputil_arm.c that ``..those functions
> should be suppressed ASAP..", so maybe someone else has been
> thinking about this as well)
That's about something else.
> For our project we have taken the GStreamer approach and it works great.
I don't know what the gstreamer approach is. Could you elaborate?
> (liboil's assembly had to be patched as well).
I'm not surprised.
mans at mansr.com
More information about the ffmpeg-devel