-
Notifications
You must be signed in to change notification settings - Fork 777
Add VA-API JPEG decoder again #563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
3a81e2b
Change *RgbPacketProcessor::process() to public
xlz e7f35bd
Refactor DoubleBuffer with memory pools
xlz 560b80e
vaapi: Add VA-API JPEG decoder
xlz 52c5a61
vaapi: Add build support
xlz 0726f90
vaapi: Remove a 8MB memcpy
xlz 2bfe7fb
vaapi: Use more zero-copy operations
xlz 17adf23
docs: Add VAAPI dependency instructions
xlz b305053
cmake: Print feature list
xlz File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,96 @@ | ||
| /* | ||
| * This file is part of the OpenKinect Project. http://www.openkinect.org | ||
| * | ||
| * Copyright (c) 2014 individual OpenKinect contributors. See the CONTRIB file | ||
| * for details. | ||
| * | ||
| * This code is licensed to you under the terms of the Apache License, version | ||
| * 2.0, or, at your option, the terms of the GNU General Public License, | ||
| * version 2.0. See the APACHE20 and GPL2 files for the text of the licenses, | ||
| * or the following URLs: | ||
| * http://www.apache.org/licenses/LICENSE-2.0 | ||
| * http://www.gnu.org/licenses/gpl-2.0.txt | ||
| * | ||
| * If you redistribute this file in source form, modified or unmodified, you | ||
| * may: | ||
| * 1) Leave this header intact and distribute it under the same terms, | ||
| * accompanying it with the APACHE20 and GPL20 files, or | ||
| * 2) Delete the Apache 2.0 clause and accompany it with the GPL2 file, or | ||
| * 3) Delete the GPL v2 clause and accompany it with the APACHE20 file | ||
| * In all cases you must keep the copyright notice intact and include a copy | ||
| * of the CONTRIB file. | ||
| * | ||
| * Binary distributions must follow the binary distribution requirements of | ||
| * either License. | ||
| */ | ||
|
|
||
| /** @file allocator.h Allocator definitions. */ | ||
|
|
||
| #ifndef ALLOCATOR_H_ | ||
| #define ALLOCATOR_H_ | ||
|
|
||
| #include <cstddef> | ||
|
|
||
| namespace libfreenect2 | ||
| { | ||
|
|
||
| class Buffer | ||
| { | ||
| public: | ||
| size_t capacity; ///< Capacity of the buffer. | ||
| size_t length; ///< Used length of the buffer. | ||
| unsigned char* data; ///< Start address of the buffer. | ||
| }; | ||
|
|
||
| class Allocator | ||
| { | ||
| public: | ||
| /* If the inner allocator fails to allocate, it MUST not return NULL. | ||
| * Instead it MUST return a Buffer with data being NULL. | ||
| * The stdlib will throw std::bad_alloc if new Buffer fails. | ||
| */ | ||
| virtual Buffer *allocate(size_t size) = 0; | ||
| virtual void free(Buffer *b) = 0; | ||
| virtual ~Allocator() {} | ||
| }; | ||
|
|
||
| class PoolAllocatorImpl; | ||
|
|
||
| class PoolAllocator: public Allocator | ||
| { | ||
| public: | ||
| /* Use new as the inner allocator. */ | ||
| PoolAllocator(); | ||
|
|
||
| /* This inner allocator will be freed by PoolAllocator. */ | ||
| PoolAllocator(Allocator *inner); | ||
|
|
||
| virtual ~PoolAllocator(); | ||
|
|
||
| /* allocate() will block until an allocation is possible. | ||
| * It should be called as late as possible before the memory is required | ||
| * for write access. | ||
| * | ||
| * This allocate() never returns NULL as required by Allocator. | ||
| * | ||
| * All calls to allocate() MUST have the same size. | ||
| * | ||
| * allocate() MUST be called from the same thread. | ||
| */ | ||
| virtual Buffer *allocate(size_t size); | ||
|
|
||
| /* free() will unblock pending allocation. | ||
| * It should be called as early as possible after the memory is no longer | ||
| * required for read access. | ||
| * | ||
| * The inner free() can be called with NULL. | ||
| * | ||
| * free() can be called from different threads than allocate(). | ||
| */ | ||
| virtual void free(Buffer *b); | ||
| private: | ||
| PoolAllocatorImpl *impl_; | ||
| }; | ||
|
|
||
| } /* namespace libfreenect2 */ | ||
| #endif /* ALLOCATOR_H_ */ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do you call releaseBuffer here? shouldn't the stream parser do this? otherwise you assume that every packetprocessor is wrapped with an asyncpacketprocessor, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The stream parser passes the buffer asynchronously so it can not wait after
process()finishes and free the buffer.I have assumed, or found very packet processor is wrapped in the async one, yes, and reduced multiple copies of
releaseBuffer()to just this one.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, so basically every packetprocessor should call releaseBuffer at the end of process?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. In theory releaseBuffer should be called as soon as the access to it is finished, but right now no new allocateBuffer will be called before
processor->ready()becomes true, so putting it in the main loop of async processor is OK.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, maybe add a comment mentioning what we discussed here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do.