a622dbe33efb6e9053073ebd8c51cbd3493111dd: Bug 1135544 - Create an abstract base class for a track demuxer; r=kinetik
Anthony Jones <ajones@mozilla.com> - Mon, 02 Mar 2015 16:34:44 +1300 - rev 261591
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1135544 - Create an abstract base class for a track demuxer; r=kinetik
0b402720106c3ab03a2df8ddd0ff6beab9c6bd3b: Bug 1135785 - Hoist some work onto the state machine thread and tighten down our assertions. r=cpearce
Bobby Holley <bobbyholley@gmail.com> - Mon, 23 Feb 2015 15:43:16 -0800 - rev 261590
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1135785 - Hoist some work onto the state machine thread and tighten down our assertions. r=cpearce
6a49d13612c82fae502d59005255068c4ffc2023: Bug 1135785 - Stop manually resetting mCurrentSeekTarget in MDSM::SeekCompleted and rely on the AutoSetOnScopeExit instead. r=cpearce
Bobby Holley <bobbyholley@gmail.com> - Wed, 25 Feb 2015 10:38:49 -0800 - rev 261589
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1135785 - Stop manually resetting mCurrentSeekTarget in MDSM::SeekCompleted and rely on the AutoSetOnScopeExit instead. r=cpearce For some reason the current code is resetting it twice - once explicitly and once with the AutoSetOnScopeExit. To make matters worse, we have a monitor drop between the two. So when DecodeSeek runs on the decode task queue but SeekCompleted runs on the state machine thread, we can start another DecodeSeek during the monitor drop, and then clobber it with the AutoSeetOnScopeExit, causing us to hang. This is a non-issue with the patches in bug 1135170, but necessary to make the patches in this bug independently green.
a9bf129cdbdbb2e736ae4e92ecbe0a6cea52e3f9: Bug 1135785 - Stop invoking StopPlayback in SetDormant. r=cpearce
Bobby Holley <bobbyholley@gmail.com> - Tue, 24 Feb 2015 08:41:23 -0800 - rev 261588
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1135785 - Stop invoking StopPlayback in SetDormant. r=cpearce This already gets incoded in the DECODER_STATE_DORMANT case of RunStateMachine, which will run momentarily on the state machine thread. Doing this allows us to avoid calling StopPlayback on the main thread.
ede75f0e87f0e907ae0977e2fc8599a7a6bed8f2: Bug 1135785 - Return samples on state machine thread. r=cpearce
Bobby Holley <bobbyholley@gmail.com> - Fri, 20 Feb 2015 16:47:05 -0800 - rev 261587
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1135785 - Return samples on state machine thread. r=cpearce This is necessary because we're going to want to start disconnecting sample and seek requests directly from the state machine thread, and the machinery asserts that disconnection happens on the same thread as resolution. More generally, this is the right thing to do architecturally, and will help wean us off the monitor.
2a077477b16c970ce100f41fbba2dde13fc9919d: Bug 1135785 - Make DecodeError safe to run on any thread. r=cpearce
Bobby Holley <bobbyholley@gmail.com> - Sun, 22 Feb 2015 14:16:28 -0800 - rev 261586
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1135785 - Make DecodeError safe to run on any thread. r=cpearce This is necessary so that we can make On{Audio,Video}{,Not}Decoded run on the state machine thread in the next patch.
e637962ba64b4a6dc25965d9179af92c30200815: Bug 1135785 - Make MediaTaskQueue::IsCurrentThreadIn actually do the right thing on release builds. r=cpearce
Bobby Holley <bobbyholley@gmail.com> - Mon, 23 Feb 2015 17:46:55 -0800 - rev 261585
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1135785 - Make MediaTaskQueue::IsCurrentThreadIn actually do the right thing on release builds. r=cpearce The current situation is really dangerous because it compiles on release builds, but just lies. This bit me when I tried to use it for non-assertion purposes. My reading of the reasoning for the current setup in bug 968016 is that we didn't trust nsIEventTarget::IsCurrentThreadOn or thought it might be slow. But the implementation of MediaTaskQueue::IsCurrentThreadIn doesn't actually use that, and indeed currently does all of the work for this feature in release builds anyway.
dc0b58714ffc7c5865bd16e102b61ca91da2fb51: Bug 1135785 - Introduce a 1-argument overload of ProxyMediaCall. r=cpearce
Bobby Holley <bobbyholley@gmail.com> - Sun, 22 Feb 2015 13:56:53 -0800 - rev 261584
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1135785 - Introduce a 1-argument overload of ProxyMediaCall. r=cpearce
264f97c4355288ecf9c85a43e2e0f67234c40687: Bug 1138072 - Don't defer reading to a closed stream. r=roc
Bobby Holley <bobbyholley@gmail.com> - Fri, 27 Feb 2015 16:00:51 -0800 - rev 261583
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1138072 - Don't defer reading to a closed stream. r=roc Other streams in the list bail out of the servicing loop if they're closed, so we can wait indefinitely.
b7ec05265c3319720ffd13ed1a93a25cab9acd05: Bug 1132771 - Implement file-info mach command; r=glandium
Gregory Szorc <gps@mozilla.com> - Fri, 27 Feb 2015 13:58:01 -0800 - rev 261582
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1132771 - Implement file-info mach command; r=glandium Now that we have a mechanism for defining file-based metadata, let's add a mach command to interface with it. Currently, we limit ourselves to simple Bugzilla data dumping. Features will be added over time.
4cc39c54099d3eb7a40cb114e22da2a0da9e419a: Bug 1132771 - Define some bug components; r=glandium
Gregory Szorc <gps@mozilla.com> - Thu, 26 Feb 2015 11:43:45 -0800 - rev 261581
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1132771 - Define some bug components; r=glandium This patch defines bug components for code that I have historically touched.
7eed09d39b9fae0d3a08485129aebaa3b71ff04a: Bug 1132771 - Add Files to moz.build with ability to define Bugzilla component; r=glandium
Gregory Szorc <gps@mozilla.com> - Fri, 27 Feb 2015 13:56:26 -0800 - rev 261580
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1132771 - Add Files to moz.build with ability to define Bugzilla component; r=glandium The Files sub-context allows us to attach metadata to files based on pattern matching rules. Patterns are matched against files in a last-write-wins fashion. The sub-context defines the BUG_COMPONENT variable, which is a 2-tuple (actually a named tuple) defining the Bugzilla product and component for files. There are no consumers yet. But an eventual use case will be to suggest a bug component for a patch/commit. Another will be to automatically suggest a bug component for a failing test.
c3a0cb4b45b17efa64bd8419b08d23d59ffc2883: Bug 1132771 - Support and test for reading without a config object; r=glandium
Gregory Szorc <gps@mozilla.com> - Thu, 26 Feb 2015 10:21:52 -0800 - rev 261579
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1132771 - Support and test for reading without a config object; r=glandium We want the ability to read data from any moz.build file without needing a full build configuration (running configure). This will enable tools to consume metadata by merely having a copy of the source code and nothing more. This commit creates the EmptyConfig object. It is a config object that - as its name implies - is empty. It will be used for reading moz.build files in "no config" mode. Many moz.build files make assumptions that variables in CONFIG are defined and that they are strings. We create the EmptyValue type that behaves like an empty unicode string. Since moz.build files also do some type checking, we carve an exemption for EmptyValue, just like we do for None. We add a test to verify that reading moz.build files in "no config" mode works. This required some minor changes to existing moz.build files to make them work in the new execution mode.
91d34d3107faa777264cdcc9c89456bf4c289466: Bug 1132771 - Add a test for reading all moz.build files in filesystem traversal mode; r=glandium
Gregory Szorc <gps@mozilla.com> - Thu, 26 Feb 2015 09:49:49 -0800 - rev 261578
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1132771 - Add a test for reading all moz.build files in filesystem traversal mode; r=glandium moz.build files should execute in filesystem traversal mode. Add a test that verifies this is true. This test performs a brute force filesystem scan to find relevant moz.build files. This can be a little slow. That's unfortunate. But it's a price we need to pay in order to ensure metadata extraction mode continues to work.
6c44edc8208a54a9d5d830266cded7b409a776e1: Bug 1132771 - Support reading relevant moz.build files; r=glandium
Gregory Szorc <gps@mozilla.com> - Thu, 26 Feb 2015 09:44:55 -0800 - rev 261577
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1132771 - Support reading relevant moz.build files; r=glandium Building on top of the API to retrieve relevant moz.build files for a given path, we introduce a moz.build reading API that reads all moz.build files relevant to a given set of paths. We plan to use this new API to read metadata from moz.build files relevant to a set of files. This patch changes the generator behavior of read_mozbuild to emit the main context before any processing occurs. This allows downstream consumers to manipulate state of the context before things like directory processing occurs. We utilize this capability in the new reading API to forcefully declare the directory traversal order for processed moz.build files, overriding DIRS and similar variables. Since variable exporting doesn't work reliably in this new traversal mode, variable exporting no-ops when this mode is activated.
ed135df395751194bf379584a4d210f14ac849b4: Bug 1132771 - Pass special types down to sandboxes via metadata; r=glandium
Gregory Szorc <gps@mozilla.com> - Thu, 26 Feb 2015 09:43:55 -0800 - rev 261576
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1132771 - Pass special types down to sandboxes via metadata; r=glandium Currently, MozSandbox assumes that the FUNCTIONS, SPECIAL_VARIABLES, and SUBCONTEXTS data structures are the instances that should be associated with the sandbox. As we introduce new moz.build processing modes that wish to change processing behavior, it is necessary for them to have control over these special symbols. This patch moves the declaration of these types to the special metadata dictionary which is inherited during recursion. The "read_topsrcdir" API now explicitly passes the initial metadata into "read_mozbuild".
acdd5491f10ecf8ea4e1a14150f9a2e282e2cf5d: Bug 1132771 - Implement strongly typed named tuples; r=glandium
Gregory Szorc <gps@mozilla.com> - Thu, 26 Feb 2015 09:38:43 -0800 - rev 261575
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1132771 - Implement strongly typed named tuples; r=glandium An upcoming patch introduces a use case for a strongly typed named tuple. So, we introduce a generic factory function that can produce these types.
4013d256b5910404cc04bb3caaf696b8ee551fc5: Bug 1132771 - API to return moz.build files relevant for a set of paths; r=glandium
Gregory Szorc <gps@mozilla.com> - Wed, 25 Feb 2015 14:10:10 -0800 - rev 261574
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1132771 - API to return moz.build files relevant for a set of paths; r=glandium We have an eventual goal to store file-level metadata in moz.build files and to have this metadata "cascade" down directory hierarchies. e.g. metadata in the root directory will apply to all children directories. A prerequisite for this feature is a way to query which moz.build files are relevant to a given file. In this patch, we implement an API that returns this information.
0fa6398b46b980ea673bf6e015a2bf067c97f0a7: Bug 1138240 - Fail faster if a CDM tries to resolve a resolved promise. r=edwin
Chris Pearce <cpearce@mozilla.com> - Mon, 02 Mar 2015 14:13:47 +1300 - rev 261573
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1138240 - Fail faster if a CDM tries to resolve a resolved promise. r=edwin
c6e173b28ecae3617d303bf2218253d3e20f54ac: Bug 1137529: Prefer Apple's VDA hardware acceleration for Hi-Def videos. r=rillian
Jean-Yves Avenard <jyavenard@mozilla.com> - Mon, 02 Mar 2015 10:48:28 +1100 - rev 261572
Push 830 by raliiev@mozilla.com at Fri, 19 Jun 2015 19:24:37 +0000
Bug 1137529: Prefer Apple's VDA hardware acceleration for Hi-Def videos. r=rillian With some GPUs (such as Intel HD-x000), Apple VideoTool box provides poor decoding speed, causing us to drop frames for most HD videos. VDA is around 50 times faster on those machines (31ms average to decode a 4K frame with VT, while 0.6ms average with VDA)
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip