This organizes all public headers for the library into
include/ and makes sure then don't rely on any headers from
other folders.
To accomplish this, this change also refactors macros.h,
media/base/macros.h, and status/status_macros.h into macros/classes.h,
macros/compiler.h, macros/crypto.h, macros/logging.h, macros/status.h,
and public/export.h. Now the export macros from macros.h live in
include/ to keep include/ from requiring anything else.
This refactor enables an install target that includes public headers
only.
---------
Co-authored-by: Cosmin Stejerean <cstejerean@meta.com>
Reorder headers to follow the Google C++ Style Guide:
> In dir/foo.cc or dir/foo_test.cc:
>
> 1. dir2/foo2.h.
> 2. A blank line
> 3. C system headers (more precisely: headers in angle brackets with
the .h extension), e.g., <unistd.h>, <stdlib.h>.
> 4. A blank line
> 5. C++ standard library headers (without file extension), e.g.,
<algorithm>, <cstddef>.
> 6. A blank line
> 7. Other libraries' .h files.
> 8. A blank line
> 9. Your project's .h files.
https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes
This feeds into efforts to create a working install target.
The order of headers is still funky, and was "fixed" by clang-format,
but in a way that doesn't exactly align with the style guide. Further
cleanup of header order is coming in a follow-up PR.
CENCv3 recommends only encrypting video data in slice NALs. Slice
data partition NALs should not be encrypted.
In the code, differentiate is_vcl and is_video_slice. They are the
same for H265; for H264, vcl NALs include slice data partition NALs
but video_slice NALs do not.
Change-Id: I91f4bdd76d25f0eac50e39aed350ebce3f667121
In H264, there may be multiple consecutive video slice NAL units
in the same frame. The original code assigns a new access unit
for every video slice NAL unit, which is incorrect.
Fixes#134.
Change-Id: I4d44271df48cb08867ddd02f7494fb3573af3356
Joey Parrish
Carlos Bentzen
Haoming Chen
Rintaro Kuroiwa
Kongqun Yang