2015-01-20 08:39:00 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
|
|
|
#ifndef GMPUtils_h_
|
|
|
|
#define GMPUtils_h_
|
|
|
|
|
|
|
|
#include "mozilla/UniquePtr.h"
|
2017-02-23 04:04:25 +03:00
|
|
|
#include "mozilla/RefPtr.h"
|
|
|
|
#include "mozilla/AbstractThread.h"
|
2017-08-17 02:48:52 +03:00
|
|
|
#include "nsStringFwd.h"
|
2015-08-11 01:27:41 +03:00
|
|
|
#include "nsTArray.h"
|
2015-11-27 00:53:17 +03:00
|
|
|
#include "nsCOMPtr.h"
|
2016-02-09 04:37:22 +03:00
|
|
|
#include "nsClassHashtable.h"
|
2015-01-20 08:39:00 +03:00
|
|
|
|
2017-02-21 23:26:47 +03:00
|
|
|
#define CHROMIUM_CDM_API "chromium-cdm8-host4"
|
|
|
|
|
2015-05-29 05:07:22 +03:00
|
|
|
class nsIFile;
|
2015-11-27 00:53:17 +03:00
|
|
|
class nsISimpleEnumerator;
|
2015-05-29 05:07:22 +03:00
|
|
|
|
2015-01-20 08:39:00 +03:00
|
|
|
namespace mozilla {
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
struct DestroyPolicy
|
|
|
|
{
|
|
|
|
void operator()(T* aGMPObject) const {
|
|
|
|
aGMPObject->Destroy();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<typename T>
|
2015-04-17 19:43:18 +03:00
|
|
|
using GMPUniquePtr = mozilla::UniquePtr<T, DestroyPolicy<T>>;
|
2015-01-20 08:39:00 +03:00
|
|
|
|
2015-08-11 01:27:41 +03:00
|
|
|
void
|
|
|
|
SplitAt(const char* aDelims,
|
|
|
|
const nsACString& aInput,
|
|
|
|
nsTArray<nsCString>& aOutTokens);
|
|
|
|
|
2015-08-14 10:18:19 +03:00
|
|
|
nsCString
|
2016-12-21 00:37:09 +03:00
|
|
|
ToHexString(const nsTArray<uint8_t>& aBytes);
|
2016-12-20 23:54:20 +03:00
|
|
|
|
2016-12-21 00:37:09 +03:00
|
|
|
nsCString
|
2016-12-20 23:54:20 +03:00
|
|
|
ToHexString(const uint8_t* aBytes, uint32_t aLength);
|
|
|
|
|
2015-10-14 02:18:06 +03:00
|
|
|
bool
|
|
|
|
FileExists(nsIFile* aFile);
|
|
|
|
|
2015-11-27 00:53:17 +03:00
|
|
|
// Enumerate directory entries for a specified path.
|
|
|
|
class DirectoryEnumerator {
|
|
|
|
public:
|
|
|
|
|
|
|
|
enum Mode {
|
|
|
|
DirsOnly, // Enumeration only includes directories.
|
|
|
|
FilesAndDirs // Enumeration includes directories and non-directory files.
|
|
|
|
};
|
|
|
|
|
|
|
|
DirectoryEnumerator(nsIFile* aPath, Mode aMode);
|
|
|
|
|
|
|
|
already_AddRefed<nsIFile> Next();
|
|
|
|
|
|
|
|
private:
|
|
|
|
Mode mMode;
|
|
|
|
nsCOMPtr<nsISimpleEnumerator> mIter;
|
|
|
|
};
|
|
|
|
|
2016-02-09 04:37:22 +03:00
|
|
|
class GMPInfoFileParser {
|
|
|
|
public:
|
|
|
|
bool Init(nsIFile* aFile);
|
|
|
|
bool Contains(const nsCString& aKey) const;
|
|
|
|
nsCString Get(const nsCString& aKey) const;
|
|
|
|
private:
|
|
|
|
nsClassHashtable<nsCStringHashKey, nsCString> mValues;
|
|
|
|
};
|
|
|
|
|
2016-04-12 07:12:21 +03:00
|
|
|
bool
|
|
|
|
ReadIntoString(nsIFile* aFile,
|
|
|
|
nsCString& aOutDst,
|
|
|
|
size_t aMaxLength);
|
|
|
|
|
2016-11-03 04:33:31 +03:00
|
|
|
bool
|
|
|
|
HaveGMPFor(const nsCString& aAPI,
|
|
|
|
nsTArray<nsCString>&& aTags);
|
|
|
|
|
2017-02-21 03:44:58 +03:00
|
|
|
void
|
|
|
|
LogToConsole(const nsAString& aMsg);
|
|
|
|
|
2017-02-23 04:04:25 +03:00
|
|
|
RefPtr<AbstractThread>
|
|
|
|
GetGMPAbstractThread();
|
|
|
|
|
Bug 1351953 - Pre-allocate shmems for the CDM process to use for storing decrypted and audio samples. r=gerald
Makes transfer of samples between the content and CDM processes use shmems.
The Chromium CDM API requires us to implement a synchronous interface to supply
buffers to the CDM for it to write decrypted samples into. We want our buffers
to be backed by shmems, in order to reduce the overhead of transferring decoded
frames. However due to sandboxing restrictions, the CDM process cannot allocate
shmems itself. We don't want to be doing synchronous IPC to request shmems
from the content process, nor do we want to have to do intr IPC or make async
IPC conform to the sync allocation interface. So instead we have the content
process pre-allocate a set of shmems and give them to the CDM process in
advance of them being needed.
When the CDM needs to allocate a buffer for storing a decrypted sample, the CDM
host gives it one of these shmems' buffers. When this is sent back to the
content process, we copy the result out (uploading to a GPU surface for video
frames), and send the shmem back to the CDM process so it can reuse it.
We predict the size of buffer the CDM will allocate, and prepopulate the CDM's
list of shmems with shmems of at least that size, plus a bit of padding for
safety. We pad frames out to be the next multiple of 16, as we've seen some
decoders do that.
Normally the CDM won't allocate more than one buffer at once, but we've seen
cases where it allocates two buffers, returns one and holds onto the other. So
the minimum number of shmems we give to the CDM must be at least two, and the
default is three for safety.
MozReview-Commit-ID: 5FaWAst3aeh
--HG--
extra : rebase_source : a0cb126e72bfb2905bcdf02e864dc654e8340410
2017-03-28 08:59:11 +03:00
|
|
|
// Returns the number of bytes required to store an aWidth x aHeight image in
|
|
|
|
// I420 format, padded so that the width and height are multiples of 16.
|
2017-04-27 23:55:28 +03:00
|
|
|
size_t
|
Bug 1351953 - Pre-allocate shmems for the CDM process to use for storing decrypted and audio samples. r=gerald
Makes transfer of samples between the content and CDM processes use shmems.
The Chromium CDM API requires us to implement a synchronous interface to supply
buffers to the CDM for it to write decrypted samples into. We want our buffers
to be backed by shmems, in order to reduce the overhead of transferring decoded
frames. However due to sandboxing restrictions, the CDM process cannot allocate
shmems itself. We don't want to be doing synchronous IPC to request shmems
from the content process, nor do we want to have to do intr IPC or make async
IPC conform to the sync allocation interface. So instead we have the content
process pre-allocate a set of shmems and give them to the CDM process in
advance of them being needed.
When the CDM needs to allocate a buffer for storing a decrypted sample, the CDM
host gives it one of these shmems' buffers. When this is sent back to the
content process, we copy the result out (uploading to a GPU surface for video
frames), and send the shmem back to the CDM process so it can reuse it.
We predict the size of buffer the CDM will allocate, and prepopulate the CDM's
list of shmems with shmems of at least that size, plus a bit of padding for
safety. We pad frames out to be the next multiple of 16, as we've seen some
decoders do that.
Normally the CDM won't allocate more than one buffer at once, but we've seen
cases where it allocates two buffers, returns one and holds onto the other. So
the minimum number of shmems we give to the CDM must be at least two, and the
default is three for safety.
MozReview-Commit-ID: 5FaWAst3aeh
--HG--
extra : rebase_source : a0cb126e72bfb2905bcdf02e864dc654e8340410
2017-03-28 08:59:11 +03:00
|
|
|
I420FrameBufferSizePadded(int32_t aWidth, int32_t aHeight);
|
|
|
|
|
2015-01-20 08:39:00 +03:00
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif
|