ExoPlayer and Kotlin Thoughts

This past weekend I finally took the plunge and updated my Android TV / Fire TV application to use ExoPlayer.   Yeah, I’m a bit behind the curve here, and should have done this a while ago.   When I first wrote Serenity for Android about 5 years ago, you pretty much had to roll your own Player UI if you wanted anything more than the bare basics.   Thankfully, things are much simpler with ExoPlayer and the provided SimpleExoplayerView.   Everything I had to roll by hand and brute force implement in MediaController and the SurfaceView are now bundled directly in the SimpleExoplayerView.   This includes the ability to display Subtitles.   What took me about a good 2 months to implement myself, was basically done in a couple of days with Exoplayer.

The other nice thing about Exoplayer is that it brings video playback stability across devices.   Using the old player and MiBox Android TV device, if I tried to play back a movie with Dolby Digital Audio it would crash the app.    With ExoPlayer it works directly out of the box with the basic configuration.    This was the main reason that I made the switch to ExoPlayer.    The other reason is the ability to support Transcoding and choose either HLS or Dash support.    Currently Serenity supports the Universal Transcoder from the latest Plex Servers, but will hopefully start supporting the Emby Media Server as well.

While we are talking about Plex… why haven’t they provided 3rd party developers with a real documented API yet?    Emby has a complete Java API as well as APIs for multiple other languages.   Plex makes it so you have to reverse engineer what they are doing, or hope you can decipher one of the few remaining Open Source clients they have available to use and browse the code.    It is one of the reasons I’m starting the migration to Emby instead of Plex.  Functionality wise they are about equal now, but the open source nature of Emby fits better with my goals.   Having a documented API will help foster your third party developers, which can help drive users to possibly look at some of your paid subscription options for your applications.

Back to Exoplayer, I highly recommend taking a look at the library if you haven’t already.  If your last experience creating a video player or audio player was with the old Android APIs, then you will be presently surprised what you get out of the box for free now with ExoPlayer.

Now on to Kotlin.   It has been the rage for a while now in the Android community, especially with Google adopting it as an official supported language for Android development now.   Kotlin has a lot of good things too it, but along with the good comes some very frustrating things.

  • Increase in method count size.  If you have an app that needs to run on older devices still and you are near the 64K method limit.  You can be pushed over the edge with Kotlin and will need to start using Multi Dex.   One of the issues (features) is that Kotlin generates property accessors (getter/setters) for all field level variables you define that aren’t private.   This means that you can needlessly have extra methods generated that are never used.
  • If you do Test Drive Development or just write Unit Tests for your application (you do do this right???).   Then you will run into how much of a pain that Kotlin’s close by default nature becomes.   A work around for this is to use the Kotlin All Open plugin, to make classes and functions annotated with a particular annotation open by default.   This allows mocking frameworks like Mockito to play better with Kotlin generated code.   I understand the reasoning and I think closed by default is perfectly valid for Data classes within Kotlin, I just don’t agree that everything should be closed by default for all classes.
  • If you have a Java Interface that you need to implement in a Kotlin, and that interface has getter and setters defined.  You will not be able to use a Data class for this implementation.  The reason being you need to override the default definitions of the getter and setters within Kotlin.   So you loose the conciseness that Data classes provide.
  • There are pain points still if your application is a Hybrid application (i.e. a mix of Java and Kotlin code).   Accessing singleton instances from within Java code that was written in Kotlin can be a pain due to having to access inner Companion classes.
  • Dependency Injection is a bit funky with Kotlin if you use Dagger.   Because Dagger requires at least protected or internal fields and these fields can’t be private.  You’ll end up with a lot of getters and settters in the generated code.   Plus, you will need to use lateinit var option on your fields that will be injected.   If you need to annotate a field with more than one annotation you will need to use the really funky @field:[Inject ForVideoQueue] annotation format, where the options in the @field annotation are the multiple Annotations to be assigned to the field.   The added levels of syntax sugar can make the underlying code more verbose.
  • Becareful with the use of the null (?) operator in Kotlin, it can generate a bunch of extra code that you normally wouldn’t see generated as it checks for Null every time the method is used.   This can affect your code coverage results if you aren’t careful.

Kotlin isn’t all frustrating though.  It does force you to really do some defensive programming, and with some refactoring of existing code and knowing the flow of your application, use of @NonNull annotations in your Java Code can help detect possible NPE’s and keep you from passing these to Kotlin code.    Also the short cuts for one line methods is nice as well for reducing some boiler plate code.

I’m still early in my Kotlin adoption, but I see why people like it, but as much as people talk it up as the greatest thing since sliced bread, it still has it’s warts just like any other language.


Posted in android, kotlin, open source, plex media server | Leave a comment

OBS-Studio and Hardware Encoding for Linux

There are a lot of different ways to do hardware based encoding with obs-studio, however, this particular article will discuss getting things to work with the libva api standard that some Intel and AMD gpu’s support.   Unfortunately, obs-studio doesn’t support this right out of the box, but since it is open source, several people have made the necessary files available.

First though why do you want Hardware Encoding of your videos, obs-studio by default comes with access to the x264 software based encoder that is used with ffmpeg.  While this does a good enough job, it is also very CPU intensive, and in my experience this is is pretty picky on CPU usage that can start to drop your frame’s per seconds down.  Dropped frames means stuttering or laggy video.  Which isn’t a good thing.

On my particular system using software encoding with OBS-Studio running would take between 18 to 25 percent cpu.  If it creeped up into the 20% range, it would  start to drop frames.   So I had to be judicial about what was being done with the scenes.   With Hardware encoding enabled, the system is consistently using between 5 to 8 percent CPU.  A huge difference that frees up the CPU to be used for other things by other applications.

If you have Ubuntu installed, you probably already have the necessary drivers needed to use LIBVA api for hardware encoding.   To check this you can run the command vainfo to get the necessary information if your system supports hardware encoding.

vainfo libva info: VA-API version
    0.38.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/i965_drv_video.so libva info: Found init function
    __vaDriverInit_0_38 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.38 (libva 1.6.1) vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Desktop -
    1.6.1 vainfo: Supported profile and entrypoints
          VAProfileMPEG2Simple            : VAEntrypointVLD
          VAProfileMPEG2Simple            : VAEntrypointEncSlice
          VAProfileMPEG2Main              : VAEntrypointVLD
          VAProfileMPEG2Main              : VAEntrypointEncSlice
          VAProfileH264ConstrainedBaseline: VAEntrypointVLD
          VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
          VAProfileH264Main               : VAEntrypointVLD
          VAProfileH264Main               : VAEntrypointEncSlice
          VAProfileH264High               : VAEntrypointVLD
          VAProfileH264High               : VAEntrypointEncSlice
          VAProfileH264MultiviewHigh      : VAEntrypointVLD
          VAProfileH264MultiviewHigh      : VAEntrypointEncSlice
          VAProfileH264StereoHigh         : VAEntrypointVLD
          VAProfileH264StereoHigh         : VAEntrypointEncSlice
          VAProfileVC1Simple              : VAEntrypointVLD
          VAProfileVC1Main                : VAEntrypointVLD
          VAProfileVC1Advanced            : VAEntrypointVLD
          VAProfileNone                   : VAEntrypointVideoProc
          VAProfileJPEGBaseline           : VAEntrypointVLD
          VAProfileH264MultiviewHigh      : VAEntrypointVLD
          VAProfileH264MultiviewHigh      : VAEntrypointEncSlice
          VAProfileH264StereoHigh         : VAEntrypointVLD
          VAProfileH264StereoHigh         : VAEntrypointEncSlice

If you get information like above, you are set to move to the next step.  If you don’t, then either your system doesn’t support libva, or you may need to install the necessary deb file (intel-libva-driver I believe).

Next we need to recompile OBS-Studio with the necessary support plugin.  Fortunately, Reboot from GitHub has create the necessary plugin for us.   I’ve forked his code, and updated it to work with 19.x or above.   You will need to clone the repository and check out the vaapi-h264 branch I have.

I’m not going to go into detail on how to compile OBS-Studio, that is documented on the Wiki.   But once you recompile, you should now have a new menu option in the Output section of the preferences.   It will still default to x264, but you should be able to select the VA-API encoder option.   I would recommend this for both Streaming and Recording.  You shouldn’t need to mess with changing any of the defaults.

Start your recordings, and you should not see your CPU spiking as you did in the past.  You can play with the settings if you want, but the defaults worked well for me.




Posted in obs-studio, streaming, Uncategorized | Tagged , | 2 Comments

The State of Android and Eclipse

So it has been a while since I posted an update of where things stand.  Honestly, not a lot has changed on the eclipse front.  We still don’t have built in AAR support, there is no integrated Gradle support between Buildship and Andmore, we are behind on Nougat support, and O is fast approaching release status.   With that said, there have been a few bug fixes contributed by the community, which were released as a maintenance release, but the larger corporate adoption… is pretty much non-existent from a contribution stand point.

The later I’m not sure how to fix, as I whole heartily believe that Andmore needs a corporate backer and sponsor to fund things.   This could probably be avoided if several people that really have an itch to fix the base wanted to scratch it.   There is a lot to work on that it can be a bit overwhelming to figure out where to start.

When Google had announced a couple years ago that Android Development Tools would not be maintained any longer, I had that itch to see if I could at least get it and the Moto Dev Studio tools to a place where it would have a chance to survive.  I managed to scratch that and over the next year with the help of several other committers bring you Andmore 0.5.0.   Believe me the most difficult work has been done, and that is getting everything through the IP process, what is there is clean from that stand point.

So the general question now that Andmore is at the Eclipse Foundation, is there a dire need from the community to have Android tooling?   There was much outrage and yelling when Google made the decision to move to Intellij, some of it rightfully deserved some of it just background noise.   Regardless of the reasons, Android Tooling was always a Google controlled and sponsored project, it was open source in really name only (it took nearly 2 years for Doug’s CDT integration to be integrated into the core).   The same is happening with Android Studio, it is controlled and dominated by Google and is really open source in name only.  If Google decides for whatever reason that they want to move all development to the cloud and abandon Android Studio and Intellij, there is nothing that anyone will be able to do to prevent it.  The difference though is, that Jet Brains will pickup and continue developing Android support themselves.  Why, because they have a financial interest to make sure their IDE supports it for their corporate customers.

This brings us back to the question… Does the community really want Android tooling built off the eclipse platform?   If so, how do we improve it, given that right now, this is largely a volunteer effort.


Posted in android, eclipse, open source | Leave a comment

Andmore 0.5.1

A small maintenance release for the Andmore project has been released. This release contains a handful of bug fixes that have been provided entirely by the community. So if you have the will and desire to help move Android development for eclipse along, you just need to submit a pull request to the project and it will more than likely be included.

If you really, want to become a committer. The barrier to entry is pretty low. Just submit some quality pull requests to the project, and if you have the desire to work on the project more we will probably ask. Andmore is what the community makes it.

The maintenance release is available through the eclipse marketplace.

Posted in android, eclipse | 1 Comment

Andmore 0.5-M7 available.

Screen Shot 2015-04-19 at 4.44.52 PM

It’s been a while since I posted an update.  Milestone 0.5-M7 is available for download.  This is a pretty big upgrade to the underlying support libraries.   You should now be able to work with Android versions up to M with the this update.   It is recommended that you update your SDK as well if you haven’t already.

Android N may work as well, and we’ll need people to test this out.   The latest version is out in the Eclipse Market Place


The latest version can always be obtained from the following p2 url:


Please do give this a tire kick, and thanks again to Matthew Piggot for contributing the update and  Kaloyan for getting this big change out.

Posted in android, eclipse, planetandroid | Tagged , | 2 Comments

Andmore 0.5-M3 available.

Screen Shot 2015-04-19 at 4.44.52 PM

The third stable milestone is ready for you, the user community to kick the tires, and use for your development.  This is primarily a bug and stability milestone.  The one big addition is that Andmore now supports multi-dexing of the APK files.    Also, starting with the next Neon milestone, an Android Developers EPP package will be available.   This effort is being lead by the newest committer Kaloyan Raev.

Also this release of Andmore can be installed on older versions of Eclipse other than Mars.   There is also now an Eclipse Marketplace entry for the project as well to make installing the tooling even easier.



The latest version can always be obtained from the following p2 url:


Posted in android, eclipse, planetandroid | Tagged , | Leave a comment

Andmore 0.5-M2 Released

Screen Shot 2015-04-19 at 4.44.52 PM

The second stable milestone release is ready for you, the user community to kick the tires, and start to use for your development.  Thanks to several community members for fixes in this release.  The most important being that the Android XML Editor no longer tries to be the only XML editor in the system.  This should allow Andmore to play nicer with other plugins that you may be using.   Also the Database Perspective got some attention and when browsing a Database from a device you should no longer get an error dialog displayed. Full details can be found in the New and Noteworthy section for the release notes.

There is a p2 site for your installation needs, I haven’t had time yet to do a composite repository yet, but it is on the list.  In the mean time add the following update site to get the latest milestone release.


Add the above url to your available software sites.

It is recommended to get also get the latest m2e-android as well.  It adds some support to guarantee that source folders stay in the correct order and helps guarantee that other eclipse plugins work well with Andmore when using maven.

We are still waiting for some extension points from the Buildship project so that we can provide Gradle integration.

Thanks again the community members that provided patches.  It helps move the project forward.

Posted in android, eclipse | Tagged , | 1 Comment

Android Developer Tools is dead….long live Andmore.

It is now official.   A posting from the official Android Developer’s blog has confirmed what many of us already knew, that the days of the original Android Developer Tools based on Eclipse was numbered.   Honestly, I think this is not  a bad thing.  It does free up the resources that Google has to fully concentrate on the Android Studio tooling, and continue to improve and advance their chosen strategy going forward.

However, all is not lost, as the Andmore project is here to continue to provide Android tooling for the Eclipse community.  However, progress right now is pretty slow, and that is because my own time has been limited.   With this said, we do have integrated support with Maven and the android-maven-plugin through the m2e-android project’s support.   The Buildship project can import an existing Android gradle project, and even run some tests, but it still has problems in setting up the project natures and make things work with Andmore.   There is a feature request opened to have some sort of project configuration extension so that Andmore can help configure such projects to better work with the tooling.

The state of Android development with Andmore and how well it keeps up with the yearly and quarterly updates coming from the Android Open Source Platform is going to greatly depend on contributions from the community.   We need your help, as one person definitely can not maintain the project alone.    So please do take a look at the bug/feature backlog, feel free to fork the project on GitHub, roll up your sleeves and get a bit dirty, submit pull requests and file new bugs.   Andmore is going to be what the community makes it.   We wished for years that ADT had been open more to contributions from the community, now is the time for us to follow through on that wish.

Posted in android, eclipse | Tagged , | Leave a comment

Andmore 0.5-M1 Released

Screen Shot 2015-04-19 at 4.44.52 PM

Android development using eclipse has taken a step forward today.  The first stable milestone release is ready for you, the user community to kick the tires, and start to use for your development.  Full details can be found in the New and Noteworthy section for the release notes.

There is a p2 site for your installation needs, and it is recommended that you not install both Android Developer Tools and Andmore into the same IDE.


Add the above url to your available software sites.

Andmore contains all the functionality and features of Android Developer Tools, plus a lot more.    Also, thanks to Ricardo Gladwell for updating the m2e-android plugin to support Andmore.  This means that if you are using maven already, you can continue to do so with Andmore to continue developing Android applications and manage your dependencies.  The p2 site for maven support is:


So what about Gradel support and the the android gradle plugin?  Right now this is targeted for 0.5-M2.   There is a lot of stuff that needs to occur in order for this to happen.  For one thing, AAR support is necessary.   We also need to look into what extension points that the Buildship project will offer.  Will Andmore need to provide any extension points to allow Maven and Gradel to have more control over the build process?

Limitations with the current Andmore release:

  • No AAR support
  • No Gradel support
  • Android API 22 has limited support.  The only piece that may give you an error message is the GUI Layout editor.  If this happens change the API level in the editor from 22 to 21 or lower.

There is plenty to do yet, and the project is very open to contributions from the community.  If you would like to help out with any of the remaining work, do not hesitate to fork the repo on Github, and submit a pull request.   Andmore will be what the community makes it.  Bugs and Feature requests can be opened at:


Posted in android, eclipse | Tagged , | Leave a comment

Andmore 0.5-M1 RC2

Release Candidate 2 is available for smoke testing.   This is mainly some spit and polish to remove the Andmore name from the menus and views, and replace them with more generic labels where it makes sense.


Just add the above to your Install Software, and select the Andmore features to install.  Note that if you have existing ADT projects that you want to work with Andmore, you will need to Configure those to work with the new tooling.  To do so select a project, Configure->Convert ADT project.

If no new big show stoppers are reported by next week, we will do a formal 0.5-M1 announcement with complete change log.

Posted in android, eclipse | Tagged , | Leave a comment