This patch allows to use the Videotoolbox API in asynchonous mode.
Note that when using async decoding the user is responsible for
releasing the async frame.
Moreover, an option called videotoolbox_async was added to enable
async decoding with ffmpeg CLI.
---
ffmpeg.h | 1 +
ff
decoded frames.
I spent some times today and got an experimental implementation that allows
to enable the async decoding mode.
I’ll provide a patch here for the async support this weekend.
Regards,
—
Sebastien Zwickert
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> On 11 Jul 2015, at 18:52, Michael Niedermayer wrote:
>
> On Sat, Jul 11, 2015 at 06:26:51PM +0200, Sebastien Zwickert wrote:
>> ---
>> libavcodec/version.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/version.h
> On 05 Jul 2015, at 16:41, Sebastien Zwickert wrote:
>
> As VDA is a wrapper of VideoToolbox framework, the changes base vda
> implementation
> upon the videotoolbox implementation to factorize common part of code.
>
> The changes allow the user to request a custo
---
libavcodec/version.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/version.h b/libavcodec/version.h
index ee21f5d..a9b9e25 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
#define LIBAVCODEC_VERSION_MAJOR 56
#define LIBAVCODEC_
> On 07 Jul 2015, at 23:03, Michael Niedermayer wrote:
>
> On Sun, Jul 05, 2015 at 05:03:44PM +0200, Sebastien Zwickert wrote:
>>
>>> On 05 Jul 2015, at 16:41, Sebastien Zwickert wrote:
>>>
>>> delete mode 100644 ffmpeg_vda.c
>>> cr
> On 05 Jul 2015, at 16:41, Sebastien Zwickert wrote:
>
> delete mode 100644 ffmpeg_vda.c
> create mode 100644 ffmpeg_videotoolbox.c
-M as arguments to the format-patch CLI does not detect these as rename...
> rename libavcodec/{vda_internal.h => vda_vt_internal.h} (50%)
w
> On 05 Jul 2015, at 16:41, Sebastien Zwickert wrote:
>
> As VDA is a wrapper of VideoToolbox framework, the changes base vda
> implementation
> upon the videotoolbox implementation to factorize common part of code.
This new patch does not break previous VDA implementation wh
- OS X VideoToolbox support
version 2.7:
diff --git a/MAINTAINERS b/MAINTAINERS
index fa9e966..7d6beaf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -303,6 +303,7 @@ Hardware acceleration:
vaapi*Gwenole Beauchesne
vda* Sebastien Zw
t implementation the kVTDecodeFrame_EnableAsynchronousDecompression
flag is not set and the user is not able to change the parameters passed to the
videotoolbox
decode function. So the decoding is synchronous and the current place for
flushing the delayed
frames is a good one :)
>> [...]
> On 20 Jun 2015, at 17:35, Clément Bœsch wrote:
>
> On Sat, Jun 20, 2015 at 01:33:00PM +0200, Sebastien Zwickert wrote:
>> Old videtotoolbox patch rebased and updated to target the new HWAccel API.
>> As VDA is a wrapper of VideoToolbox framework, the changes base v
> On 20 Jun 2015, at 17:08, Hendrik Leppkes wrote:
>
> On Sat, Jun 20, 2015 at 1:33 PM, Sebastien Zwickert
> wrote:
>> Old videtotoolbox patch rebased and updated to target the new HWAccel API.
>> As VDA is a wrapper of VideoToolbox framework, the changes base vda
&
100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -303,6 +303,7 @@ Hardware acceleration:
vaapi*Gwenole Beauchesne
vda* Sebastien Zwickert
vdpau*Carl Eugen Hoyos
+ videotoolbox
The pixel buffer base address is never unlocked this causes
a bug with some pixel format types that are produced natively
by the hardware decoder: the first buffer was always used.
Unlock the pixel buffer base address fixes the issue.
---
ffmpeg_vda.c | 2 ++
1 file changed, 2 insertions(+)
diff
14 matches
Mail list logo
