Steve Langasek ha scritto: > There is a middle ground here, which is mplayer statically linking > against the common ffmpeg package; I think that would be a reasonable > compromise, and I'd like to know if there are reasons this too isn't > achievable for etch. There may be known reasons, of course -- it's just not > clear to me which of the reasons for not dynamically linking also apply to > statically linking, and whether the issues with static linking might be > surmountable. "statically linking with external ffmpeg" (StaLEF) is another option I investigated; I did not report my investigation to avoid adding too much other noise to the discussion StaLEF is in principle a very nice compromise : it does not make i386 slower; at the same time , it does relieve the security (who just need a bin-nmu, if ffmpeg is ever changed) the only (small) drawback of StaLEF is that there is no easy 'configure' option to do that: you cannot just './configure --slef && make' - it requires some hacking lets come to today today, the ffmpeg inside Debian is 6 months older then the one in MPlayer; for that reason , DynLEF fails . When I tried it, I also tried 'make -k' , to see if there were few failures that I could fix; but the number of errors is too much . lets investigate why it fails Those errors are due to the fact that , in the older-debian-ffmpeg, headers and code are simply too different . One problem I saw is that many 'defines' are missing. So I should 'backport' all the defines in a special file, and include. And, of course, check that they have the same meaning (or, any meaning at all) in the older ffmpeg. Another problem is that debian-ffmpeg does not package a library for the swscale subtree : so if you try to link mplayer with debian-ffmpeg , you actually are linking the new swscale to the old 'postprocess/libavcoded/libavformat' lib, and this is a complete mess. All of the above will make no difference if you try to StaLEF instead of DynLEF to the older debian-ffmpeg : it is a problem of semantic of the calls, and too many cross > Now it's probably not reasonable to require shared linking for mplayer as a > release-critical requirement, especially when there are known problems with > that approach ffmpeg is developed inside MPlayer ; for that reason, they (correctly) feel free to improve it in any way they like. This is clearly stated in the web pages of ffmpeg: no stable api, sorry. MPlayer people are also free to cross-link the two codes: this is AFAICT why DynLEF does disable some features. For the same reason, though, StaLEF will need some scrutiny : for example, I cannot just go into the configure script and hack a few lines to do DynLEF, but then end with static linking: this would still disables all features aforementioned. --- all of the above, of course, to the best of my today knowledge --- conclusion: StaLEF and DynLEF may be done, but it needs time and help; unfortunately, I had few of the former and I did not get any of the latter > Thanks, thank you for the interest a.
Attachment:
signature.asc
Description: OpenPGP digital signature