[FFmpeg-devel] libavcodec for iPhone

Måns Rullgård mans
Wed Mar 18 11:34:23 CET 2009


"Kvikant, Christian \(Scilla\)" <kvide at scilla.tv> writes:

> M?ns wrote regarding FASTDIV:
>>
>> That is much slower.
>>
>> Please try replacing the lsrle line with "movle %0, %2, lsr #1".
>> It's possible the apple assembler hates the lsr pseudo-instruction.
>>
>
> Yes, thx! This replacement works ok with the iPhone SDK.

OK, I'll change that then.  It's not all that ugly, although the newer
syntax is perhaps slightly more readable.

> Regarding dylib relocation:
>>
>>>> I don't see anything that would need relocations there.  
>>>> Do you have some more details?
>>>
>>> Well, neither did I but iPhone's dyld just chokes on it while
>>> loading the dylib...
>>
>> Does it give any details at all?
>
> I checked this out again last weekend and to my surprise I did not get any
> relocation errors from simple_idct_armv6.S in r17942 (libavcodec.52.21.0)
>
> Now when I investigated a bit further I realized that I had two libavcodecs
> loaded into memory and the address rebase error actually came from the other
> build (r16838/libavcodec.52.11.0), which in this specific configuration also
> had simple_idct_arm.S included.
>
> (My assumption had been that all dylibs will be removed from memory when an
> application is terminated but that is apparently not the case. They stay
> loaded between debugging sessions.)

That's just weird...

> So to conclude: static builds of ffmpeg4iphone works ok out of the box. To
> build dynamic libraries jrevdct_arm.S and simple_idct_arm.S need to be left
> out. In both cases it is the const arrays that a) apple's linker feels are
> non-relocateable and b) dyld actually chokes on them when loading them into
> memory.

Annoying, although those files are not needed on an armv6 device anyway.

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




More information about the ffmpeg-devel mailing list