This makes WR properly handle mPicSize when RenderBufferTextureHost is used.
The main change is that we need to take care to pass in display().Size() from
the descriptor, and then further use that to carefully limit the size of the
CbCr texture, as it doesn't necessarily maintain an appropriate half-sized
scale with respect to the Y texture if it is padded.
Given that mPicSize should now actually work, we should no longer need any
of the previous mCroppedSize mechanisms that were added to work around this,
and so they are removed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D139267
Before Bug 1713276 fix, BufferTextureData of ffmpeg decoded video was recycled.
ShmemTextureData::CropYCbCrPlanes() changed BufferDescriptor. And it blocks the BufferTextureData to be recycled. The BufferDescriptor needs to be restored to original value before recycling.
Differential Revision: https://phabricator.services.mozilla.com/D137829
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
The code always assumed that the size of the image with the Y plane dimensions, which, while often the case, isn't correct.
We remove the assertions that the display offset was always (0,0) and properly carry the actual data over IPC.
Remoting the theora decoder and enabling fast video copy exposed several other related issues in the various D3D11 image types.
Various WPT uses theora YUV44 images (because we do not support YUV444 H264 ones). Those images are made of 32 pixels planes with a display size set to 20 pixels. Prior P1D the backend image was a ShareYCbCrPlanar image which correctly handled the size settings.
Like the image serializer, the various D3D11 images always assumed that the Y plane size was the image size.
This however expose existing issues where the offset position of the display is completely ignored for some image type. See bug 1669054
All those problems explain why sometimes we displayed more pixels than we should have.
Depends on D91914
Differential Revision: https://phabricator.services.mozilla.com/D92233
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
The only reason BufferTexture needs a LayersIPCChannel instead of the IShmemAllocator base interface is that it needs to know if the allocator is cross-process or not. Both LayersIPCChannel and ISurfaceAllocator use IsSameProcess() for this but without a common interface for it. Rather than further complicate the inheritance diagram for the layers and IPDL core classes, this patch makes BufferTexture handle both with generic code.
Differential Revision: https://phabricator.services.mozilla.com/D56225
The only reason BufferTexture needs a LayersIPCChannel instead of the IShmemAllocator base interface is that it needs to know if the allocator is cross-process or not. Both LayersIPCChannel and ISurfaceAllocator use IsSameProcess() for this but without a common interface for it. Rather than further complicate the inheritance diagram for the layers and IPDL core classes, this patch makes BufferTexture handle both with generic code.
Differential Revision: https://phabricator.services.mozilla.com/D56225
YUVColorSpace is inseparable from the bit depth as the matrix coefficients to be calculated need the bit depth information.
So let's put the two types together. gfx namespace also makes more sense as that's where we find IntRect, IntSize and other.
The extent of the changes highlight how much similar data structures are duplicated across the code, to the point it's scary.
Differential Revision: https://phabricator.services.mozilla.com/D25347
