API Review

What follows is a list of the APIs that the current Linux Flash Player 9 development version is using. I debated whether it was appropriate to publish this information. Then I remembered that anyone who knows what they’re doing should be able to figure this stuff out by themselves anyway once the final Player is released.

  • General graphics: X11
  • GUI elements (dialog boxes): GTK
  • Audio I/O: ALSA
  • Camera input: Video4Linux, API version 1
  • Threads: POSIX threads
  • non-HTTP Networking: BSD sockets
  • SSL: OpenSSL
  • IME: you know what? I don’t think we’ve settled on this one yet…

There are undoubtedly others that I’m missing… dlsym() and friends for dynamically loading shared library functions to avoid static linking of LGPL libraries.

Now that I think about it, how come there are so many layered methods for doing basic A/V operations but one for doing network communication (BSD sockets)? I have searched for higher level general libraries on top of the sockets. I know that some criticize raw ALSA programming as being comparable to ASM for audio operations. BSD sockets strike me as the ASM of network programming.

I would now like to open this thread for readers to voice their concerns over API choices.

Welcome, again, Digg readers. Flash Player 9 for Linux Details Posted by Adobe Insider– sounds so scandalous. I just wanted to point out that the really interesting part of this post are the comments in the thread written by another Adobe insider, Tinic Uro, explaining why rendering graphics in Flash is not as easy as it sounds. Search for them.

153 Responses to API Review

  1. mark pinto says:

    I believe you’ve made good choices. I’m sure you’ll get a lot of complaints for the use of GTK, but the reality of it is that it’s a good choice. Besides, I assume that a large percentage of KDE users have GTK installed anyway and it’s not difficult for those who don’t to install it.

  2. James C says:

    All those things sound like good targets to me. The only hangups may be the use of V4L v.1 instead of v.2 but if Adobe decides to make more frequent releases of Flash player than they have in the past, it may not be an issue (I hope we don’t have to wait years for a new version again).Alsa will probably give the BSD guys a headache, but it’s the better choice for Linux.Do you know if you guys will be able to offer versions with GTK statically compiled to keep the QT/KDE guys happy?

  3. Fernando says:

    Can I suggest ‘ARTS’ Sound Architecture?The linux xine player is a good successful case for this.

  4. Jonathan Ballet says:

    > “GUI elements (dialog boxes): GTK”Do you mean “GTK 1” or “GTK 2” ?> Fernando :ARTS is dead, so it’s better to stick with Alsa (or another multimedia framework, why not)

  5. cartman says:

    All I can say, GTK+ oh my god! Good luck with_that_weird_long_api . Qt anyone? Adobe owns Qt licenses did you know that? 😉

  6. mark pinto says:

    I’m a bit curious as to why you picked ALSA over GStreamer, considering that you went you also went with GTK

  7. Tristan Wibberley says:

    I think V4L1 may have been formerly deprecated. You should check that – the player may be partially non-functional in a years time.For higher-level networking, I think glib (the gtk support library) has a network library – gnet. Not sure how standardised it is yet, though.gnet seems to have windows support too, so there is now *one* standard GUI and network library for both Linux and Windows (GTK+GNET) – that could save you some money in the future.

  8. Kevin Krammer says:

    glib, which you are already using through GTK+ contains a socket abstraction if I understand the API docs correctly.Since most of the APIs on Unix are in C, there is often no abtraction needed, while there is usually always an abstraction API or binding for other languages like C++, Python and so on.

  9. Ondra Hosek says:

    Sounds like a bunch of good choices to me too.For finding out which libraries are used, ldd (for the dynamically) and nm (for the statically linked ones) have told me quite a lot. On Mac OS X, it’s otool’s job. They also have an strace equivalent, ktrace, but I think strace is much better.

  10. Rene Horn says:

    There are APIs that sit on top of the BSD sockets, but they can be a little hard to find because they’re usually a part of a package.If you haven’t written too much networking code yet, you might wish to check out SDL_net.

  11. Jure Repinc says:

    I think that these are very good choices. And in this case I would also say that GTK2 (I sure hope it is not GTK1) is a better choice since most people will use Flash player in Firefox browser which is also GTK2 and it will feel more integrated that way. Other then that I found Qt to be a lot easier and nicer to work with, when I tried to learn one of the Linux GUI toolkits. But then again if programmers at Adobe working on Flash already know GTK well I guess it would only delay things if they needed to learn Qt in addition to all work.

  12. Arren Lex says:

    Sounds good to me, assuming you mean GTK2. Personally I’m a KDE user and prefer QT from an integration\eye candy\end user standpoint, but since Firefox is GTK2 you’re better off with that toolkit for flash. Definitely looking forward to the ALSA sound sync goodness! Don’t listen to the guys asking for aRts and GStreamer – aRts isn’t that great and I think development has largely stopped, and I for one think GStreamer is another set of unnecessary libraries on top of the same old thing and don’t have it installed. You’ve made good choices for the widest compatibility, IMHO (although of course the best way to make it as compatible as possible would be to release the source 😉

  13. Tinic Uro says:

    Both GTK1.2 and GTK2.x are supported, you can select specific .so you want through an environment variable (FLASH_GTK_LIBRARY).Otherwise, by default it will look for ‘libgtk-1.2.so.0’. If that fails it will look for ‘libgtk-x11-2.0.so.0’ and then finally for ‘libgtk.so’.

  14. DannyB says:

    For GUI elements, I hope you are using GTK2, as people are now finally getting rid of the original GTK. For camera input, V4L will be out of the kernel likely before the release of Flash, or close to it. A better idea so you don’t have to tie yourselves to Linux and V4L2 is to just use GStreamer. Same for audio with ALSA, as some people want arts, some want OSS, some want pulse audio, etc… using GStreamer for the audio output will have their system automatically use the correct audio output system. As others have mentioned, GLib also provides network abstraction, but BSD sockets also work fine for it. I hope you guys choose GStreamer and make it easier for everyone to have Flash ported to other platforms like BSD and Solaris, without you guys having to do it yourselves, without having to make anything open source if you don’t want to.

  15. Sam Morris says:

    Three comments:1. V4L version one is not very useful. According to Linux’s feature removal schedule, it is just about to be removed from the kernel entirely.2. Please use GTK 2.0 in preference to GTK 1.2!3. What’s with the dlopening? I’m not sure why you don’t just dynamically link to the libraries in question. Using dlopen will not affect the extent to which the Flash plugin binary will be considered a derived work of the libraries you use; Is there a technical advantage that I am not seeing which outweighs the additional complexity and fragility of doing all your library linking by hand, at runtime?

  16. @Sam Morris:We go the dlsym() route because, per my experience, if you rely on the OS to do it for you, and a particular library or function does not exist on the system, the dependent module will not load. Thus, if the user does not have ALSA installed, the plugin will simply — and silently — fail to load. It gets to be a philosophical matter– is it better for the plugin to silently fail, or to proceed but not play any sound? There will be tech support issues in either case, but I think the latter option will be easier to diagnose.

  17. jimbo says:

    why would you try to load gtk1 before gtk2? gtk1 = legacy apps only. if you can use gtk2, go for it.

  18. @jimbo:Actually, Tinic was a bit off. The policy, after checking for that env var, is to query the library loader for GTK’s major version number and load the appropriate library, 2.0 or 1.2, as indicated.

  19. llp says:

    I still beleave that Adobe would help GNASH instead of create a flash player for linux. It will won nothing with that non-free flash player.

  20. Chester says:

    My only “concern” is, as stated above, video for linux 1, which is being almost completely removed from the kernel, also stated above. Also, go with GTK2 for sure.The rest of the choices look good. Most “modern” distributions come with both GTK and Qt nowadays anyways, with GTK being favored as more of the standard.The same for the sound, most modern distributions use ALSA here instead of OSS. As far as I know, ALSA and OSS are the only two sound layers on the same level. The rest (GStreamer/Arts/ESD/etc.) Sit on top of either ALSA or OSS, and are mainly in existence to make multimedia processing easier.As always, keep up the good work, I look forward to seeing the release.

  21. Justin says:

    I don’t know a whole lot about this stuff, but why not use OpenGL for the graphics? If I’m being stupid, let me know, but it seems like that would be a better choice because it supports hardware acceleration where possible and mesa where not.

  22. Bloody says:

    I’d say nice choices. Except for V4L version 1. That is getting a bit old and if it’s flagged for removal, shouldn’t probably be used. On the other hand, more conservative distros may not have V4L version 2 compiled in yet.And if glib has network support, I think that perhaps it would be a good idea to check it out as it would bring consistency to the whole thing. More glib and gtk yay!

  23. Anders Aagaard says:

    no complaints at all, aslong as we get it and it’s possible to get it to work properly (without MAJOR bugs, like the current player’s A/V desync) we will figure it out. And there will be tutorials all over the web on how to get it working.

  24. FunkyM says:

    – You might consider GStreamer for the multimedia parts (Audio/Camera/Video?). It is an upcoming standard, not bound to a desktop, abstracts stuff away for you and enables people to use present or future backends of their choice (v4l, v4l2, alsa, oss, sunaudio…) without you having to bother about it. Roughly think of it as the “DirectX” (/slapmyself) counterpart. The Linux “Desktop” was missing a decent unified multimedia framework for quite some time…- Graphics: X11While there might be ideas to use cairo or derivates for the vector rendering, Flash’s range of graphical requirements prolly applies best onto a(/the already present?) custom renderer. However sure something to revalidate as soon as the F9 player is done. I guess it’s a general question for Flash to finally use some acceleration on each platform (OpenGL, Cairo on glitz, …) and not bump the CPU graph. ;)- GUI: GTK2Guess it is the best for both GNOME/KDE worlds and blends fine with Firefox ;)- Audio: GStreamerGST Gives people the choice to choose their audio backend and integrates with modern linux desktops.- Camera: GStreamerSame as with audio; people can choose the backend of their choice and you don’t have to update stuff nor care for any kernel removal of v4l(1). Also seems correct in the longterm.- IME: Clueless… Anyone? Something in GTK?… rest looks ok. If you stick to your current setup just try to use v4l2 and check glib/gtk/gdk for other stuff you might need.

  25. Paulo Matias says:

    Very good choices, excepting, as said, v4l1. 😉 Please use v4l2 and gtk2.About the sound library, it’s best to use ALSA. If you use GStreamer, it’s one more (really big) dependancy you would put in the package.I found interessanting the commentary by Mike Melanson. I had no knowledge of the existance of gnash. It would be great if Adobe put his developers to help gnash instead of writing a closed plugin. But I know it is out of control of you developers.Maybe us users could create an undersigned for convincing Adobe that an opensource plugin solution would be most lucrative for him (turning easier porting and spreading swf to new platforms). 🙂

  26. C. Sawczuk says:

    The choices of API seem fine, apart from the V4L which is meant to be deprecating soon.However, I know your working on the new flash player and such, and thats great, but, if it is meant to be release some time next year wouldn’t it make sense to just upgrade the current flash player to fix the crippling A/V sync problem right now? I’m not sure how hard it would be to fix, but it gets damn annoying having to right click, and then pause and play.It sucks not being able to see alot of the new flash content out there, but for a crutch till the player is out and ready, having A/V sync would be great.Also, using GTK+2 would be the gui wrapper to use I believe, as it is the lightest compared to QT and its LGPL. Just saying. It is possible to create a simple dialog application in under 20 lines tops.Good work so far.Chris

  27. EnviroTO says:

    Makes sense except for the V4L1 choice over V4L2.

  28. Tinic Uro says:

    @JustinOpenGL is not a good option right now for browsers. Imagine every small .SWF in a HTML page using up a full OpenGL context. Every single OpenGL context uses up a lot of resources and requires some time to start up. So every time you would go to a new page you would have to wait a second for it to initialize or wait several frames for an existing context to be updated for the new location. Talk about a bad user experience.In addition you end up with scrolling synchronization issues (since the rest of the web page is usually straight X11 and OpenGL does not work together well with the X11 scrolling APIs).It would also be a nightmare to fix your system if something is wrong with your browser or OpenGL installation. OpenGL still works best for dedicated full window or full screen applications.Ideally browsers should provide native OpenGL support before the use of it makes sense for something like the Flash Player. For now we try to stay as compatible as possible with browsers out there which still assume that plugins only do X11.Obviously our long term goal is to made advances on this front. We understand that OpenGL offers performance benfits in specific areas.Currently we use XShmPutImage as the main blit function, with XPutImage as a fallback if the Shm extension is not available.As for using OpenGL to render the vectors, there are not too many cards out there who can currently handle that in an acceptable fashion. It’ll work for simple movies (a few squares and circles maybe), but as soon as you add loads of vector text the software renderer is still faster. We have done extensive tests on OSX to show this. In addition designers are very particular about how their content renders. Every pixel counts for them, so we have to get as close as possible to what they expect. This is something you can’t rely on with the current generation of cards which people have out there. We can’t ask everyone to buy new graphics cards just for Flash.

  29. Paulo Matias says:

    What about Cairo? It draws vectors with antialiasing etc. Perhaps Gtk2 uses it for widget drawing, and it uses OpenGL acceleration when available, via Glitz, otherwise falls back to software rendering.

  30. Anonymous says:

    For an IME I would just like to put my vote for SCIM.

  31. Mait says:

    As I know, Ubuntu, Fedora … use SCIM as there default multi language input.SCIM support so many languge via its plugin module style. I heard that It use XIM protocol.Care about XIM, SCIM for multilanguage input.

  32. Tinic Uro says:

    @PauloCairo is not fully compatible with the Flash rendering engine. As I said designers want pixel level accuracy, nothing less, including ALL the rendering bugs Flash has as strange as that sounds (one famous example: http://www.misuseit.com/bitmapbug/). We version check EVERY change in the renderer so that old SWFs will not look different (we got into big trouble many times for ever so slightly changes we made, even if they fixed a bug). While it would work great for simple animations, we would run into countless of issues with current content out there as users really fiddle with every single pixel. 95% cross platform compatibility is what matters for us, that’s the main value of Flash IMO.Flash 8 makes the situation even worse because of new rendering features cairo does not have (filters like blur, drop shadow etc, focal point radial gradients, stroke pixel hinting, SVG like blend modes etc. etc.). All of this would have to be redone in some form or another.I believe cairo uses a painters model for rendering meaning shapes are drawn on top of other shapes (never looked at the source though) vs. Flash which is using a scanline based renderer, e.g. no scanline is ever touched twice during the rendering process. This has implications, making content look vastly different in some cases (did you know that Flash has a 12 layer limit per scanline span f.ex. and drops any additional ones?). The devil is in the details, not the high level APIs.The software rendering performance of cairo is not what Flash can do on the desktop last time I checked (at least on Windows and MacIntel. FP7 on Linux was absolutely terrible in that regard, I admit. It essentially had NO optimizations, even the gcc options were not ideal for this code. :-(I am really not trying to dismiss cairo here, it’s a wonderful library solving a lot of cross platform issues. Cairo works perfectly well for a _lot_ of purposes and I believe any SVG implementation should use it.

  33. kz says:

    Using gtk2, never worry about input method. gtk2 itself support multiple input modules that is changable at runtime. Mentions about SCIM or whatever are out of coverage. It’s up to each end user.If with gtk1, don’t mind too. gtk1 only support XIM. (And please don’t use gtk1 as possible :p)

  34. Tux says:

    V4L version two please. It’s pointless to code to a deprecated API. V4L v2 already works just fine … I have a PVR card and 1.3 megapixel webcam using it.If GTK*, absolutely positively use GTK v2… or FLASH WILL NOT WORK ON ANY SYSTEM WITH XGL INSTALLED (b/c GTK v1 does not to transparency). You’d have to use crazy launch tricks to get Flash working in XGL on GTK 1.* From my brief poking around, QT seems alot easier to learn and code … you a masochist? It’s like the Python of GUIs… easy yet powerful.

  35. Greg Loscombe says:

    Great news!However, personally, I’m a QT fan so its disappointing to see GTK used over QT. Hopefully it will be static linked.

  36. Apreche says:

    How about SDL?

  37. Kulin says:

    Nothing mentioned about 64-bit version of flash player 9 yet. Is it gonna happen or not? 🙂

  38. Just want to ask if this will be available for 64bits linux. Will you make a 64 bit version?I can´t say anything about your API choices since I don´t understand too much about it, sorry.

  39. lezard says:

    Using GTK is quite a strange option, given that Adobe uses quite a lot QT. What’s more, given that QT>4.2 integrates very well under KDE and GTK based DEs, this would be much better. Using GTK means it will not fit at all under KDE, and will be very weird under konqueror.

  40. Jon says:

    All good with the exception to ALSA. Use Gstreamer. There will always be some odd-numbered person who needs to use a certain back-end for whatever reason and every user should be considered to be as important as every user you have.I can see quite clearly nothing there is processor dependant. So there sure as hell be some PPC PPC64 and SPARC ports.

  41. 1c3d0g says:

    Agreed with the people that say “go for GStreamer”. Amarok, BMPx, Totem, etc., almost all of the audio/video players out there have a GStreamer back-end as an option or are working on implementing one. Please consider this option very carefully. The rest looks great IMO!And don’t worry about the people complaining that the player should be Qt, they can always use the QTK-Qt theme engine. ;-)http://www.freedesktop.org/wiki/Software/gtk-qt

  42. Jesper T. says:

    Why not use Qt? It can help you with some of the network stuff as well 😉

  43. Anonymous says:

    * GTK is a good choice considering firefox uses GTK2. though using GTK1 instead of GTK2 would be shooting yourself in the foot. it would be like buying a brand new car… from 1987.* for IME use GDK (part of GTK). you are already getting your hands dirty with GTK, so use it’s input methods. with GDK you can have any kind of input there is and it’s easy. support for keyboards, joysticks, tablets and rocks, very small rocks.*** did i mention that GTK/GDK is cross platform? **** ALSA for audio was a _GOOD_ choice. i think the jillions of comments to use ALSA in the original post got through. horray!* the camera support seems a trivial feature to me but V4Lv2 is a much better choice than V4Lv1. i would make this a very low priority as ive never come across flash that needed a webcam.

  44. Super Carrot says:

    Please be aware, that posts on Digg are user created and driven. Changing your title wont make any difference. Its like just Slashdot but not edited. When a user likes a story they “Digg” it. This will draw more traffic. If they dont, the “Bury” it, this will bury the story. Its a great site, but I can understand if you have been on the wrong side of it. Not very much like fun, not for a serious site like this one.

  45. Stoffe says:

    Well I would like Gstreamer for input/output as this is where the future seems to go for Linux desktops in general. As long as you use ALSA and sync is good though, it’s ok. ;-)Otherwise I don’t have much comments, ppl have already warned you about v4l.Looking forward to this, when can we look forward to an alpha to test (please)?I’m currently running Flash 9 via CrossOver Office, but that doesn’t work at places like Youtube that tries to autodetect with flawed methods (the player works just fine).I really look forward to a native version, and while I would much prefer it to be open, I respect that this is not your descision.

  46. Jacob Brown says:

    For video out, audio, network you could have just used SDL. Also, the nice thing about SDL, is it ports to almost all platforms…

  47. Levi Durham says:

    I’ve setup Japanese input support on a number of distro’s (Mandrake, Slackware, Gentoo) using SCIM and whatever it was that was recommended before that came out. In my experience XIM has always been the fallback option, as it is part of the X protocol. IIIMF [www.openi18n.org/subgroups/im/IIIMF/]seems to be writing a replacement, but it looks doubtful that it will be included in the 7.0 series of X.org releases. (According to a PDF in Googles cache, Sun seems to be pushing IIIMF).

  48. Peter de Kraker says:

    Looks all great.Only think you really should use GStreamer instead of ALSA. It is thé upcoming multimedia framework for linux, and allows people to choose their audio backends.Anyway, you should definately look into GStreamer before deciding not to go with it, since allmost all multimedia projects are starting to use it.Thanks for the update, looking forward to the alpha!

  49. mOrPhie says:

    I would’ve picked gstreamer or xine. That way you support al backends supported by gstreamer or xine, which are a lot, plus the fact that it supports software mixing, which standard ALSA lacks.

  50. If you want to have binaries that work over various distros…1) Stick with the versions of the APIs based on the latest LSB Core and Desktop standardshttp://www.freestandards.org/en/Specifications#LSB_3.12) For APIs to modules not part of the above standards, create a separate dynamic link library with functions that call/get/set the platforms module, that links to the underlying dynamic library module.Distribute the bridge module DDL with flash, but also release the source code for this bridge library under the LGPL, so that other/future linux distributions can hack the bridge code and replace the DDL.

  51. Bert says:

    As a couple of people said, V4L will make video-input impossible in near future. V4L2 is to be targeted.

  52. Mike Hearn says:

    A few issues to bear in mind:- You WILL get bitten by using any C++ dependencies. Qt, SCIM can cause problems. The GNU C++/ELF ABIs are not well thought out. Random crashes will be the result. So, best to stick with C based things for now … GTK is good, GStreamer is good, Qt/aRts not so good.- For IME if you can, it’d be good to let GTK handle it. There are many IME engines out there some better than others for different languages etc. I understand this may be difficult to integrate with the Flash movies …- Avoid GTK 1. Quite apart from the fact that GTK 2 came out years ago there will be _VERY_ weird issues with mixing them in the same process. You really don’t want to go there …. eg consider a Firefox linked against GTK 2 for theming then dlopening GTK 1 – this is an unstable configuration and will crash on some systems. For same reasons as C++ will cause issues.If you want more details on this email me.

  53. I am really impressed with both the Adobe guys for being more open about the development process, and the commenters for keeping the trolling to a minimum.It would be nice if Adobe could release some sort of stop-gap crashy plugin sooner rather than waiting until it is perfect in 2007. I’m running in to more and more sites every day that claim I don’t have flash installed or require a later version than I have. As a developer I can understand the desire to avoid mountains of support emails, but pretty soon I’m not going to be able to browse a lot of popular sites (Project Runway :().If possible, it would be great to have a parallel-installable plugin for Flash 8 and 9, and if the movie requires version =8 it could launch the new plugin. The new plugin could pop up an annoying “do you want to load flash 9” box every time, in case there’s a site where flash 9 is unnecessary but it crashes the plugin. That way linux users can at least browse web sites, and perhaps even help by filing bugs on sites that crash the plugin.

  54. kris says:

    Have you guys looked into making a xara backend? According to this: http://www.xaraxtreme.org/about/performance.html it’s muuuch faster than both gdi and cairo. Admittedly that was taken with cairo 1.0 and it’s now at 1.2 i think so maybe it’s not representative anymore, then again maybe it is. The wonders of opensource 🙂

  55. Danny says:

    > Can I suggest ‘ARTS’ Sound Architecture?> The linux xine player is a good successful case for this.This comment reminded me…I use Xine/Kaffeine and Flash 7 for watching videos. I can watch flash videos just fine. As soon as I have a flash video player still open, but launch Kaffeine (using Xine) the flash audio will no longer work until I close and re-launch FireFox.Whatever you do for sound, please, PLEASE make it compatible with Xine (and probably also mplayer, which I may use in the future).

  56. John Bloch says:

    Will you provide a PC-BSD version of the Flash Player?

  57. I’d also like to voice a preference for SCIM.

  58. kevin kricfalusi says:

    Yeah I am just another person making a suggestion ;)Video4linux is pretty much removed from the kernel “yes” but v4l2 is what is there now, despite what people are saying. Many projects are going to move that way pretty soon and drop v4l1 and go 2. But then again it probably would stop being supported by around the time flash 11 comes out so you could wait till the next release of flash4linux 😉 thanks for helping us little linux guys out. Keep strong man!

  59. fury says:

    I would suggest jack audio support as well as full ALSA DMIX support.Too many programs out there dont adopt this and it makes using sound a chore already when using more than one program to access sound.My $0.02.

  60. Abraham Al-Saleh says:

    Why not save yourself a lot of trouble and use sdl to do most of the abstraction for you?SDL website

  61. AL13N says:

    – V4L 1 may be officially deprecated, but i don’t think all camera’s are V4L2 compatible yet… so, maybe you should try to support both ( or at least consider that V4L2 will be a must within 2 years, so you could try to get as portable as possible making the next version easily done).- scim is the most used one, but GTK2 supports this transparently.- alsa is a good choice, this way you don’t have to go too high level to get sound output. if you need lots of codecs you might want to think about using libxine- you might also want to think about ntpl instead of just posix threads, it’s mostly compatible, and with a little effort both should be ok… (not sure about kernels compiled with ntpl)- openssl is a nice way of basic SSL supportIMPORTANT NOTE: PLEASE let it compile under x86_64 !!! been waiting for at least 2 years to properly use a 64bit browser… (except for java, this is the last 32bit plugin)

  62. nonnano says:

    Yes, thanks for screwing up *BSD and Solaris etc users completely with your choices. Then talk about using BSD sockets, ahh the sweet irony of that.

  63. Niomi says:

    I’m just releaved you used the phrase ‘once the final Player is released’ instead of ‘if the final player is released’. I was getting worried at your last couple of posts.

  64. Cláudio Pinheiro says:

    You should support both V4L and V4L2. Older kernels and modules support only V4L, and soon V4L will be dropped from main kernel.Depending on your release schedule (if bigger than 6 months) maybe supporting only V4L2 would be a wise solution.I have developed V4L and V4L2 C++ code for an open source project that’s able to detect the correct API and communicate with a video capture device. If I have any means to help (coding, licensing my code for free or whatever) please make contact to me.

  65. Joseph Cole says:

    It looks like you are reinventing the wheel. I would suggest utilizing gstreamer where possible:* General graphics: Gstreamer – provides X11, XV, SDL, OpenGL, AA, etc.* GUI elements (dialog boxes): GTK (GOOD. Consistent with Adobe, Real, Vmware, etc. QT requires a paid license for non-GPL software)* Audio I/O: Gstreamer – provides ALSA, OSS, ESD, ARTS, etc.* Camera input: Gstreamer – provides Video4Linux 1, Video4Linux 2, custom inputs, etc.Another bonus to using Gstreamer is porting your code to other architectures should be easier. Gstreamer already runs on alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, and sparc.

  66. Alex Lowe says:

    Thank you for your well-considered choices.In response to some of your choices:General graphics: X11This is probably the best choice for what you’re doing at the moment, however I believe that sometime along the line OpenGL will be a better choice. However, No complaints from me here.GUI elements (dialog boxes): GTKOkay, I personally would have chosen Qt 4, but it’s really up to you. But perhaps it would be good to make future versions of the Windows and the Linux versions both in Qt (relatively little work converting). This is why OpenGL might be better in the future. Still, even though I’m a KDE person, no complaints, as GTK works just as well as Qt (not that I’m ever going to try programming with it again).Audio I/O: ALSAThe obvious choice (in my opinion). OSS is depricated, aRTs is too KDE-ish (and works on top of ALSA), others are specifically for other DEs. The only other possibility would have been Jack, but it really doesn’t matter to me.

  67. Sudrien says:

    There has been several recomendations for SCIM, but I would suggest looking into UIM (which does have compatibility layers with scim available) for input. It automatically overides the default GTK input mode.

  68. Simon says:

    For all KDE/Qt users asking for GTK2 to be statically linked, I think/fear you mean that you want Adobe to distribute them as a part of the package? (because, generally, libraries *are* statically linked, ie linked with ld at compilation time, as opposed to dynamically linking with ld.so or a wrapper such as libtdl). I might be wrong in my understanding [maybe you were saying this because you don’t want GTK2 to be dynamically linked, in fact I’m not sure if dynamically loading a library with ld.so will duplicate it in the memory if it’s already loaded by an application that is statically linked to it, but I don’t see why it would..!] if so, please excuse me), but if that’s the case, thanks for asking Adobe to increase the memory footprint of Flash for 50% of GNU/Linux users.Anyway, for KDE/Qt users bitching about GTK+’s choice, may I remind you that GTK2/GNOME is the default configuration on the 3 biggest desktop oriented distributions, namely Fedora Core, Suse, and Debian Ubuntu. May I remind you that even amongst KDE-based distributions, most use Firefox (which means they already have the GTK2 libraries loaded when using Flash). Now, I don’t know much about Konqueror, I hope Flash9 will be tested against it for you KDE users, yet the Konqueror users are far outnumbered by Firefox users. On a side note, KDE users often have the GTK2 libraries (this is even the default configuration in many KDE-based distributions), while we GNOME/Xfce users rarely have any Qt library (thanks God I am totally free of Qt ugliness ;P). Btw, maybe Adobe has some Qt licenses, but not only those licenses are not per company but per developer, but Adobe also used GTK2 in Acroread 7 (which is quite good imho, except that ugly icons bar). My point being: yes, GTK2 should definitely be linked statically against Flash (but GTK2 shouldn’t be distributed along in the package), there should be no GTK1 support (a distribution with only GTK1 won’t support ALSA nor Gstreamer anyway, and Flash without any sound sucks anyway).Now about GStreamer, come on people, are you that selfish for less than 5 Megs (on your hard drive) of a lib that would allow *BSD and OpenSolaris people to get sound working on Flash, that would allow everyone to choose his favourite backend (audio and video sink, meaning no problem with V4L’s version)? It’s not a KDE vs GNOME vs Xfce argument here, Gstream (even if it’s using Glib) is a freedesktop.org project and is used in KDE as well. All new desktop distributions will include and support it, so get used to it, it was definitely needed. I am all for using ALSA in the end, but may I remind you (yes, once again! 😉 I just love to) that it means Advance *Linux* Sound Architecture, and Flash being portable to other free *nix OS’es is a Good Thing(Tm).Now for Mike Melanson, I understand why you’d want to use the dynamic loading of libraries to keep Flash running if a non-mandatory library (ie, providing sound) is missing, but in your posting, you were first talking about LGPL’ed libraries. Well, linking (either statically or dynamically) with LGPL’ed libraries isn’t considered as derivative code (that’s where there difference with the GPL lies), so I really didn’t understand that part. You can freely statically (ie, normally) link at least mandatory libraries (ie X11, GTK2 [if you drop that useless GTK1.2] and NTPL [which both are LGPL’d]).All-in-all, those are good choices, and I wish you good luck :). I can’t wait to get a decent version of Flash running.

  69. As a GNOME user, I’m happy with the choice to use GTK+2. However, if this is being developed in C++, QT would probably be a more appropriate choice than gtkmm.ALSA is definitely the best way to go. It’s the backend that everyone supports, KDE, GNOME, *box or whatever.V4L1 is probably going to be a mistake. Selfishly, I own a macbook and its iSight is only supported by V4L2 drivers, so I think that’s a better way to go.Good luck, keep up development!

  70. Jeremy Harmon says:

    I’m just curious how far behind the Linux player is to the current Flash 9 beta?

  71. I would recommend using boost, it has async network ioasio.sf.netwith openssl support. It has support for portable threads:http://www.boost.org/doc/html/threads.htmlAnd alot of other usefull libraries, look at:www.boost.org

  72. Francisco says:

    Video4Linux 1 is deprecated and won’t be supported any time soon. Please switch over to version 2!

  73. Sterling Christensen says:

    Looks good.What if the loader is Opera or Konqueror (ie a QT browser with no GTK major version)? I suggest that if that env var isn’t set and it can’t figure out the loader’s GTK version, that GTK 2 be the default. GTK 1 is ugly and doesn’t work well with XGL.BTW, OSNews has also linked here:http://www.osnews.com/story.php?news_id=15284

  74. Peter Czanik says:

    Any chance to see Linux PPC support this time? Java browser plugin is coming slowly from IBM, so the only remaining road block for wider Linux PPC desktop acceptance remains Flash support.

  75. k. lewitz says:

    Choice of APIs is fine!- Gtk+ 1.x supported is unneeded, even embedded applications have switched to Gtk+ 2.x- V4L 1 support is scheduled to be removed from the kernel in favour of V4L 2- Glib (which is a dep of Gtk+) does provide some support for sockets, whether this is meaningful for Flash Player 9 I don’t know, seehttp://developer.gnome.org/doc/API/2.0/glib/glib-IO-Channels.html- You don’t have to worry about IME support, Gtk+ handles this. See also:http://developer.gnome.org/doc/API/2.0/gtk/gtk-running.html(look for GTK_IM_MODULE)Vanilla Gtk+ ships with several IM modules, other IM products (such as Scim, which is the most popular solution for CJK input) provide their own Gtk-IM modules

  76. RQ says:

    This all sounds like you won’t make us wait till 2007. Thank you so much! 🙂

  77. Jesper says:

    I’m wondering if SDL couldn’t have worked for you as ‘one common API for it all’. It does Networking, Sound, Threads, etc etc, with a n OS neutral API. And it’s a damn fast library to boot.

  78. Ali says:

    That’s really good to hear that a new flash player will be coming 🙂 and that’s a really good job, but I’d like to express some remarks :- It would be really great if you could help gnash people 🙂 Maybe you can share some LGPLed code ?- Using Gstreamer instead of alsa and v4l would be great ! Gstreamer is actually not bloated, and gives the user tha ebility to choose what he wants to use as backend (think of people willing to use pulseaudio or oss … ?)- for networking code, maybe you should take a look at Flow (http://hpj.blognaco.com/2006/06/20/garbage-in-garbage-out/)??? The glib contains some basic IO management (GIOChannel), that you could use for async networking.Anyway, thank you for your work 🙂

  79. Eugenia says:

    Please ALSO support Video4Linux v2. Many new cameras only have drivers for the new API, while others for the older API. Please support both!

  80. [Knuckles] says:

    I agree with the people suggesting Gstreamer for input and output: it’s much more flexible, and much more workable than alsa and v4l.Also for IME I’ve used SCIM and I think it’s the most used in current distros.

  81. Thomas says:

    I vote for QT! becauze its sooo Qute

  82. Looks good all around. I agree that all the multimedia stuff should be in gstreamer. You could then write it this once, and for the most part forget about it for subsequent releases. Think of it as the grease between two blocks (one being flash, and the other being alsa/V4L etc.) I like QT better, but GTK2 is perfectly fine also. I hope this comes together very soon, it will really make the web a better place for us Linux users. And thank you, and Adobe for paying attention to linux/Open Source users, we all appreciate it.

  83. t3RRa says:

    I hope that you could use more cross platform libraries so that the flash can be compiled for several platforms out there like BSD and so on. I know the blog is for linux version tho, as you said “95% cross platform compatibility is what matters for us”, I hope from version 9, flash could be supported on BSD natively too (yeah, I am a big fan of BSD :p) but anyway, I think this is one of the great news(or blog entry) recently. thanks.

  84. Nael says:

    For all of you begging to switch the audio API to GStreamer: I really don’t think it’ll happen.First, ALSA is included in the Linux 2.6 kernel. GStreamer is an external library that probably isn’t included on lighter distros. Everyone has a Linux kernel, but not everybody has GStreamer. Second, he’s already implemented the ALSA audio backend, and I’m sure having to tear down what he’s already done to support another API that a user may or may not have is not at all inviting, and may introduce a whole new set of bugs that may delay the plugin further. With all the progress he’s made, rewriting the audio to use GStreamer would cause more problems than it would solve.And as a KDE user, I really don’t mind using GTK. GTK-Qt exists, so it’s not going to look out of place. As long as it’s GTK2, it’s all good.

  85. Joseph Garvin says:

    I’m curious — why do people think GTK would be weird in KDE? No matter how adamant a KDE user you are, you’re going to have some GTK apps installed. I know no one who runs a pure QT environment. The same goes for Gnome, even the most vehement GTK users usually have QT/Kdelibs installed so they can run K3b or Amarok.It seems like even more of a pointless debate given that flash as far as I can see has very few UI elements. It’s basically a popup menu when you right click the applet and that’s it.

  86. Gary says:

    @Nael,The reason it’s an issue is there ARE some out there that want a fully Qt based desktop. I personally cannot count myself as one, but I do know a decent amount that have that view.

  87. Anonymous says:

    Another reason to use GStreamer is that people are writing nice sound policy management tools for it. There’s at least two of these, http://live.gnome.org/GSmartMix and I forget the other. Anyway it will be very nice to have flash audio fade out or pause when you answer your VOIP phone, respect volume controls, that sort of thing.

  88. tkng says:

    Gtk+2 itself has the feature for input method which called immodule. It would be best to use immodule for input method, because1. immodule has a simple and easy-to-use API.2. next standard of XIM is not known yet.3. all of next standard candidates of IME correspond to Gtk+ immodule.For Gtk+1… I guess it would be enough to support only XIM.

  89. michael says:

    No QT. No Arts. They both suck, and are big pieces of bloatware.GTK+2 and Alsa are the way to go. KDE fanbois should realise that they already have GTK+ installed, and don’t even need a static build of it (why bother, it’s just extra bloat to make it static). A lot of the KDE fanbois use Firefox anyway, which is GTK+2.I’m supportive of the choices made however I too think some of it could have used SDL instead.

  90. Dan Roberts says:

    I second the vote for Cairo. Things that cairo does not have can be addressed other ways. “(filters like blur, drop shadow etc, focal point radial gradients, stroke pixel hinting, SVG like blend modes etc. etc.).” blur can be implemented through openGL or even a simple framebuffer effect. drop shadow can be accomplished through a gradient + a shape on a layer below the shadow caster. Though I can’t speak for cairo’s speed because i’ve never actually used the API I do know that any FEATURES it does not posess could be implemented in other ways.If the result of cairos shortcommings is that the flash player ends up using proprietary vector rendering, it would be nice if the rendering library was GPLed(wishfull thinking probably) but it would be great.cheers-Dan

  91. Franck says:

    Gstreamer will be easier for you to handle and probably a better choice for the next releases.It aims to unify the Linux Desktop.

  92. Benjamin says:

    > Now that I think about it, how come there are so many layered methods for> doing basic A/V operations but one for doing network communication (BSD> sockets)?Maybe because the BSD sockets API is very familiar for us, so very easyto use. Plus it’s portable and “universal” (in posix-land, I mean), sothere’s no special needs for a wrapper.At the opposite, A/V suffers for differences among Unix platforms andevent kernel versions (audio drivers, sound servers, codecs, etc.), andthat’s where an abstraction layer make sense.Sadly, those came too late so none became standard (maybe soon, withgstreamer through LSB then ISO ?).Anyway there’s some abstract layer for sockets too, like SDL_net,or in Qt (if you had gone the Qt way).About the choices you exposed: they’re pretty unixish, and good ol’timers,you can’t be wrong with them. Except one.Using ALSA directly is a poor choice that’ll bite often the users. Usingan abstraction layer among audio driver would make sense no ?Some short insights about this:- Not every ALSA driver has I/O multiplexing. That’s already a problemwith the current, OSS based, flash version: you get hanged, I/O waiting,when you try to access concurently to the soundcard.For some users it will prevent launching a sound sever (like esd, aRts,etc.) or simply playing musing while navigating with Flass. Odd.- ALSA is very specific to Linux. There’s no ALSA in FreeBSD, Solaris,OpenBSD, NetBSD etc. so if you use it directly, you loose any chanceto work on those platforms any time (or you make it harder for themto use Flash through Linux emulation layer).- If Flash used an opensource, community maintained A/V abstraction layer,it would allow use to evolve, change the lower level APIS, use newdesktop paradigms (like new sound servers etc) without breaking Flash(that we don’t maintain, so we couldn’t help). And distros would havemore chance to get what’s needed right to have a working Flash.- Some (few) Linux audio drivers still uses OSS ; abstractions layersdeals transparently with those (and off course with the other OS’saudio drivers API too).Did you get a look at Gstreamer or Polypaudio, for final audio rendering ?(the former also provide a good abstraction to get video input, likewebcam etc. on a platform independant manner, and handles v4l2 too).

  93. stl says:

    Two points make me conserned.V4L API’s version that is deprecated and will be removed from kernel.The sound API. IMHO you could use some intermediate layer. It could be for example gstreamer or libao which make it possible to choose between: oss, alsa, esd (mixing!) and some other output channels without having to support several different APIs.

  94. stl says:

    I would have forgotten. Please make the new player available for x86_64.Best regards

  95. Jason Tokarz says:

    As much as I prefer QT over GTK, I suspect the choice of GTK over QT is that the QT library is only available as GPL or commercial, whereas the GTK library is LGPL and as was previously stated, Flash is not going to be open sourced for the foreseeable future.As for audio/video I agree with others who have recommended GStreamer.

  96. Samuel says:

    Why not load V4L version 2 dynamically, see if there is any working camera, and if not fall back to V4L1?Other than that I think you have made the right choices!By the way, will transparent SWFs be supported in version 9 (if supported by the browser of course)?

  97. René says:

    Why don’t you stream the sound-data to gstreamer? But if you do so, you have to keep it up-to-date until gstreamer is stable.If you are lazy and are not planing to work more an the linux-version than years ago, just use alsa…GTK2 is a good choice, because KDE-User can install the qt-theme for gtk and have their own look an feel.It would be great, if you use a license, which allows distributions to put it into their native package-format und please compile it for many platforms (x86, x86_64, PPC…) or release the source-code..

  98. René says:

    Why don’t you use cairo for rendering? It has support for anti-aliasing and will be able to render via opengl…

  99. Michael Collette says:

    As a FreeBSD desktop user who presently still uses flash 6 under Linux emulation, the ALSA choice is a bit of a concern. Still hoping for a real native version for FreeBSD, which a dependancy on a Linux kernel module will obviously never allow, nor will it work even in emulation.I know that you’ve got more folks in the Unix world over on Linux, but that shouldn’t mean you develop only for that one Unix flavor. FreeBSD is still an extremely strong dektop OS, except for lacking a couple of native Adobe applications.

  100. Kevin Newman says:

    I’m not sure about the API choices, but I would suggest contributing (at least) parts of your code and technology (the parts that are not licensed from 3d parties, whatever portion of the codebase that might be) to the Open Source Flash Player project Gnash.Adobe seems to want to push Flash as a real complete platform, and sell the development tools for profit, so why not contribute as much of the source as possible to the Open Source Gnash, and let the community fill in the blanks (like the snap to pixel font rendering engine, which afaik is licensed tech).The nice thing is that the GPL actually protects your Flash Player licensing, since devs can’t link a GPL code base to a proprietary code base (meaning they would still need to license the original Flash Player from Adobe – I have no idea how big that market is for Adobe though).Imagine the benefits of having the latest Flash Player included with every Open Source OS and browser by default, and the porting work done by an employee of a specific distro (Ubuntu, Red Hat, etc.).Just my 2 cents. 🙂

  101. Anonymous says:

    From a developer point of view I think Qt would be the best choice for several reasons:1) The API is really powerful and yet easy to use2) It has support for all your network needs3) With the commercial license (which should be no problem for Adobe to finance) you can additionally statically link (just look at Opera – they offer both)4) Embedded devices running Linux also use Qt (Qtopia) in most cases hence a port to Zaurus and various Cellphones is also easier (again look at Opera)For the AV Part:I think ALSA is not a very good choice. With more platform independent APIs a port to other *NIX-Like operating systems is MUCH easier.Consider Solaris and FreeBSD..As mentioned gstreamer offers both audio and video (and may even be supported by embedded Linux devices).For audio only there is OpenAL that is portable and would also allow an easy way to support embedded devices.Again using X11 is probably a good choice perfomance wise, on the other hand you can gain good perfomance with Qt too and additionally have the opportunity to make a way to embedded devices.As you see, the main things are about a way to support more platforms and I think Adobe knows that there is huge demand for Flash on embedded devices in the near future!

  102. Luke says:

    If you used wxWidgets for the GUI elements, you could also use their higher level socket API’s.Luke.

  103. Chris says:

    I have heard good things about the SDL as a higher level A/V library. Not sure about networking.Still, the current choices seem fine.

  104. Brian says:

    Hi, just wanted to let you know how much I appreciate Adobe allocating the time and resources for better Linux support. Just maintaining this blog and responding to comments gives me faith in your decisions. Thanks, guys!

  105. Brandon Drummond says:

    I think somone stated this earlier, but it’s obvious why these codecs are being used, right? They are all already a part of the standard *Linux* kernel. That’s *why* they are such a good choice. I seriously doubt that any of you are going convince Adobe to build on top of ‘third party interface’ x, y, or z just to support a handful of BSD machines. Remember this is the LINUX version of Flash player as you may have noticed from it’s title.

  106. T says:

    Almost every widely used ime support XIM protocol. So I think there’s no problem with input something if the flash plugin supports XIM protocol.

  107. Bloody says:

    To all the SDL fanboys out there, I know I’m going to piss you off but SDL absolutely sucks as a library.I’ve used it for a while when I was developing a win32 project and I thought it was nice back then… …until I realised I truly, from the bottom of my heart, hated it and would rather use raw win32 API calls than use the SDL.Furthermore, it’s bloated, not everyone has SDL installed on their linux machine and not everyone want to install SDL on their machine. Well I guess that says it all.

  108. Anonymous says:

    Something I haven’t seen mentioned yet with respect to audio:Have you considered PulseAudio?I’m not sure it’s meant as an audio abstraction layer, but it has very few dependencies and a bunch of different output modules. (oss, alsa, solaris, win32, network)Client doxygen docs here.

  109. Villagers of Tsunami says:

    – arts is dead according this site: http://www.arts-project.org/doc/arts-maintenance.html(likely KDE4 not use arts anymore)- Using GTK is right choice because the license (GTK use LGPL)- How about other popular platform like FreeBSD, OpenSolaris and Darwin are they have this APIs

  110. Leon Ho says:

    Modern Linux Input Method Frameworks use im module in GUI toolkits – i.e. gtk+ and qt im-module. So if you let them handle the im, most of the existing frameworks can use on flash without any issues.XIM on the other hand is being deprecated, as its protocol tightly coupled with X and it is not flexible enough for supporting true multilingual input.

  111. Segin says:

    You should create add-on plugins for FP9 that allow people to use Qt or aRts. Not everyone has a Creative Sound Blaster 1024 u3br-l33t Edition wih ALSA support for more simultaneous streams than one would logically want to support. I for one cannot afford a decent, or even anything near decent, soundcard. I am stuck using my onboard AC’97 crap whose driver won’t allow 2 sound streams to play at once. Therefore I use aRts.And why not GStreamer? Here’s why:rw-r–r– 1 root root 1.2G Jul 14 15:33 /gst.coreNote the filesize. That’s right, that coredump is over a gig. Why in the sam hell would I use something that blows up all the time and leaves gigabyte coredumps?

  112. Anonymous says:

    I have heard of several projects sticking to v4l:1 due to v4l:2 having an unstable API.I do not know if this is still the case, just thought I’d throw it out for someone to confirm or debunk. (This may have been on the driver end, which might explain the slow adoption)Also this point may not be relevant as v4l:1 is being removed soon.

  113. Jaramir says:

    Will there be a native 64bit port of flash 9 for linux?I know i can run 32bit mode apps but switching just to see a flash video based anim is not at all that good.Tnx

  114. Anonymous says:

    Gtk2, v4l2, Alsa are OK imho!

  115. Chase Venters says:

    A few remarks:- Please, please use ALSA over Gstreamer. Gstreamer may be seen as many users as a ‘standard’ but they have a history of incompatible API changes. This could spell doom for flash users in the future.- Qt could address your desire for a cleaner sockets API, and could also offer you much easier windowing, etc. Plus, Adobe already licenses Qt…

  116. Joe says:

    Please don’t use the low level api’s, like alsa etc.Use a highler level api.As has been said already, not only will that allow users to use the best low level driver on their system, and allow flash to play nice with their other audio products, it will also make your code more portable.I KNOW you don’t want to support FreeBSD, but sticking to low level Linux stuff WILL bite you in the long run…For example, you are missing an opportunity to bring closer parity to the OS X version.Opera is available natively for FreeBSD, and that is a complete web browser! So are NVIDIA openGL drivers.If these can be done, yet you have difficulty with something much simpler like Flash, then people will either think you couldn’t care less, or that you can’t write good portable and clean code.And one day in the future, some new OS, or Linux derivative may become more popular, and yet flash won’t work on it, causing you to have to do more work again.The goal from the START should be to make the code as portable as possible.. As I said, even if you don’t care about other systems now, it will eventually come back to bite you in the future when things change.

  117. Ben says:

    (Please correct me if I am wrong) Why use GTK if most flash apps out there don’t use UI widgets for buttons but instead use buttons made from pixmaps and SVG paths?@TSDL is not bloated and is in fact very popular among Linux distros (explains why all major Linux games use SDL: Quake 4, Doom 3, Quake 3, Wolfenstein, etc.). It is a lightweight SIMPLE multi-platform abstraction layer and is much more cleaner than win32 apis. Besides you can’t really use win32 apis in linux, now can you? I think SDL makes sense for flash, especially because access to audio, input, and 2d are virtually painless with it.

  118. Ben says:

    Whoops above comment aimed at Bloody instead of T. I got confused by all the lines.

  119. Øyvind says:

    General graphics: X11I’d say this is a good and compatible choice, for now.GUI elements (dialog boxes): GTKAs long as it’s GTK 2, I’d say it’s a good and compatible choice (and I’m a KDE user). PLEASE DONT SUPPORT GTK1, it’s ancient and should be put out of its misery.Audio I/O: ALSAThis is a flash player for Linux, right ? Very good choice, since it’s the standard Linux 2.6 kernel sound API. Don’t depend on large multimedia-frameworks to be installed. Support the codecs you need internally, and support them well.Camera input: Video4Linux, API version 1Oops, as many before me has pointed out, V4L1 is deprecated, better go with V4L2, instead.Threads: POSIX threadsNo problems with this choice.non-HTTP Networking: BSD socketsEven though there are abstractions around, I don’t really think any one of them can be considered standard, therefore I think this is a good choice.SSL: OpenSSLA good and compatible choice.IME: you know what? I don’t think we’ve settled on this one yet…GTK2 should provide what you need ?

  120. gego says:

    as some one has said before follow the LSB – standars, cos that will help a lot, when it comes to compatability…..//Gego

  121. Charles Vicle says:

    The reason it’s an issue is there ARE some out there that want a fully Qt based desktop. I personally cannot count myself as one, but I do know a decent amount that have that view.

    No one is forcing you to use Flash, or anyone else’s code for that matter.

  122. Víctor Fernández says:

    No more GTK, please! If Adobe has a QT license, why don’t you just use it? It will also be easier for you to maintain it, since QT programming is MUCH easier and powerful than GTK programming, I can tell by experience. For example, take a look at the chance to connect signals and slots in different threads, that just can’t be done in GTK. There are also more KDE users than Gnome users (just look at the polls), so QT is definitively a better choice.

  123. Víctor Fernández says:

    The reason it’s an issue is there ARE some out there that want a fully Qt based desktop. I personally cannot count myself as one, but I do know a decent amount that have that view.

    From that point of view, the same thing could be said for the people defending the use of GTK, don’t you think so? If Flash used QT, why should they complain as long as they had QT installed (as the majority of distros do)?

  124. Anonymous says:

    About using XShmPutImage, I’m just wondering if this is the fastest choice or would Xv be faster?I’m asking because the biggest problem I’ve had with flash on Linux is performance. It’s just loads slower than in Windows, I suppose DirectDraw or whatever is used over there. For example, http://www.dreamfall.com/ is usable but slow on this machine I’m writing on, Pentium 4 Xeon 3.06 GHz and NVidia Quadro FX 500/600 with Nvidia’s drivers.Well, that site demonstrates another problem with Linux flash, most text doesn’t display at all…

  125. very good, hopefully flash9 will not crash my firefox anymore with nvidia drivers and 2d acceleration, and i can watch movies with it.alsa is better choice, i dont want gstreamer to take over my fine and working alsa/xine/mplayer machine, because gstreamer is mostly just a crashing something.the choice over v4lv2 or v1 is imho not very important atm, because v4lv1 is supported very well, and i never saw a flash using my cam anyway. in future of course this will add work to port it.even with gnome in all major distris, i know very few real hardcore gnome users (its more historical and a cross platform gpl issue, that kde was not prefered and might change in future anyway) and even if less portable atm, i find qt ways more beautiful.however, gtk2 would be okay, firefox is gtk2 anyway.i suggest to think about future linkings against qt and v4lv2 support. maybe keep good abstraction to be able to relink with something else than gtk.everything else seems fine.

  126. deltatux says:

    hmmm… I like the APIs chosen so far, however, I would disagree about using GTK+. If the reason of choosing GTK+ over QT because of licencing issue, then I understand. If it’s for usability, I find that the QT engine runs faster and smoother. GTK+ feels very very bulky.This is one of the main reason why I run KDE. It uses the QT over GTK+.

  127. Alex Schultz says:

    Personally, I would hate it to use gt unless you made it possible to choose between gtk and qt.Most people, even kde users, have gtk installed for programs such as Firefox and GIMP, however a very large portion of non-kde users do not has qt installed nor want to install it.

  128. desrt says:

    Ignore the haters; you’ve made some fine choices.1. GTK2 is on practically every desktop in existence at this point.2. ALSA with proper DMIX support solves huge problems for 95% of your users (excluding those that want to stream the sound from their flash animations over the network to the stereo).3. About networking: check out the glib IO channel stuff. You still have to do the setup yourself, but it lets you tie the socket into the GTK mainloop which is the nicest way of dealing with it.4. GTK2 will deal with input methods for you unless you’re getting down and dirty and registering handlers for X events.5. Keep up the good work. You’re making an awful lot of people very happy.Cheers

  129. Julien Puydt says:

    Notice that since you’re using gtk+, you could also use gmodule for your dlopening needs.

  130. Ken says:

    You asked about higher-level network libraries. I suggest looking at Twisted. It’s implemented in Python, so it’s probably not much use to you on this project, but it’s a great high-level networking library.

  131. Enver ALTIN says:

    I’d love to add just a few words. We have several deployments of GNOME desktops running via XDMCP and VNC and I know that some other large GNOME deployments in Spain do something like that.So I’d suggest sticking with gstreamer, or PulseAudio at least, to provide network transparency of audio for deployments like ours.Thanks and congratulations.–Enver

  132. Jon Cooper says:

    For the love of god, use GStreamer! Abstraction is the key for linux desktops, forcing only ALSA will lead to all sorts of problems 🙁

  133. Joe Buck says:

    mark pinto: the idea of including a statically compiled gtk to keep KDE folks happy is a poor one. Most KDE users are going to have at least one gtk-using program around anyway. , and every distro packages it, so using static linking will take more memory, as well as mean that you don’t get any bug fixes to GTK that come out after you ship. But more importantly, the fact that gtk is LGPL-licensed means that if a proprietary program is shipped statically linked to it, a way must be provided to re-link to a new version of the gtk library (read the LGPL), so it’s a hell of a lot easier to use dynamic linking.The legal issue is going to mean that no clueful proprietary vendor will statically link an LGPL library.

  134. Rob Caskey says:

    Indeed, GStreamer please!

  135. Jon says:

    I’m gonna be another to call for gstreamer to be used.

  136. Raphael says:

    By using GStreamer instead of ALSA, you’d make it very, very easy to port the Flash Player to other Unices, like Solaris or BSD. While ports the aforementioned systems wouldn’t make a huge impact on your user base, it would be a very nice gesture to the “community”.

  137. Rubens says:

    Using ALSA is also a good choice (if news spread out that GStreamer would be used, I’d expect the opposite from this thread). Gnome vs KDE people, I guess. ALSA can make both parties happy.

  138. WindoM says:

    All good choices, except ALSA: please choose GStreamer instead. It should be easier for you and far better for the users.

  139. Ycros says:

    Indeed, good choices, except I have to agree and say you really should use gstreamer for A/V.

  140. kw123 says:

    gtk 2 please – gtk is the best. it is stable, accountable to a community not a company, it is lgpled, has great bugzilla and QA community, it has an awesome and wise API, it looks great, it integrates with firefox already.gstreamer would be nice, but probably a bit overload for flash. I would love to see you go all the way with gstreamer. it would be a risk but has a great future.what I hate about flash now is that it gets no sound if there is another sound app already openi’m sure gstreamer is your fix here.I have a very recent soundcard and alsa. alsa is kinda eccentric.

  141. Anonymous says:

    GTK 2 is a good choice.I’ll second all the calls for more abstraction, GStreamer is the best way to go for sound I/O and camera input.This also means that Solaris/BSD users will be a lot better off.Though many KDE3 users don’t have GStreamer installed by default today, the future KDE4 sound API “Phonon” will most likley use GStreamer as it’s main backend.

  142. chele says:

    webcams: I notice that neither V4L nor V4L2 support using a firewire camcorder as a webcam. Ekiga/Gnomemeeting uses libpt to provide this function.

  143. Ed says:

    I would also recommend using GStreamer; not only is it more abstracted and portable than ALSA and VfL, but it will help immensely with networked installations; the admin just needs to set the default GStreamer output to whatever the current network audio system is (ARts, ESD, PulseAudio, NAS, etc.)

  144. John says:

    But doesn’t ubuntu need a graphics interface for this to work…

  145. Anonymous says:

    Another for GStreamer please

  146. This would be my vote for using GStreamer for everything it can be used for.Reasons:* Ubuntu is one of the most popular distros out there and completely supports GStreamer 0.10.* The GStreamer team is very committed and are focused upon constantly improving their API.* KDE4 will have GStreamer support.* Extensive architecture support. Wouldn’t it be nice if the same code would run on i386 and x64 cpu’s?There are a lot of other reasons, but those are the ones that first came to mind.Keep up the good work.

  147. Richi says:

    Another vote for GStreamer. A close analogy would be developing an audio player that only interfaces with amplifiers when digital signal processors have a lot of functionality that people want and some are finding they can’t do without.Could we have enough of the “GStreamer crashes” and “GStreamer API is not stable” cruft? It hasn’t crashed for me, yet, and crashes are repairable (with no need to reprogram the client program using it). The API for 0.10 has been stable since its inception.

  148. Anonymous says:

    For us to see more and more Flash Players on embedded Linux devices, please use GStreamer.In many cases, Audio/Video codecs (e.g. mp3 & vp6) need to run on co-processors in embedded Linux. Flash Player can automatically benefit from those HW accelerations if it uses GStreamer.

  149. Anonymous says:

    I don’t see why there should be separate lines of development for Windows and the minority OSes. In 2006, can’t people yet build for 99.8% of systems from just one set of source? If that is somehow impractical, people should be told why.

  150. Thank you so very much. This is a very important improvement to Linux flash support. One question, however: Have you considered using the XVideo extension for video playback? Raw X11 video playback is dismally slow. All the improvements are most welcome, though!

  151. digitalturbulence says:

    If anyway the flash player would be closed source, please use QT and NOT the slow GTK.

  152. Heiko Rölke says:

    A little bit late for this post, but have not found any other information: So what IME was decided to use? What method is used to figure out if there is one? Thanks.