- 24 Oct, 2016 13 commits
-
-
Oliver Woodman committed
-
Oliver Woodman committed
-
Issue: #1976 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=137044583
olly committed -
Issue: #1986 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=137035576
olly committed -
Code coverage is disabled in V2 to workaround https://code.google.com/p/android/issues/detail?id=226070 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=137032839
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=137011920
olly committed -
Oliver Woodman committed
-
Issue:#1966 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136836332
aquilescanta committed -
SectionPayloadReaders are provided to a SectionReader to get whole sections(crc checked). This allows the injection of custom section readers. E.G: SCTE35 messages. Issue:#726 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136816612
aquilescanta committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136710546
andrewlewis committed -
In this CL: * PesReader moves out of TsExtractor and becomes public. * ElementaryStreamReaderFactory becomes TsPayloadReaderFactory and is moved to TsPayloadReader. * The TsPayloadReaderFactory is in charge of wrapping any ElementaryStreamReaders with a PesReader. Incoming: * Extract SectionReader supperclass (analog to PesReader, but for sections) from Pat and Pmt readers. * Add a ScteReader, wrapped by a section reader, and include it in the DefaultTsPayloadReaderFactory. Issue:#726 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136707706aquilescanta committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136702598
olly committed
-
- 21 Oct, 2016 2 commits
-
-
Fix NPE in TsExtractor when ElementaryStreamReaderFactory returns null
Santiago Seifert committed -
pesPayloadReader can be null here because DefaultStreamReader.init() can return null on unknown streamId. If we have a junk transport stream in our content an exception will be thrown.
vitekn committed
-
- 20 Oct, 2016 5 commits
-
-
Update dev-v2-id3
ojw28 committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136697697
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136607848
aquilescanta committed -
Oliver Woodman committed
-
- 19 Oct, 2016 8 commits
-
-
Oliver Woodman committed
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136597149
olly committed -
Issue: #1965 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136595233
olly committed -
*** Reason for rollback *** Flag doesn't enforce what it says it enforces, due to redirects *** Original change description *** Add REQUIRE_HTTPS flag Note that it's not possible for the library to enforce that the flag is adhered to, since it's possible for applications to inject custom implementations of DataSource (there's no requirement they even extend HttpDataSource for network requesting implementations). It's possible for applications to replace pretty much anything in the library, so there's no other place we could put the flag where we could make this guarantee. Hence this is a best-effort that will work when... *** ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136583459
olly committed -
This is a problem when two invocations of getNextChunk that retrieve chunks (i.e. not playlists) occur too apart in time. In that case the last loaded chunk has a media sequence that is behind the current playlist. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136501291
aquilescanta committed -
Note that it's not possible for the library to enforce that the flag is adhered to, since it's possible for applications to inject custom implementations of DataSource (there's no requirement they even extend HttpDataSource for network requesting implementations). It's possible for applications to replace pretty much anything in the library, so there's no other place we could put the flag where we could make this guarantee. Hence this is a best-effort that will work when using HttpDataSource implementations that we provide. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136500947
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136399474
kapishnikov committed -
Use sha1 of content uri if a custom cache key or content id isn't provided. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136351830
eguven committed
-
- 18 Oct, 2016 2 commits
-
-
Oliver Woodman committed
-
Oliver Woodman committed
-
- 17 Oct, 2016 7 commits
-
-
Merge dev-v2 into dev-v2-id3
ojw28 committed -
Oliver Woodman committed
-
Oliver Woodman committed
-
Oliver Woodman committed
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136339035
olly committed -
This will allow asynchronous preparation. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136176854
aquilescanta committed -
One issue with the previous implementation was that isUnsynchronized would not be set back to false if previously set to true and if the next header has majorVersion >= 4. In general, having the decoder be stateless is clearer (and thread safe, albeit that this property is not required).
Oliver Woodman committed
-
- 14 Oct, 2016 3 commits
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136163292
klampert committed -
1. HttpMediaDrmCallback.executeProvisionRequest needs to specify an empty byte[], else we do a GET instead of a POST. 2. Content-Type should not be set when making the provision request, since there's no body. 3. DataSource implementations must correctly handle a non-null body with zero length. CronetDataSource was not handling this case. DefaultHttpDataSource was, but made a code modification to make it a little clearer. OkHttpDataSource seems to handle the case correctly, and it doens't look like the code can be made clearer. Issue #1925 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136042641
olly committed -
Note that actually handling CEA-708 is not yet implemented, and so this is a no-op change from a behavior point of view. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136038439
olly committed
-