Fix a crash in URLFetcherCore by handling a case where |request_| is NULL

This is a speculative fix for the crash:
https://crash-old.corp.google.com/reportdetail?reportid=4897b184b09b23c8#crashing_thread

My hypothesis is that the request is released while there is a pending call to DidWriteBuffer().
The request was maybe released because
- the fetch was stopped or cancelled
- or ReleaseRequest() was called in OnReadCompleted


BUG=308626, 314241

Review URL: https://codereview.chromium.org/46573008

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@232929 0039d316-1c4b-4281-b951-d872f2087c98
[Ozone] Rename software implementation files to use Dri

Avoiding the DRM prefix such that it isn't confused with Digital Rights
Management.

BUG=

Review URL: https://codereview.chromium.org/49303002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@232930 0039d316-1c4b-4281-b951-d872f2087c98
chrome.windows.create should return new window id in Guest mode

Some context: Chrome OS Guest mode is incognito mode and user extensions are
disabled but we have couple component extensions that work in Guest mode.
QuickOffice is one of them. It uses incognito split mode and runs in incognito
profile. CanCrossIncognito returns false if extension runs in not split mode.
Therefore include_incognito is false. But in general there is no problem
if chrome.windows.create return incognito window if extension itself already
works in incognito mode.

BUG=313789
TEST=manual

Review URL: https://codereview.chromium.org/49463006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@232931 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 232931
media: Increase max number of decode threads for VP9 decodes at higher resolutions.

This improves decode performance of VP9 input encoded with tiling enabled.  Each 
tile must be at least 256 pixels wide. The number of tile columns are log2. So encoded
files can have 1, 2, 4, 8, 16 tile columns. E.g. 1920x1080 files can have up to 4
encoded tile columns. Tile rows do not matter for decode performance.

Specifically, any system with multiple cores and/or hyper threading will
benefit from this change.

On desktop 1080p decode speed is roughly 1.5-2x with this change. For example, 
on the low end of the results from the test set used to produce these numbers 
an average increase is from 82 frames/second to 163 frames/second.

This holds on Android devices as well, with the same clip on a Nexus 7 going
from 14 frames/second to 25. Chrome OS shows similar gains. This puts some 1080p 
in the playable range and gives 720p more clearance.

Review URL: https://codereview.chromium.org/55213002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@232932 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 232932