searching for reviewer(jya)
7b72fa29c64be23ef4ac7f2373e5622adb48b337: Bug 1552081 - part2. Modify test 'test_webvtt_update_display_after_adding_or_removing_cue.html'. r=jya
Alastor Wu <alwu@mozilla.com> - Fri, 17 May 2019 00:56:27 +0000 - rev 474283
Push 36027 by shindli@mozilla.com at Fri, 17 May 2019 16:24:38 +0000
Bug 1552081 - part2. Modify test 'test_webvtt_update_display_after_adding_or_removing_cue.html'. r=jya Now adding or removing cue would trigger processing cues only when media element's `show-poster` flag is false, so we have to modify the test to reset the flag in order to test the correct behavior. Differential Revision: https://phabricator.services.mozilla.com/D31511
95ccc685eb11f356e7b8c8be9ed2bea601585a4e: Bug 1552081 - part1. Sometimes we should run 'TimeMarchesOn' only when the media element's show poster flag is false. r=jya
Alastor Wu <alwu@mozilla.com> - Fri, 17 May 2019 01:59:34 +0000 - rev 474282
Push 36027 by shindli@mozilla.com at Fri, 17 May 2019 16:24:38 +0000
Bug 1552081 - part1. Sometimes we should run 'TimeMarchesOn' only when the media element's show poster flag is false. r=jya In the following situations, we should only run `TimeMarchesOn` when the media element's `show-poster` flag is false. - add cue : https://html.spec.whatwg.org/multipage/media.html#playing-the-media-resource:time-marches-on-2 - remove cue : https://html.spec.whatwg.org/multipage/media.html#playing-the-media-resource:time-marches-on-3 - track mode changes : https://html.spec.whatwg.org/multipage/media.html#text-track-model:time-marches-on - cue's startTime changes : https://html.spec.whatwg.org/multipage/media.html#text-track-api:time-marches-on - cue's endTime changes : https://html.spec.whatwg.org/multipage/media.html#text-track-api:time-marches-on-2 Differential Revision: https://phabricator.services.mozilla.com/D31376
45d495a1a3a97f659451ce077d17d8e23fba7fb4: Bug 1550585 - no need to check whether media is playing when dispatching 'TimeMarchesOn' and 'UpdateCueDisplay'. r=jya
Alastor Wu <alwu@mozilla.com> - Fri, 17 May 2019 01:12:37 +0000 - rev 474281
Push 36027 by shindli@mozilla.com at Fri, 17 May 2019 16:24:38 +0000
Bug 1550585 - no need to check whether media is playing when dispatching 'TimeMarchesOn' and 'UpdateCueDisplay'. r=jya The spec [1] doesn't mention that we should run `TimeMarchesOn` or `UpdateCueDisplay` only after media starts playing. Removing the checking can help us to render the cue correctly no matter media starts or not. [1] https://html.spec.whatwg.org/multipage/media.html#time-marches-on Differential Revision: https://phabricator.services.mozilla.com/D31504
5ba6d20ec80ad5dcabead733c7bd77df18aa05d7: Bug 1550737 - When shutdown is finished use only a reference of the child. r=jya
Alex Chronopoulos <achronop@gmail.com> - Thu, 16 May 2019 12:59:37 +0000 - rev 474068
Push 36022 by ncsoregi@mozilla.com at Thu, 16 May 2019 21:55:16 +0000
Bug 1550737 - When shutdown is finished use only a reference of the child. r=jya When `RemoteMediaDataDecoder::Shutdown` is finished it is not necessary to hold a reference of the `self` any more. Keep the `mChild` alive, which is the only one needed to destroy the IPDL. In addition to that, deleting the IPDL and destroying the child will be happening at the task queue similar to what was happening before Bug 1545416. Differential Revision: https://phabricator.services.mozilla.com/D31261
d4bbc018fe902044fb90f08b6dc2c0a0d172423d: Bug 1550737 - Make sure we keed strong reference until the end of the method. r=jya.
Alex Chronopoulos <achronop@gmail.com> - Thu, 16 May 2019 14:07:42 +0000 - rev 474067
Push 36022 by ncsoregi@mozilla.com at Thu, 16 May 2019 21:55:16 +0000
Bug 1550737 - Make sure we keed strong reference until the end of the method. r=jya. Instead of deleteing a RefPtr directly copy it in a local variable in order to ensure that the pointer will be alive till the end of the method. In addition to that, on RemoteMediaDataDecpder::Shutdown promise use a reference of the child object instead of the whole `self` object since this is the only one needed. Finally, one style change. Differential Revision: https://phabricator.services.mozilla.com/D30637
126a59b083f619859b308f023bc5c8df49686b3d: Bug 1532495 - part2 : add test 'test_background_video_resume_looping_video_without_audio.html' r=jya
alwu <alwu@mozilla.com> - Thu, 09 May 2019 23:09:44 +0000 - rev 473337
Push 35995 by apavel@mozilla.com at Fri, 10 May 2019 09:50:15 +0000
Bug 1532495 - part2 : add test 'test_background_video_resume_looping_video_without_audio.html' r=jya Add test to to ensure that the looping video (without audio track) which has been suspended can continute to playback correctly after we resume video decoding. Differential Revision: https://phabricator.services.mozilla.com/D30419
5567ad616234db69e9c4aff10805eca281c839ab: Bug 1532495 - part1 : only skip the 'completed' state during seamless looping mode. r=jya
alwu <alwu@mozilla.com> - Thu, 09 May 2019 17:47:52 +0000 - rev 473336
Push 35995 by apavel@mozilla.com at Fri, 10 May 2019 09:50:15 +0000
Bug 1532495 - part1 : only skip the 'completed' state during seamless looping mode. r=jya The normal looping process is that, goes to `completed` state first, notify playback ended, and finally media element would call seek to the start position in order to start looping again. However, if we're in the seamless looping mode, we can stay in `loopingDecoding` state and repeating the looping without going to other states. Otherwise, we should go to `completed` state if decoding has ended. Differential Revision: https://phabricator.services.mozilla.com/D30307
45c3b589ed49c3aa2dab3baf6f8b3c2a513903ec: Bug 1550308 - remove empty wpt ini files. r=jya
alwu <alwu@mozilla.com> - Thu, 09 May 2019 12:22:22 +0000 - rev 473263
Push 35993 by nbeleuzu@mozilla.com at Fri, 10 May 2019 02:54:27 +0000
Bug 1550308 - remove empty wpt ini files. r=jya These ini files are all empty, which didn't include any extra information for testing, so we should remove them. Differential Revision: https://phabricator.services.mozilla.com/D30437
005917cd9f361ea5bebcd9af1000d5799ef724ac: Bug 1548923 - part5 : run `TimeMarchesOn` in correct order r=jya
alwu <alwu@mozilla.com> - Thu, 09 May 2019 01:34:57 +0000 - rev 473259
Push 35993 by nbeleuzu@mozilla.com at Fri, 10 May 2019 02:54:27 +0000
Bug 1548923 - part5 : run `TimeMarchesOn` in correct order r=jya To run `TimeMarchesOn` in correct spec's steps order. Differential Revision: https://phabricator.services.mozilla.com/D30391
c64974ef15b2e1d1b58c8fa5ed16a641179af213: Bug 1548923 - part4 : prevent run `TimeMarchesOn` before media has any data. r=jya
alwu <alwu@mozilla.com> - Thu, 09 May 2019 01:33:36 +0000 - rev 473258
Push 35993 by nbeleuzu@mozilla.com at Fri, 10 May 2019 02:54:27 +0000
Bug 1548923 - part4 : prevent run `TimeMarchesOn` before media has any data. r=jya In patch2, whenever the media element's readyState is changed back to HAVE_NOTHING, we would reset all cues' active flag and update cue display in order to hide them. It also means that we should not set any cue's flag when media element's readyState is `HAVE_NOTHING`, so we should abort the `TimeMarchesOn` in this situation. Differential Revision: https://phabricator.services.mozilla.com/D30390
1a3bb9e678fe8a4d999dbf399d4c3f4d5a1aa6b5: Bug 1548923 - part3 : add test 'test_webvtt_update_display_after_adding_or_removing_cue.html'. r=jya
alwu <alwu@mozilla.com> - Wed, 08 May 2019 17:46:39 +0000 - rev 473257
Push 35993 by nbeleuzu@mozilla.com at Fri, 10 May 2019 02:54:27 +0000
Bug 1548923 - part3 : add test 'test_webvtt_update_display_after_adding_or_removing_cue.html'. r=jya Differential Revision: https://phabricator.services.mozilla.com/D29883
894e0713977b72b7045412e8b70898723a9aacde: Bug 1548923 - part2 : reset cues' active flag when media element's ready state becomes 'HAVE_NOTHING' r=jya
alwu <alwu@mozilla.com> - Wed, 08 May 2019 17:46:39 +0000 - rev 473256
Push 35993 by nbeleuzu@mozilla.com at Fri, 10 May 2019 02:54:27 +0000
Bug 1548923 - part2 : reset cues' active flag when media element's ready state becomes 'HAVE_NOTHING' r=jya According to the spec [1], whenever the media element's readyState is changed back to `HAVE_NOTHING`, we have to reset all cues' active flag and update cue display in order to hide them. [1] https://html.spec.whatwg.org/multipage/media.html#text-track-cue-active-flag Differential Revision: https://phabricator.services.mozilla.com/D30110
667010d35e3418a9b9b2a21086dd411cb931d6e9: Bug 1548923 - part1 : abort 'TimeMarchesOn' algorithm during seeking. r=jya
alwu <alwu@mozilla.com> - Wed, 08 May 2019 17:33:36 +0000 - rev 473255
Push 35993 by nbeleuzu@mozilla.com at Fri, 10 May 2019 02:54:27 +0000
Bug 1548923 - part1 : abort 'TimeMarchesOn' algorithm during seeking. r=jya In the spec [1], it doesn't mention that we should only run `TimeMarchesOn` after media has started. Therefore, we should remove this return condition in order to update cue's state correctly no matter the media starts or not. In addition, according to the spec [2], `TimeMarchesOn` should be executed after seeking completed, we shouldn't not run it during seeking. [1] https://html.spec.whatwg.org/multipage/media.html#time-marches-on [2] https://html.spec.whatwg.org/multipage/media.html#seeking:time-marches-on Differential Revision: https://phabricator.services.mozilla.com/D29882
175f567cd163eb70fd015e585bb0ae74f60c2cfe: Bug 1549642 - handle cue with negative duration. r=jya
alwu <alwu@mozilla.com> - Wed, 08 May 2019 18:09:56 +0000 - rev 473127
Push 35988 by opoprus@mozilla.com at Thu, 09 May 2019 03:32:40 +0000
Bug 1549642 - handle cue with negative duration. r=jya According to the spec [1], the cue's end time might be negative and be smaller than its start time. In this case, when we reach the cue's start on the media time line, we should treat it as a `missing cue` (which won't be actually displayed, but will receive events) when we run the `TimeMarchesOn`. Therefore, we have to add this kind of cue into `otherCue` and let `TimeMarchesOn` handles it properly, to dispatch `enter` and `exit` event for it. [1] https://html.spec.whatwg.org/multipage/media.html#text-track-cue-end-time Differential Revision: https://phabricator.services.mozilla.com/D30242
98918b9e369c5fb7bc421349862c3ffd09b89c8b: Bug 1538023 - Change MDSM::HasLowBufferedData() to consider data buffered after end of decoded data rather than start. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 08 May 2019 04:35:32 +0000 - rev 473011
Push 35985 by dvarga@mozilla.com at Wed, 08 May 2019 11:13:21 +0000
Bug 1538023 - Change MDSM::HasLowBufferedData() to consider data buffered after end of decoded data rather than start. r=jya When under pressure, the MediaCache evicts data before the last read on a stream. We typically have two demuxers reading from different offsets in a stream. So if the MediaCache is under pressure, it may end up evicting data between the two demuxers. The MediaDecoderStateMachine currently goes into buffering state if there's insufficient data available beginning at the start of its queue of decoded samples. However since the MediaCache evicts data behind the streams read cursor, the data after the beginning of the sample queue may have already been evicted by the media cache. This will cause the MediaDecoderStateMachine to enter a buffering state, and if its sample queues are full, there will be no demuxers reading to cause the MediaCache to download the data between the two demuxers, and we'll get stuck in buffering state indefinitely. So change the MediaDecoderStateMachine to instead check whether there's insufficient data available at the end of the decoded sample queues. This means we won't get stuck in buffering state. Note the MediaCache may still evict data which the other demuxer needed, causing us to re-request it, but at least we won't get stuck in buffering state. Differential Revision: https://phabricator.services.mozilla.com/D30310
8e38a89a6d652b199a048628d7d1aa633ae930bd: Bug 1538023 - Add support for -Inf to media::TimeUnits. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 08 May 2019 06:27:03 +0000 - rev 473010
Push 35985 by dvarga@mozilla.com at Wed, 08 May 2019 11:13:21 +0000
Bug 1538023 - Add support for -Inf to media::TimeUnits. r=jya TimeUnits with a negative infinity value are used in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D30309
8a577f046a209ccc0d955d171882a8deaa74d5c9: Bug 1549628 - enable wpt 'track-add-track.html'. r=jya
alwu <alwu@mozilla.com> - Tue, 07 May 2019 18:16:27 +0000 - rev 472943
Push 35983 by ncsoregi@mozilla.com at Wed, 08 May 2019 03:38:51 +0000
Bug 1549628 - enable wpt 'track-add-track.html'. r=jya Added missing event parameter for the callback function of `onaddtrack`. Differential Revision: https://phabricator.services.mozilla.com/D30143
90ebd256a92b6abfa5a701dfac54b40e45ca3351: Bug 1540573 - p7. Modify CSP tests to use preload=2 on (emulated) cellular connections. r=jya
Chris Pearce <cpearce@mozilla.com> - Mon, 06 May 2019 22:43:18 +0000 - rev 472815
Push 35978 by shindli@mozilla.com at Tue, 07 May 2019 09:44:39 +0000
Bug 1540573 - p7. Modify CSP tests to use preload=2 on (emulated) cellular connections. r=jya The Content Security Policy tests were handling the smaller android preload values that were #defined on Android by setting media.preload.default=2. Now that we're detecting whether we're on cellular or not, and the android emulators that our tests run on emulate a cellular connection, just setting media.preload.default is no longer enough. So set media.preload.default.cellular=2 in the CSP mochitests instead of media.preload.default, to make the CSP mochitests pass in the Android emulators. Differential Revision: https://phabricator.services.mozilla.com/D29617
0d175912734db128b3f4fc4dab37a10997d17852: Bug 1540573 - P6. Use frugal preloading of media data when on cellular, otherwise aggressive. r=jya
Chris Pearce <cpearce@mozilla.com> - Mon, 06 May 2019 22:43:14 +0000 - rev 472814
Push 35978 by shindli@mozilla.com at Tue, 07 May 2019 09:44:39 +0000
Bug 1540573 - P6. Use frugal preloading of media data when on cellular, otherwise aggressive. r=jya We're allowed to take some liberties as to what the default value and behaviour we assume for the 'preload' attribute on HTMLMediaElement by the spec. On desktop we assumed preload="metadata", while on mobile we assumed the default of preload="none" to save data. On mobile we also assumed that preload="auto" meant preload="metadata". I think it makes sense to instead of always assuming that data on Android is always expensive, we can instead detect if we're running on a cellular connection, and preload frugally then, otherwise aggressively. Differential Revision: https://phabricator.services.mozilla.com/D26235
07c6d54744f70517f1d5d92789c44335631229da: Bug 1540573 - P5. Only "always throttle" media download to the readahead on cellular connections. r=jya
Chris Pearce <cpearce@mozilla.com> - Mon, 06 May 2019 22:43:09 +0000 - rev 472813
Push 35978 by shindli@mozilla.com at Tue, 07 May 2019 09:44:39 +0000
Bug 1540573 - P5. Only "always throttle" media download to the readahead on cellular connections. r=jya Normally when downloading media data we throttle the download only if we're ahead of the read cursor more than the "readahead limit", and if we estimate that the connection is fast enough that we'll be able to download at a rate fast enough to playback in real time if we resume it later. On mobile we additionally override this so that we always throttle the download once we're ahead of the read cursor by the readahead limit. This is to save data. I think we can relax this to only do this override if we're on a cellular connection; if we're on WiFi we can assume data is cheap. Differential Revision: https://phabricator.services.mozilla.com/D26234
bcbb8c779852193d99648b9a109daf5ffe17058a: Bug 1540573 - P4. Use larger MediaCache sizes when on cellular connection. r=jya
Chris Pearce <cpearce@mozilla.com> - Mon, 06 May 2019 23:38:02 +0000 - rev 472812
Push 35978 by shindli@mozilla.com at Tue, 07 May 2019 09:44:39 +0000
Bug 1540573 - P4. Use larger MediaCache sizes when on cellular connection. r=jya Differential Revision: https://phabricator.services.mozilla.com/D26233
f7adce9bf91ca23f8137bb4cf9cf5630b5f75613: Bug 1548935 - enable wpt 'track-add-remove-cue.html'. r=jya
alwu <alwu@mozilla.com> - Mon, 06 May 2019 01:59:12 +0000 - rev 472760
Push 35978 by shindli@mozilla.com at Tue, 07 May 2019 09:44:39 +0000
Bug 1548935 - enable wpt 'track-add-remove-cue.html'. r=jya If we can't get corresponding cue, `getCueById()` will return `null`, not empty object. Therefore, we should use `assert_equals` instead. Differential Revision: https://phabricator.services.mozilla.com/D29888
2a813680dbefc7febb4be0347b8791b8baa82807: Bug 1535847 - add 'fuzzy' for track-cue-rendering-empty-cue.html. r=jya
alwu <alwu@mozilla.com> - Fri, 03 May 2019 08:21:27 +0000 - rev 472510
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1535847 - add 'fuzzy' for track-cue-rendering-empty-cue.html. r=jya This can fix the 1 color difference intermittent failure problem, it's small enough to be ignored. Differential Revision: https://phabricator.services.mozilla.com/D29773
d000d40067de32c45c46b39a413ad6a9d2949411: Bug 1540760 - Build system changes for aarch64-win64 support in ffvpx; r=jya
Dan Minor <dminor@mozilla.com> - Wed, 01 May 2019 15:04:50 +0000 - rev 472490
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1540760 - Build system changes for aarch64-win64 support in ffvpx; r=jya Differential Revision: https://phabricator.services.mozilla.com/D27790
742b7c0a4bdbbe5f4004b038b4b5b4467ef4484b: Bug 1540760 - Add missing aarch64 files for ffvpx; r=jya
Dan Minor <dminor@mozilla.com> - Wed, 01 May 2019 23:06:25 +0000 - rev 472489
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1540760 - Add missing aarch64 files for ffvpx; r=jya Differential Revision: https://phabricator.services.mozilla.com/D27789
f40ae51578ac27c6ea38af1e2818a12ac0b93dbd: Bug 1540760 - Rerun generate_sources_mozbuild.sh for arm64 windows; r=jya
Dan Minor <dminor@mozilla.com> - Wed, 01 May 2019 15:04:49 +0000 - rev 472488
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1540760 - Rerun generate_sources_mozbuild.sh for arm64 windows; r=jya Differential Revision: https://phabricator.services.mozilla.com/D27788
a338bdcb894fbfbc4412e9f8efefc54667cd32a6: Bug 1540760 - Use arm sources for libvpx; r=jya
Dan Minor <dminor@mozilla.com> - Wed, 01 May 2019 15:04:49 +0000 - rev 472487
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1540760 - Use arm sources for libvpx; r=jya Differential Revision: https://phabricator.services.mozilla.com/D27787
cd666f0befca97073d92bf1c46f39ead6eff3646: Bug 1540760 - Enable neon for libyuv for aarch64; r=jya
Dan Minor <dminor@mozilla.com> - Wed, 01 May 2019 15:04:49 +0000 - rev 472486
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1540760 - Enable neon for libyuv for aarch64; r=jya Differential Revision: https://phabricator.services.mozilla.com/D27786
9de7d7669f41a5df9c61b753767a5713aa9b965d: Bug 1533211 - Remove assertion for if MP4 sample description index is invalid. r=jya
Bryce Van Dyk <bvandyk@mozilla.com> - Fri, 03 May 2019 00:38:10 +0000 - rev 472482
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1533211 - Remove assertion for if MP4 sample description index is invalid. r=jya It's possible for a malformed mp4 to contain invalid sample description index in fragments, that do not reference any sample description entries found in the header. E.g. the header may contain 2 sample description entries (which should be indexed with indices 1 and 2), but for a fragment to contain an index to 4. Instead of asserting in this case we should gracefully fail. Bug 1547328 plans to add logging for this case, so we have a means to still detect failures here from bad files. Depends on D29733 Differential Revision: https://phabricator.services.mozilla.com/D29734
acbe63c7a420bbc2171a1f3377496f1421ba94ae: Bug 1533211 - Add crashtest for MP4 with a bad sample description index. r=jya
Bryce Van Dyk <bvandyk@mozilla.com> - Fri, 03 May 2019 00:38:28 +0000 - rev 472481
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1533211 - Add crashtest for MP4 with a bad sample description index. r=jya Add an mp4 with a bad sample description index to crashtests. When samples in a fragment are encountered, they should reference a sample description entry found in the mp4 header. However, it's possible that the index contained in the fragment may refer to an entry that doesn't exist in the header, as in this file. Differential Revision: https://phabricator.services.mozilla.com/D29733
514ed4bfb0bd41fdb359befe7c30c8c72fee4566: Bug 1548686 - only add RemoteDecoderModule in CreatePDMs if e10s. r=jya
Michael Froman <mfroman@mozilla.com> - Fri, 03 May 2019 00:35:15 +0000 - rev 472480
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1548686 - only add RemoteDecoderModule in CreatePDMs if e10s. r=jya This can cause 1proc tests to fail because no decoder ends up supporting a format. The particular case was enabling Vorbis decoding on RDD. Differential Revision: https://phabricator.services.mozilla.com/D29766
f00e36d2011fb9123158ab5ea3a6b3df6c75761e: Bug 1548113 - pass mEOS from MediaRawData to remote decoder. r=jya
Michael Froman <mfroman@mozilla.com> - Fri, 03 May 2019 00:36:19 +0000 - rev 472479
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1548113 - pass mEOS from MediaRawData to remote decoder. r=jya Lack of mEOS for decoding Vorbis on RDD was causing a mochitest failure with file spacestorm-1000Hz-100ms.ogg in dom/media/test/test_playback.html. The symptom was an incorrect frame count here[1]. [1] https://searchfox.org/mozilla-central/rev/b59a99943de4dd314bae4e44ab43ce7687ccbbec/dom/media/platforms/agnostic/VorbisDecoder.cpp#178 Differential Revision: https://phabricator.services.mozilla.com/D29756
8432594d00d5ccc168b24858ca0041e4cb761b87: Bug 1533215 - Remove assert that can be triggered by malformed MP4. r=jya
Bryce Van Dyk <bvandyk@mozilla.com> - Fri, 03 May 2019 00:48:45 +0000 - rev 472477
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1533215 - Remove assert that can be triggered by malformed MP4. r=jya The assert removed here can be triggered by malformed mp4s that lack certain crypto info (the sinf box), but that still indicate samples are encrypted via sample description entries. I plan to follow up the removal here by adding logs so we have some way to detect this case. This will be done as part of bug 1547328. Depends on D29692 Differential Revision: https://phabricator.services.mozilla.com/D29693
ee6dcf8e69d6c194ef15a3c518734e91fef91a9b: Bug 1533215 - Add crashtest for MP4 with encrypted track with bad sinf. r=jya
Bryce Van Dyk <bvandyk@mozilla.com> - Fri, 03 May 2019 00:49:13 +0000 - rev 472476
Push 35958 by malexandru@mozilla.com at Fri, 03 May 2019 21:56:39 +0000
Bug 1533215 - Add crashtest for MP4 with encrypted track with bad sinf. r=jya Add an mp4 with a mangled tenc box to the crashtests. This file has been fuzzed and appears to have had the tenc box for its second track changed to a '.enc' box, which means it cannot be parsed. The tenc box is contained in the sinf box, so this will bust the sinf parse. We should tolerate such bad files and not assert and/or crash. Driveby add a comment to another line in crashtests list to make it clear the bug the file originally relates to. Differential Revision: https://phabricator.services.mozilla.com/D29692
dd882b8cd73efd56bc92aa1467139699e7e1db6d: Bug 1540573 - p7. Modify CSP tests to use preload=2 on (emulated) cellular connections. r=jya
Chris Pearce <cpearce@mozilla.com> - Fri, 03 May 2019 02:45:06 +0000 - rev 472417
Push 35956 by dluca@mozilla.com at Fri, 03 May 2019 12:59:14 +0000
Bug 1540573 - p7. Modify CSP tests to use preload=2 on (emulated) cellular connections. r=jya The Content Security Policy tests were handling the smaller android preload values that were #defined on Android by setting media.preload.default=2. Now that we're detecting whether we're on cellular or not, and the android emulators that our tests run on emulate a cellular connection, just setting media.preload.default is no longer enough. So set media.preload.default.cellular=2 in the CSP mochitests instead of media.preload.default, to make the CSP mochitests pass in the Android emulators. Differential Revision: https://phabricator.services.mozilla.com/D29617
b10d2cae45f2e0ea7809d60c54e80784ba871429: Bug 1540573 - P6. Use frugal preloading of media data when on cellular, otherwise aggressive. r=jya
Chris Pearce <cpearce@mozilla.com> - Fri, 03 May 2019 02:44:49 +0000 - rev 472416
Push 35956 by dluca@mozilla.com at Fri, 03 May 2019 12:59:14 +0000
Bug 1540573 - P6. Use frugal preloading of media data when on cellular, otherwise aggressive. r=jya We're allowed to take some liberties as to what the default value and behaviour we assume for the 'preload' attribute on HTMLMediaElement by the spec. On desktop we assumed preload="metadata", while on mobile we assumed the default of preload="none" to save data. On mobile we also assumed that preload="auto" meant preload="metadata". I think it makes sense to instead of always assuming that data on Android is always expensive, we can instead detect if we're running on a cellular connection, and preload frugally then, otherwise aggressively. Differential Revision: https://phabricator.services.mozilla.com/D26235
270a8917377f46e18a9948c3335bfbd9b8192449: Bug 1540573 - P5. Only "always throttle" media download to the readahead on cellular connections. r=jya
Chris Pearce <cpearce@mozilla.com> - Fri, 03 May 2019 02:44:31 +0000 - rev 472415
Push 35956 by dluca@mozilla.com at Fri, 03 May 2019 12:59:14 +0000
Bug 1540573 - P5. Only "always throttle" media download to the readahead on cellular connections. r=jya Normally when downloading media data we throttle the download only if we're ahead of the read cursor more than the "readahead limit", and if we estimate that the connection is fast enough that we'll be able to download at a rate fast enough to playback in real time if we resume it later. On mobile we additionally override this so that we always throttle the download once we're ahead of the read cursor by the readahead limit. This is to save data. I think we can relax this to only do this override if we're on a cellular connection; if we're on WiFi we can assume data is cheap. Differential Revision: https://phabricator.services.mozilla.com/D26234
3db059b34e40b810394a4ef355534fe707504699: Bug 1540573 - P4. Use larger MediaCache sizes when on cellular connection. r=jya
Chris Pearce <cpearce@mozilla.com> - Fri, 03 May 2019 02:44:05 +0000 - rev 472414
Push 35956 by dluca@mozilla.com at Fri, 03 May 2019 12:59:14 +0000
Bug 1540573 - P4. Use larger MediaCache sizes when on cellular connection. r=jya Differential Revision: https://phabricator.services.mozilla.com/D26233
6638560366c476bb2d62e4f26eea39b0dfcf4905: Bug 1539030 - (redux) don't attempt RDD launch unless needed. r=jya
Michael Froman <mfroman@mozilla.com> - Thu, 02 May 2019 21:08:58 +0000 - rev 472363
Push 35954 by rgurzau@mozilla.com at Fri, 03 May 2019 04:14:31 +0000
Bug 1539030 - (redux) don't attempt RDD launch unless needed. r=jya Detect content process that already has connection to the RDD process and don't attempt to relaunch or needlessly call RDDProcessManager::CreateContentBridge. Calling CreateContentBridge unnecessarily causes churn by recreating RemoteDecoderManagerParents. Differential Revision: https://phabricator.services.mozilla.com/D29013
3835a514150a7f69310c9e8e8892acdb975e9d9f: Bug 1540748 - part1 : Android decoder should throw an error when the decoded sample's time is smaller than the time of first demuxed sample. r=jolin,jya
Alastor Wu <alwu@mozilla.com> - Thu, 02 May 2019 17:58:05 +0000 - rev 472352
Push 35954 by rgurzau@mozilla.com at Fri, 03 May 2019 04:14:31 +0000
Bug 1540748 - part1 : Android decoder should throw an error when the decoded sample's time is smaller than the time of first demuxed sample. r=jolin,jya Considering that the audio sample's time is always increased, the decoded sample's time decoder returns should always be equal or larger than its demuxed time. When the decoded sample's time is smaller than the time of first demuxed sample, that time would probably cause a problem so we should throw an error for that. Differential Revision: https://phabricator.services.mozilla.com/D28167
8a834fa8a29f76d0a0268db1353d3d556fd2cf56: Bug 1540748 - part0 : mark functions const. r=jya
Alastor Wu <alwu@mozilla.com> - Thu, 02 May 2019 00:51:54 +0000 - rev 472351
Push 35954 by rgurzau@mozilla.com at Fri, 03 May 2019 04:14:31 +0000
Bug 1540748 - part0 : mark functions const. r=jya There functions won't change any internal variables, so they should be marked as const. Differential Revision: https://phabricator.services.mozilla.com/D29590
599e6e06599d34f06a9e1152329bd16e15889613: Bug 1540573 - P6. Use frugal preloading of media data when on cellular, otherwise aggressive. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 01 May 2019 23:48:21 +0000 - rev 472215
Push 35950 by cbrindusan@mozilla.com at Thu, 02 May 2019 09:52:27 +0000
Bug 1540573 - P6. Use frugal preloading of media data when on cellular, otherwise aggressive. r=jya We're allowed to take some liberties as to what the default value and behaviour we assume for the 'preload' attribute on HTMLMediaElement by the spec. On desktop we assumed preload="metadata", while on mobile we assumed the default of preload="none" to save data. On mobile we also assumed that preload="auto" meant preload="metadata". I think it makes sense to instead of always assuming that data on Android is always expensive, we can instead detect if we're running on a cellular connection, and preload frugally then, otherwise aggressively. Differential Revision: https://phabricator.services.mozilla.com/D26235
bf725b7daa5ba219f9a485e8d2b5bbf4ac9934fa: Bug 1540573 - P5. Only "always throttle" media download to the readahead on cellular connections. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 01 May 2019 23:48:17 +0000 - rev 472214
Push 35950 by cbrindusan@mozilla.com at Thu, 02 May 2019 09:52:27 +0000
Bug 1540573 - P5. Only "always throttle" media download to the readahead on cellular connections. r=jya Normally when downloading media data we throttle the download only if we're ahead of the read cursor more than the "readahead limit", and if we estimate that the connection is fast enough that we'll be able to download at a rate fast enough to playback in real time if we resume it later. On mobile we additionally override this so that we always throttle the download once we're ahead of the read cursor by the readahead limit. This is to save data. I think we can relax this to only do this override if we're on a cellular connection; if we're on WiFi we can assume data is cheap. Differential Revision: https://phabricator.services.mozilla.com/D26234
814c94b260288ec39dc4dc552a552d953e8c1d76: Bug 1540573 - P4. Use larger MediaCache sizes when on cellular connection. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 01 May 2019 23:48:13 +0000 - rev 472213
Push 35950 by cbrindusan@mozilla.com at Thu, 02 May 2019 09:52:27 +0000
Bug 1540573 - P4. Use larger MediaCache sizes when on cellular connection. r=jya Differential Revision: https://phabricator.services.mozilla.com/D26233
f188012d248d72153c9a5068b38ba247dac4deb9: Bug 1535005 - part2 : add test. r=jya
Alastor Wu <alwu@mozilla.com> - Wed, 01 May 2019 23:02:38 +0000 - rev 472201
Push 35950 by cbrindusan@mozilla.com at Thu, 02 May 2019 09:52:27 +0000
Bug 1535005 - part2 : add test. r=jya Differential Revision: https://phabricator.services.mozilla.com/D29095
2885da69f0f3b60a9d500e4b9212f219b3476cdc: Bug 1535005 - part1 : no need to update 'mLastTimeMarchesOnCalled' in 'DidSeek()' r=jya
Alastor Wu <alwu@mozilla.com> - Wed, 01 May 2019 23:16:42 +0000 - rev 472200
Push 35950 by cbrindusan@mozilla.com at Thu, 02 May 2019 09:52:27 +0000
Bug 1535005 - part1 : no need to update 'mLastTimeMarchesOnCalled' in 'DidSeek()' r=jya According to spec [1], `mLastTimeMarchesOnCalled` is used to represent the `last time` in step3. It's used to record last time we run `TimeMarchOn()`, so there is no need to upate it on `DidSeek()`. [1] https://html.spec.whatwg.org/multipage/media.html#time-marches-on Differential Revision: https://phabricator.services.mozilla.com/D29094
d8571fb523a061813ecd4e92526f60024dbb87d3: Bug 1540580 - Add crashtest for WebM with 0 sized samples. r=jya
Bryce Van Dyk <bvandyk@mozilla.com> - Tue, 30 Apr 2019 15:12:49 +0000 - rev 471964
Push 35944 by ccoroiu@mozilla.com at Tue, 30 Apr 2019 21:53:37 +0000
Bug 1540580 - Add crashtest for WebM with 0 sized samples. r=jya Depends on D25846 Differential Revision: https://phabricator.services.mozilla.com/D25847
1a102b35a05d4c5d93782755383f13044f433bb2: Bug 1540580 - WebM demuxer skips empty samples. r=jya
Bryce Van Dyk <bvandyk@mozilla.com> - Tue, 30 Apr 2019 15:12:30 +0000 - rev 471963
Push 35944 by ccoroiu@mozilla.com at Tue, 30 Apr 2019 21:53:37 +0000
Bug 1540580 - WebM demuxer skips empty samples. r=jya The mp4 demuxer already does this, so have the WebM case follow suit. This avoids asserts with creating 0 size shmems in the case where the demuxer is being used with the remote data decoder. Differential Revision: https://phabricator.services.mozilla.com/D25846
2787160c8537aa22a3c20ab22b3f1febe4d51715: Bug 1536766 - End a track only after the graph has reported reaching its end time in DecodedStream. r=jya,padenot
Andreas Pehrson <apehrson@mozilla.com> - Wed, 24 Apr 2019 10:56:16 +0000 - rev 470632
Push 35910 by cbrindusan@mozilla.com at Wed, 24 Apr 2019 21:51:39 +0000
Bug 1536766 - End a track only after the graph has reported reaching its end time in DecodedStream. r=jya,padenot This gives us a guarantee that the first frame of a media file can be rendered with a second media element and mozCaptureStream(), even if the file is very very short. With longer video-only files there were also cases where nothing ended up being rendered. Probably because the MediaStreamGraph ended up switching from an AudioCallbackDriver to a SystemClockDriver and this took enough time to put the SourceMediaStream::EndTrack and the SourceMediaStream::AddTrackListener calls for this video track to be processed in the same iteration. The listener would then always lose to the ending track and update main thread state too late, leading to its media element not rendering any frames and nasty intermittent failures. Differential Revision: https://phabricator.services.mozilla.com/D27270
c13cae5f1694af55b169c08ef448ce21f76034dd: Bug 1536766 - Better handle overlapping video frames in DecodedStream::SendVideo. r=jya
Andreas Pehrson <apehrson@mozilla.com> - Wed, 24 Apr 2019 10:55:55 +0000 - rev 470629
Push 35910 by cbrindusan@mozilla.com at Wed, 24 Apr 2019 21:51:39 +0000
Bug 1536766 - Better handle overlapping video frames in DecodedStream::SendVideo. r=jya A case where this wasn't working was bipbop-lateaudio.mp4, where the last frame has duration 0 and starts and ends before the previous frame has ended. The VideoSink still renders this frame at the end of playback, so this patch brings DecodedStream closer to that behavior by rendering all frames with a start time after the previous frame's start time. The track's duration is still based on absolute times so things don't blow up. Differential Revision: https://phabricator.services.mozilla.com/D27267