[FFmpeg-devel] libavcodec for iPhone

[Måns Rullgård]

"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
> devices.
>
> 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
> think.
>
> 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
could handle.

>> 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
> simplified/optimized.

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.

-- 
M?ns Rullg?rd
mans at mansr.com