- 16 Jan, 2016 1 commit
-
-
Bart van den Ende committed
-
- 14 Jan, 2016 22 commits
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112162208
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112161960
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112161860
olly committed -
I'm not really sure how best to document this in TrackRenderer; it's a bit of a weird feature. For now, I've gone with the vague approach. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112150939
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112149442
andrewlewis committed -
See the documentation of buildTracks for the gory details. Issue: #151 Issue: #676 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112149293
olly committed -
This CL exposes the cue settings parser in order to allow its usage from the MP4Webvtt extractor. Also fixes a few mistakes from the previous related CL. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112145806
aquilescanta committed -
* AudioTagPayloadReader was strangely parsing an audioSpecificConfig itself, using the parsed values to build a new audioSpecificConfig, then passing the newly constructed instance to be parsed by CodecSpecificDataUtil. Unfortunately the translation was lossy ;). * Treat Duration=0 as an unknown duration. Issue #1137 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112143569
olly committed -
- I think \r and \n are handled the wrong way around? - We only expect to encounter a BOM sequence at the start of a file, but it feels fine to automatically discard it in all cases for simplicity. A BOM sequence doesn't mean anything in UTF-8. See https://en.wikipedia.org/wiki/Byte_order_mark. Note that I think the advice not to remove it on that page relates only to the case where the file is being edited + saved. Issue #1136 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112143407
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=112127698
andrewlewis committed -
Issue: #151 Issue: #676 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111945466
olly committed -
There are multiple issues with HlsSampleSource's use of LoadControl that become apparent when you attempt to use the same LoadControl for loads by another source. * In the "limbo" state HlsSampleSource doesn't start any new loads, but doesn't update the LoadControl to tell it that it doesn't want to load anything either. This can prevent another source from starting the loads that it needs to make to complete preparation, causing playback to become stuck. * The LoadControl isn't updated properly when the EOS is reached. This can cause playback to become stuck near the end of the media. * If HlsSampleSource is released from being in the "limbo" state, it doesn't unregister itself with the control. Issue: #151 Issue: #676 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111942009
olly committed -
Given we need to do this in HlsPlaylistParser in the normal case (i.e. not MEDIA_TAG), we may as well just be consistent and do it everywhere. Issue: #151 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111941335
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111839055
eguven committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111833857
andrewlewis committed -
Currently only supports a single offset to the full media timeline (indicated by a duration of 0). This is most often used to fix the non-zero starting presentation timestamp introduced when B-frames are present. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111816916
rileya committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111746825
cblay committed -
Fixes Issue #1047 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111708934
vigneshv committed -
This is equivalent to DashTrackSelector and SmoothStreamingTrackSelector. This is a step toward allowing HlsChunkSource to expose multiple tracks, which is a requirement for supporting WebVtt. This change also enables WebVtt extractor instantiation. Issue: #151 Issue: #676 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111698833
olly committed -
This allows the same adjusters to be used by multiple HlsChunkSource instances. This is necessary because WebVTT chunks will be loaded by a second chunk source to the one loading audio/video. In both cases the same timestamp adjustments will need to be applied. Each source may transition from one discontinuity sequence to the next at a slightly different time, so it's necessary to maintain a separate adjuster for each sequence. An adjuster can only be initialized correctly using audio/video and not WebVTT, because the start time in a WebVTT file in HLS doesn't necessarily correspond to the chunk start time, which means the timestamp offset calculated by the adjuster could end up being incorrect. Hence sources providing WebVTT chunks will set isMasterSource to false. Lovely, right :(? Issue: #151 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111693126
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111689012
eguven committed -
This gives DefaultSmoothStreamingTrackSelector feature parity with DefaultDashTrackSelector. Note that the code duplication across these classes will go away eventually, when we rework track selection as described in Github Issue #1121. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111688784
olly committed
-
- 07 Jan, 2016 5 commits
-
-
This is a no-op change for clarity only. maxWidth/maxHeight don't mean anything for AAC/MP3, so it makes sense to pass MediaFormat.NO_VALUE in all cases. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111619832
olly committed -
Moved the behaviors related to Cue's to the WebvttCueParser class. This way, the parsing methods will be more easily accessible to other classes, such as the MP4Webvtt parser. This class also has some methods that require state to avoid repetitive avoidable allocations. The method visibility is subject to changes in further CLs. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111616824
aquilescanta committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111613354
olly committed -
Issue: #1090 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111607802
andrewlewis committed -
Yu-Hsuan Lin committed
-
- 06 Jan, 2016 5 commits
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111515406
olly committed -
Targeting to all API level 19 devices using the OMX.SEC.avc.dec decoder is probably the right thing to do. It shouldn't have negative implications if we apply the workaround on devices that don't really need it, except to slow down seeking slightly due to decoder re-allocation. Given we're talking about JB, I think the priority should be to "make sure it works". Issue: #951 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111514406
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111507159
olly committed -
We normally expect each frame to come in its own PES packet, but it seems that this is not always the case. This change uses the frame rate in the stream to increment the frame timestamp in the case of multiple frames contained within a single PES. Note that since we don't expect 100s of frames in a single PES, or anything close to that really, the rounding errors that may accumulate due to use of a frame duration should be fine. Issue: #1112 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111499052
olly committed -
Issue: #1102 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111497855
andrewlewis committed
-
- 05 Jan, 2016 6 commits
-
-
Issue: #862 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111403855
eguven committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111402555
aquilescanta committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111394118
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111348701
mishragaurav committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111326567
aquilescanta committed
- 04 Jan, 2016 1 commit
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=111326567
aquilescanta committed
-