sjs/media
1
0
Fork 0
mirror of https://github.com/samsonjs/media.git synced 2026-03-30 10:15:48 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
No description
4030 commits 7 branches 40 tags 626 MiB
Java 98.5%
C++ 0.4%
Kotlin 0.4%
GLSL 0.3%
PostScript 0.2%
Other 0.1%
Find a file
tonihei 4671c23c4d Migrate ExoPlayerTest to Robolectric. 
So far this wasn't possible because Robolectric's Looper and MessageQueue
implementations have multiple shortcomings:
 1. The message loop of new HandlerThreads is an not an actual loop and
    scheduled messages are executed on the thread the message is enqueued
    (not the handler thread).
 2. The scheduler used to replace the message queue is synchronizing all its
    methods. Thus, when a test attempts to add messages to a Handler from
    two different threads, it may easily run into a deadlock.
 3. The scheduler doesn't correctly emulate the order of messages as they
    would be in an actual MessageQueue:
   a. If the message is enqueued on the handler thread, it gets executed
      immediately (and not after all other messages at the same time).
   b. The list of messages is always re-sorted by time, meaning that the
      order of execution for messages at the same time is indeterminate.
 4. Robolectric's SystemClock implementation returns the current scheduler
    time of the main UI thread. So, unless this scheduler is used to add
    messages in the future, the SystemClock time never advances.

This CL adds two helper classes which extend and replace Robolectric's
ShadowLooper and ShadowMessageQueue.
 1. We intercept messages being enqueued or deleted in the message queue.
    Thus Robolectric's faulty scheduler gets never used. Instead, we keep
    a blocking priority queue of messages, sorted first by execution time
    and then by FIFO order to correctly emulate the real MessageQueue.
 2. We also keep a list of deleted messages to know which messages to ignore
    when they come up in the looper.
 3. When a new Looper is started, we override the dummy loop to an actual
    eternal while loop which waits for new messages, checks if they haven't
    been deleted, and runs the messages (similar to what Robolectric's
    MessageQueue would have done at this point).

Because we don't actually use the main UI thread in our tests, we can't rely
on the SystemClock to progress in any sensible manner. To overcome this issue,
we can use the auto-advancing FakeClock also used for the simulation tests.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182912510
2018-01-23 19:30:41 +00:00
demos Generalize parameter type in DemoApplication build methods 2018-01-23 19:27:41 +00:00
extensions Use Truth instead of framework asserts in all tests. 2018-01-23 19:29:12 +00:00
gradle/wrapper Upgrade gradle plugin / wrapper 2017-09-05 16:47:38 +01:00
library Migrate ExoPlayerTest to Robolectric. 2018-01-23 19:30:41 +00:00
playbacktests Use Truth instead of framework asserts in all tests. 2018-01-23 19:29:12 +00:00
testutils Migrate ExoPlayerTest to Robolectric. 2018-01-23 19:30:41 +00:00
.gitignore Add tv module for USB tuner support + demo app 2017-09-15 23:30:41 +01:00
.hgignore Bump to 2.5.4 2017-10-19 18:10:27 +01:00
build.gradle Update gradle wrapper 2017-11-23 15:06:12 +00:00
constants.gradle Bump version to 2.6.1 2017-12-15 20:47:57 +00:00
CONTRIBUTING.md Fix broken documentation 2016-08-31 15:25:25 +01:00
core_settings.gradle Allow easier ExoPlayer/Cast integration 2017-08-17 22:56:52 +01:00
gradle.properties Tweak project structure 2016-08-08 11:53:22 +01:00
gradlew Initial drop. 1.0.10. 2014-06-16 12:56:04 +01:00
gradlew.bat Cleanup following #884 2015-10-27 21:03:16 +00:00
ISSUE_TEMPLATE Allow late HLS sample queue building 2017-12-12 18:30:00 +00:00
javadoc_combined.gradle Generate combined Javadoc 2017-03-22 19:11:28 +00:00
javadoc_library.gradle Generate combined Javadoc 2017-03-22 19:11:28 +00:00
LICENSE Initial drop. 1.0.10. 2014-06-16 12:56:04 +01:00
publish.gradle Make it easier to use ExoPlayer modules in other projects 2017-06-28 22:26:05 +01:00
README.md Typo fixes 2018-01-03 13:34:36 +00:00
RELEASENOTES.md Include P8 in setOutputSurfaceWorkaround 2018-01-23 19:20:16 +00:00
settings.gradle Moved Exo IMA Demo to ExoPlayer. 2017-10-27 15:57:28 +01:00

README.md

ExoPlayer

ExoPlayer is an application level media player for Android. It provides an alternative to Android’s MediaPlayer API for playing audio and video both locally and over the Internet. ExoPlayer supports features not currently supported by Android’s MediaPlayer API, including DASH and SmoothStreaming adaptive playbacks. Unlike the MediaPlayer API, ExoPlayer is easy to customize and extend, and can be updated through Play Store application updates.

Documentation

Using ExoPlayer

ExoPlayer modules can be obtained from JCenter. It's also possible to clone the repository and depend on the modules locally.

From JCenter

The easiest way to get started using ExoPlayer is to add it as a gradle dependency. You need to make sure you have the JCenter and Google repositories included in the build.gradle file in the root of your project:

repositories {
    jcenter()
    google()
}

Next add a gradle compile dependency to the build.gradle file of your app module. The following will add a dependency to the full library:

compile 'com.google.android.exoplayer:exoplayer:2.X.X'

where 2.X.X is your preferred version. Alternatively, you can depend on only the library modules that you actually need. For example the following will add dependencies on the Core, DASH and UI library modules, as might be required for an app that plays DASH content:

compile 'com.google.android.exoplayer:exoplayer-core:2.X.X'
compile 'com.google.android.exoplayer:exoplayer-dash:2.X.X'
compile 'com.google.android.exoplayer:exoplayer-ui:2.X.X'

The available library modules are listed below. Adding a dependency to the full library is equivalent to adding dependencies on all of the library modules individually.

  • exoplayer-core: Core functionality (required).
  • exoplayer-dash: Support for DASH content.
  • exoplayer-hls: Support for HLS content.
  • exoplayer-smoothstreaming: Support for SmoothStreaming content.
  • exoplayer-ui: UI components and resources for use with ExoPlayer.

In addition to library modules, ExoPlayer has multiple extension modules that depend on external libraries to provide additional functionality. Some extensions are available from JCenter, whereas others must be built manually. Browse the extensions directory and their individual READMEs for details.

More information on the library and extension modules that are available from JCenter can be found on Bintray.

Locally

Cloning the repository and depending on the modules locally is required when using some ExoPlayer extension modules. It's also a suitable approach if you want to make local changes to ExoPlayer, or if you want to use a development branch.

First, clone the repository into a local directory and checkout the desired branch:

git clone https://github.com/google/ExoPlayer.git
git checkout release-v2

Next, add the following to your project's settings.gradle file, replacing path/to/exoplayer with the path to your local copy:

gradle.ext.exoplayerRoot = 'path/to/exoplayer'
gradle.ext.exoplayerModulePrefix = 'exoplayer-'
apply from: new File(gradle.ext.exoplayerRoot, 'core_settings.gradle')

You should now see the ExoPlayer modules appear as part of your project. You can depend on them as you would on any other local module, for example:

compile project(':exoplayer-library-core')
compile project(':exoplayer-library-dash')
compile project(':exoplayer-library-ui')

Developing ExoPlayer

Project branches

  • Development work happens on the dev-v2 branch. Pull requests should normally be made to this branch.
  • The release-v2 branch holds the most recent release.

Using Android Studio

To develop ExoPlayer using Android Studio, simply open the ExoPlayer project in the root directory of the repository.