Implement WiFi Display elementary stream packetizer.

[chrome.displaySource] Implement elementary stream packetizer.

The WiFi Display elementary stream packetizer packetizes unit buffers to
Packetized Elementary Stream (PES) packets. It will be used internally by
a WiFi Display transport stream packetizer.

This is part of a WiFi Display packetizer patch series:
 * https://codereview.chromium.org/1796123002/  <-- this CL
   WiFi Display elementary stream packetizer
 * https://codereview.chromium.org/1800493003/
   WiFi Display elementary stream descriptors
 * https://codereview.chromium.org/1797953002/
   WiFi Display transport stream packetizer
 * https://codereview.chromium.org/1796073003/
   WiFi Display media packetizer

BUG=242107
Committed: https://crrev.com/dc1557a2f96a9a8d85eec584ae22176352aee13d
Cr-Commit-Position: refs/heads/master@{#381945}

[e_hakkinen, 2016-03-14 10:26:00]

Description was changed from

==========
WIP: Implement WiFi Display elementary stream packetizer.
==========

to

==========
Implement WiFi Display elementary stream packetizer.

This is part of a WiFi Display packetizer patch series:
 * https://codereview.chromium.org/1796123002/
   WiFi Display elementary stream packetizer
 * https://codereview.chromium.org/1800493003/
   WiFi Display elementary stream descriptors
 * https://codereview.chromium.org/1797953002/
   WiFi Display transport stream packetizer
 * https://codereview.chromium.org/1796073003/
   WiFi Display media packetizer
==========

[e_hakkinen, 2016-03-14 10:26:00]

eero.hakkinen@intel.com changed reviewers:
+ alexander.shalamov@intel.com, mikhail.pozdnyakov@intel.com

[e_hakkinen, 2016-03-14 11:18:47]

Description was changed from

==========
Implement WiFi Display elementary stream packetizer.

This is part of a WiFi Display packetizer patch series:
 * https://codereview.chromium.org/1796123002/
   WiFi Display elementary stream packetizer
 * https://codereview.chromium.org/1800493003/
   WiFi Display elementary stream descriptors
 * https://codereview.chromium.org/1797953002/
   WiFi Display transport stream packetizer
 * https://codereview.chromium.org/1796073003/
   WiFi Display media packetizer
==========

to

==========
[chrome.displaySource] Implement elementary stream packetizer.

The WiFi Display elementary stream packetizer packetizes unit buffers to
Packetized Elementary Stream (PES) packets. It will be used internally by
a WiFi Display transport stream packetizer.

This is part of a WiFi Display packetizer patch series:
 * https://codereview.chromium.org/1796123002/  <-- this CL
   WiFi Display elementary stream packetizer
 * https://codereview.chromium.org/1800493003/
   WiFi Display elementary stream descriptors
 * https://codereview.chromium.org/1797953002/
   WiFi Display transport stream packetizer
 * https://codereview.chromium.org/1796073003/
   WiFi Display media packetizer

BUG=242107
==========

[e_hakkinen, 2016-03-14 14:23:56]

Patchset #1 (id:1) has been deleted

[e_hakkinen, 2016-03-14 14:46:06]

eero.hakkinen@intel.com changed reviewers:
+ asargent@chromium.org, jochen@chromium.org

[e_hakkinen, 2016-03-14 14:46:07]

PTAL.

@jochen for build/
@asargent, @Mikhail, @shalamov for extensions/

[Mikhail, 2016-03-14 17:53:08]

lgtm with some nits

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc
(right):

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:32:
uint64_t const us =
nit: const uint64_t

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:34:
uint64_t const n = (us * 90u + 999u) / 1000u;
ditto.

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:62:
!pts.is_null() ? !dts.is_null() ? 0x3u : 0x2u : 0x0u;
pls use brackets to improve readability

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h
(right):

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:25:
WiFiDisplayStreamPacketPart(const uint8_t (&data)[N])
explicit

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:28:
WiFiDisplayStreamPacketPart(const WiFiDisplayStreamPacketPart&& other)
should it be move ctor? if so, (WiFiDisplayStreamPacketPart&& other) // 'const'
not needed

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:29:
: WiFiDisplayStreamPacketPart(other.data(), other.size()) {DCHECK(false);}
NOTREACHED()

[e_hakkinen, 2016-03-15 10:12:44]

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc
(right):

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:32:
uint64_t const us =
On 2016/03/14 17:53:08, Mikhail wrote:
> nit: const uint64_t

Done.

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:34:
uint64_t const n = (us * 90u + 999u) / 1000u;
On 2016/03/14 17:53:08, Mikhail wrote:
> ditto.

Done.

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:62:
!pts.is_null() ? !dts.is_null() ? 0x3u : 0x2u : 0x0u;
On 2016/03/14 17:53:08, Mikhail wrote:
> pls use brackets to improve readability

Done.

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h
(right):

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:25:
WiFiDisplayStreamPacketPart(const uint8_t (&data)[N])
On 2016/03/14 17:53:08, Mikhail wrote:
> explicit

Done.

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:28:
WiFiDisplayStreamPacketPart(const WiFiDisplayStreamPacketPart&& other)
On 2016/03/14 17:53:08, Mikhail wrote:
> should it be move ctor?

Yes, it is a move ctor with a const rvalue reference.

> if so, (WiFiDisplayStreamPacketPart&& other) // 'const' not needed

'const' is needed so that WiFiDisplayElementaryStreamPacket with its const
member variables compiles.

I'll change WiFiDisplayElementaryStreamPacket so that it does not have const
member variables (that does not really change anything much as those member
variables contains only const data so it does not matter much whether the member
variables itself are const). After that, I can define move ctor with non-const
rvalue reference here.

That will make it all much less unusual.

https://codereview.chromium.org/1796123002/diff/20001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:29:
: WiFiDisplayStreamPacketPart(other.data(), other.size()) {DCHECK(false);}
On 2016/03/14 17:53:08, Mikhail wrote:
> NOTREACHED()

Sorry, the DCHECK was for testing.
I'd rather remove the DCHECK completely. This ctor does the right thing, after
all.

[jochen (gone - plz use gerrit), 2016-03-15 20:34:42]

build/ lgtm

[Mikhail, 2016-03-16 11:22:55]

CC'ing Mark Scott and Mark Foltz

[asargent_no_longer_on_chrome, 2016-03-16 22:47:58]

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc
(right):

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:15:
namespace pes {
Is any of the code here used outside of this .cc file? If not, we typically use
unnamed namespaces instead of named ones for that. See:

http://dev.chromium.org/developers/coding-style#TOC-Unnamed-namespaces
https://google.github.io/styleguide/cppguide.html#Namespaces

(I'm not sure there's a hard and fast rule *against* using named namespaces for
code that's local to a .cc file, but it's certainly unusual in the extensions
code, so probably best to match the local style)

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:124:
dst[j++] = 0x00u;  // Packet start code prefix (0x000001).
nit: this comment is sort of confusing - it's not immediately clear to me why
you have "(0x000001)" in the comment when the value being set is 0x00u

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.h
(right):

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.h:18:
using Part = WiFiDisplayStreamPacketPart;
nit: I'm not sure that the "Part" alias really aids in readability, since it's
only used AFAICT in this header

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.h:36:
};
nit: add DISALLOW_COPY_AND_ASSIGN

(also make sure to run 'git cl lint', which I think would catch this)

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.h:58:
const base::TimeTicks& dts);
Is there a reason this isn't a static method? There aren't any data members in
this class.

Perhaps this method should this just live in WiFiDisplayElementaryStreamPacket
instead of having a separate class?

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h
(right):

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:23:
: data_(data), size_(size) {}
nit: inlining constructors is discouraged

http://dev.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-in...

(here and below)

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:29:
: WiFiDisplayStreamPacketPart(other.data(), other.size()) {}
I may be misunderstanding what you're trying to accomplish here, but do you want
to use Function Suppression, ie "= delete", if this should never be called? 

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/i1o7-RNRnMs

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:34:
const uint8_t* end() const { return data() + size(); }
consider not inlining this function

http://dev.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-in...

[e_hakkinen, 2016-03-17 15:29:27]

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc
(right):

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:15:
namespace pes {
On 2016/03/16 22:47:57, Antony Sargent wrote:
> Is any of the code here used outside of this .cc file?

No, it is not used outside of this .cc file (and cannot be used as it is within
an anonymous namespace).

> If not, we typically use unnamed namespaces instead of named ones for that.

It is an anonymous namespace (extensions::(anonymous namespace)::pes).
IMHO, it is useful as it documents that what is inside it comes from the PES
specification.

WDYT?

It is of course less relevant here than in WiFiDisplayTransportStreamPacketizer
(https://crrev.com/1797953002/patch/40001/50005) where there are pieces from the
PES (Program Specific Information) specification, from TS (MPEG Transport
Stream) specification and from the WiDi (WiFi Display) specification.

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:124:
dst[j++] = 0x00u;  // Packet start code prefix (0x000001).
On 2016/03/16 22:47:57, Antony Sargent wrote:
> nit: this comment is sort of confusing - it's not immediately clear to me why
> you have "(0x000001)" in the comment when the value being set is 0x00u

Added " in three bytes".

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.h
(right):

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.h:18:
using Part = WiFiDisplayStreamPacketPart;
On 2016/03/16 22:47:57, Antony Sargent wrote:
> nit: I'm not sure that the "Part" alias really aids in readability, since it's
> only used AFAICT in this header

Done.

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.h:36:
};
On 2016/03/16 22:47:58, Antony Sargent wrote:
> nit: add DISALLOW_COPY_AND_ASSIGN

Done.

> (also make sure to run 'git cl lint', which I think would catch this)

Done, too. It did not catch anything.
For disallow macros, there are tests that they are not used incorrectly.
There are no tests that disallow macros are used correctly or at all.

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.h:58:
const base::TimeTicks& dts);
On 2016/03/16 22:47:58, Antony Sargent wrote:
> Is there a reason this isn't a static method? There aren't any data members in
> this class.
> 
> Perhaps this method should this just live in WiFiDisplayElementaryStreamPacket
> instead of having a separate class?

Not really. Done.

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h
(right):

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:23:
: data_(data), size_(size) {}
On 2016/03/16 22:47:58, Antony Sargent wrote:
> nit: inlining constructors is discouraged
> 
>
http://dev.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-in...
> 
> (here and below)

But since there is no inheritance, no explicit destructor and only a few POD
members, isn't it OK to inline?

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:29:
: WiFiDisplayStreamPacketPart(other.data(), other.size()) {}
On 2016/03/16 22:47:58, Antony Sargent wrote:
> I may be misunderstanding what you're trying to accomplish here, but do you
want
> to use Function Suppression, ie "= delete", if this should never be called?

It should never be called but it should still be available so that compiler is
allowed to elide the calls and do return value optimization.
But maybe it is more clear to move it to WiFiDisplayElementaryStreamPacket there
move constructibility is needed.

[asargent_no_longer_on_chrome, 2016-03-17 18:22:59]

lgtm

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc
(right):

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:15:
namespace pes {
On 2016/03/17 15:29:26, e_hakkinen wrote:
> On 2016/03/16 22:47:57, Antony Sargent wrote:
> > Is any of the code here used outside of this .cc file?
> 
> No, it is not used outside of this .cc file (and cannot be used as it is
within
> an anonymous namespace).
> 
> > If not, we typically use unnamed namespaces instead of named ones for that.
> 
> It is an anonymous namespace (extensions::(anonymous namespace)::pes).
> IMHO, it is useful as it documents that what is inside it comes from the PES
> specification.
> 
> WDYT?
> 
> It is of course less relevant here than in
WiFiDisplayTransportStreamPacketizer
> (https://crrev.com/1797953002/patch/40001/50005) where there are pieces from
the
> PES (Program Specific Information) specification, from TS (MPEG Transport
> Stream) specification and from the WiDi (WiFi Display) specification.

Ok, that makes sense. You might just consider making the comment slightly more
descriptive, e.g. something like:

// Code related to the Packetized Elementary Stream (PES) specification
namespace pes {
  ...
}  // namespace pes


but I'll leave that up to you.

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:124:
dst[j++] = 0x00u;  // Packet start code prefix (0x000001).
On 2016/03/17 15:29:26, e_hakkinen wrote:
> On 2016/03/16 22:47:57, Antony Sargent wrote:
> > nit: this comment is sort of confusing - it's not immediately clear to me
why
> > you have "(0x000001)" in the comment when the value being set is 0x00u
> 
> Added " in three bytes".

ah, thanks, that makes it much more clear

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h
(right):

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:23:
: data_(data), size_(size) {}
On 2016/03/17 15:29:26, e_hakkinen wrote:
> On 2016/03/16 22:47:58, Antony Sargent wrote:
> > nit: inlining constructors is discouraged
> > 
> >
>
http://dev.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-in...
> > 
> > (here and below)
> 
> But since there is no inheritance, no explicit destructor and only a few POD
> members, isn't it OK to inline?

Ok, since it has only POD members it should be alright to leave as you have it,
assuming that this will actually be performance sensitive code. (The only danger
I see is that in some future refactor, we might add some non-POD data members
and forget to de-inline the constructor).

https://codereview.chromium.org/1796123002/diff/60001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_stream_packet_part.h:29:
: WiFiDisplayStreamPacketPart(other.data(), other.size()) {}
On 2016/03/17 15:29:26, e_hakkinen wrote:
> On 2016/03/16 22:47:58, Antony Sargent wrote:
> > I may be misunderstanding what you're trying to accomplish here, but do you
> want
> > to use Function Suppression, ie "= delete", if this should never be called?
> 
> It should never be called but it should still be available so that compiler is
> allowed to elide the calls and do return value optimization.
> But maybe it is more clear to move it to WiFiDisplayElementaryStreamPacket
there
> move constructibility is needed.

ok

https://codereview.chromium.org/1796123002/diff/80001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc
(right):

https://codereview.chromium.org/1796123002/diff/80001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:164:
WiFiDisplayElementaryStreamPacket
I forgot to mention that we have a convention of annotating static methods in
the .cc file with a comment like this:

// static
void SomeClass::SomeMethod() {
  ...
}

[e_hakkinen, 2016-03-18 10:19:11]

On 2016/03/17 18:22:59, Antony Sargent wrote:
> Ok, that makes sense. You might just consider making the comment slightly more
> descriptive, e.g. something like:
> 
> // Code related to the Packetized Elementary Stream (PES) specification
> namespace pes {
>   ...
> }  // namespace pes
> 
> 
> but I'll leave that up to you.

Done.

https://codereview.chromium.org/1796123002/diff/80001/extensions/renderer/api...
File
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc
(right):

https://codereview.chromium.org/1796123002/diff/80001/extensions/renderer/api...
extensions/renderer/api/display_source/wifi_display/wifi_display_elementary_stream_packetizer.cc:164:
WiFiDisplayElementaryStreamPacket
On 2016/03/17 18:22:59, Antony Sargent wrote:
> I forgot to mention that we have a convention of annotating static methods in
> the .cc file with a comment like this:
> 
> // static
> void SomeClass::SomeMethod() {
>   ...
> }
> 
> 

Done.

[e_hakkinen, 2016-03-18 10:24:23]

The CQ bit was checked by eero.hakkinen@intel.com

[e_hakkinen, 2016-03-18 10:24:23]

The patchset sent to the CQ was uploaded after l-g-t-m from
mikhail.pozdnyakov@intel.com, jochen@chromium.org, asargent@chromium.org
Link to the patchset: https://codereview.chromium.org/1796123002/#ps100001
(title: "Comments")

[commit-bot: I haz the power, 2016-03-18 10:24:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1796123002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1796123002/100001

[commit-bot: I haz the power, 2016-03-18 12:52:01]

Description was changed from

==========
[chrome.displaySource] Implement elementary stream packetizer.

The WiFi Display elementary stream packetizer packetizes unit buffers to
Packetized Elementary Stream (PES) packets. It will be used internally by
a WiFi Display transport stream packetizer.

This is part of a WiFi Display packetizer patch series:
 * https://codereview.chromium.org/1796123002/  <-- this CL
   WiFi Display elementary stream packetizer
 * https://codereview.chromium.org/1800493003/
   WiFi Display elementary stream descriptors
 * https://codereview.chromium.org/1797953002/
   WiFi Display transport stream packetizer
 * https://codereview.chromium.org/1796073003/
   WiFi Display media packetizer

BUG=242107
==========

to

==========
[chrome.displaySource] Implement elementary stream packetizer.

The WiFi Display elementary stream packetizer packetizes unit buffers to
Packetized Elementary Stream (PES) packets. It will be used internally by
a WiFi Display transport stream packetizer.

This is part of a WiFi Display packetizer patch series:
 * https://codereview.chromium.org/1796123002/  <-- this CL
   WiFi Display elementary stream packetizer
 * https://codereview.chromium.org/1800493003/
   WiFi Display elementary stream descriptors
 * https://codereview.chromium.org/1797953002/
   WiFi Display transport stream packetizer
 * https://codereview.chromium.org/1796073003/
   WiFi Display media packetizer

BUG=242107
==========

[commit-bot: I haz the power, 2016-03-18 12:52:02]

Committed patchset #5 (id:100001)

[commit-bot: I haz the power, 2016-03-18 12:53:19]

Description was changed from

==========
[chrome.displaySource] Implement elementary stream packetizer.

The WiFi Display elementary stream packetizer packetizes unit buffers to
Packetized Elementary Stream (PES) packets. It will be used internally by
a WiFi Display transport stream packetizer.

This is part of a WiFi Display packetizer patch series:
 * https://codereview.chromium.org/1796123002/  <-- this CL
   WiFi Display elementary stream packetizer
 * https://codereview.chromium.org/1800493003/
   WiFi Display elementary stream descriptors
 * https://codereview.chromium.org/1797953002/
   WiFi Display transport stream packetizer
 * https://codereview.chromium.org/1796073003/
   WiFi Display media packetizer

BUG=242107
==========

to

==========
[chrome.displaySource] Implement elementary stream packetizer.

The WiFi Display elementary stream packetizer packetizes unit buffers to
Packetized Elementary Stream (PES) packets. It will be used internally by
a WiFi Display transport stream packetizer.

This is part of a WiFi Display packetizer patch series:
 * https://codereview.chromium.org/1796123002/  <-- this CL
   WiFi Display elementary stream packetizer
 * https://codereview.chromium.org/1800493003/
   WiFi Display elementary stream descriptors
 * https://codereview.chromium.org/1797953002/
   WiFi Display transport stream packetizer
 * https://codereview.chromium.org/1796073003/
   WiFi Display media packetizer

BUG=242107

Committed: https://crrev.com/dc1557a2f96a9a8d85eec584ae22176352aee13d
Cr-Commit-Position: refs/heads/master@{#381945}
==========

[commit-bot: I haz the power, 2016-03-18 12:53:20]

Patchset 5 (id:??) landed as
https://crrev.com/dc1557a2f96a9a8d85eec584ae22176352aee13d
Cr-Commit-Position: refs/heads/master@{#381945}