| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| |
| |
| |
| |
| | |
* commit 'c6bc18bc121ea66df715123c59f7ef9542c0914a':
vf_hwupload/hwmap: Support setting a fixed pool size
Merged-by: Mark Thompson <sw@jkqxz.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These filters do not directly know whether the API they are using will
support dynamic frame pools, so this is somewhat tricky. If the user
sets extra_hw_frames, we assume that they are aware of the problem and
set a fixed size based on that. If not, most cases use dynamic sizing
just like they did previously. The hardware-reverse-mapping case for
hwmap previously had a large fixed size (64) here, primarily as a hack
for QSV use - this is removed and extra_hw_frames will need to be set
for QSV to work since it requires fixed-size pools (as the other cases
do, and which didn't work before).
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This is something of a hack. It allocates a new hwframe context for
the target format, then maps it back to the source link and overwrites
the input link hw_frames_ctx so that the previous filter will receive
the frames we want from ff_get_video_buffer(). It may fail if
the previous filter imposes any additional constraints on the frames
it wants to use as output.
|
| | |
| |
| |
| |
| | |
Also refactor a little and improve error messages to make failure
cases easier to understand.
|
| | |
| |
| |
| |
| | |
To match creation on a newly-derived device. (This was missed earlier
because the mode is only used in some cases.)
|
| | |
| |
| |
| |
| |
| | |
Fixes CID 1412853.
(cherry picked from commit a670eea56087d0ecd4fbeccf3a9beb9110b7031f)
|
| | |
| |
| |
| |
| |
| | |
Fixes CID 1412854.
(cherry picked from commit 5635c80bf59d90e63ede473e2c014647850a8446)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is something of a hack. It allocates a new hwframe context for
the target format, then maps it back to the source link and overwrites
the input link hw_frames_ctx so that the previous filter will receive
the frames we want from ff_get_video_buffer(). It may fail if
the previous filter imposes any additional constraints on the frames
it wants to use as output.
(cherry picked from commit 81a4cb8e58636d4efd200c2b4fec786a7e948d8b)
|
| | |
| |
| |
| |
| |
| |
| | |
Also refactor a little and improve error messages to make failure
cases easier to understand.
(cherry picked from commit 38cb05f1c89cae1862b360d4e7e3f0cd2b5bbb67)
|
| |/
|
|
|
|
|
| |
* commit '124e26971e69bb25f38c6c7cb3fa20c77cf10966':
lavfi: Hardware map filter
Merged-by: Clément Bœsch <cboesch@gopro.com>
|
|
|
Takes a frame associated with a hardware context as input and maps it
to something else (another hardware frame or normal memory) for other
processing. If the frame to map was originally in the target format
(but mapped to something else), the original frame is output.
Also supports mapping backwards, where only the output has a hardware
context. The link immediately before will be supplied with mapped
hardware frames which it can write directly into, and this filter
then unmaps them back to the actual hardware frames.
|
