> I hope it copes well with multiple definitions of the same option, like the
> last
> overwriting the previous ones.
The latest stable version of the Turing codec deals correctly with multiple
definitions of the same option.
Matteo Naccari
___
ffm
mpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Moritz Barsnick
> Sent: 19 November 2016 13:29
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] Added the interface for the Turing
> codec
>
> On Fri, Nov 18, 2016 at 20:15:
> This lib has a really weird API... Anyway, access to p++ seems unbounded and
> could go past the argv array. The string overflow checks also look
> questionable. snprintf() returns the size the string would have had and isn't
> limited by the buffer passed to it, so the s pointer can go out of bo
s suggested
Matteo Naccari
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: 18 November 2016 18:51
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PA
2016-11-18 17:45 GMT+01:00 Josh de Kock :
> Can't currently test on macOS as libturing doesn't have macOS
> support (https://github.com/bbc/turingcodec/issues/5), but it is
> being worked on (supposedly), so it may make sense to wait until
> then before this is applied.
I don't know if we should
On 2016-11-19 14:29 +0100, Moritz Barsnick wrote:
> On Fri, Nov 18, 2016 at 20:15:30 +0100, wm4 wrote:
> > This lib has a really weird API...
>
> I can't judge the algorithms or the development direction and stuff -
> I'm sure it's all state of the art. But the API sure gives me
> goosebumps, and
On Fri, Nov 18, 2016 at 20:15:30 +0100, wm4 wrote:
> This lib has a really weird API...
I can't judge the algorithms or the development direction and stuff -
I'm sure it's all state of the art. But the API sure gives me
goosebumps, and I don't mean the sexy feelgood type.
Sure, it has all the fle
On Fri, 18 Nov 2016 15:25:49 +
Matteo Naccari wrote:
> - The Turing codec is an open source HEVC encoder licensed under GPLv2
> - More information at http://turingcodec.org/
> ---
> LICENSE.md | 1 +
> configure | 5 ++
> libavcodec/Makefile| 1 +
> libavco
On Fri, Nov 18, 2016 at 4:25 PM, Matteo Naccari
wrote:
> - The Turing codec is an open source HEVC encoder licensed under GPLv2
> - More information at http://turingcodec.org/
> ---
> LICENSE.md | 1 +
> configure | 5 ++
> libavcodec/Makefile| 1 +
> libavcodec
> Can't currently test on macOS as libturing doesn't have macOS support
> (https://github.com/bbc/turingcodec/issues/5), but it is being worked on
> (supposedly), so it may make sense to wait until then before this is applied.
>
Ok we'll try to get this sorted out and then get back to you. Thanks
On 18/11/2016 15:25, Matteo Naccari wrote:
- The Turing codec is an open source HEVC encoder licensed under GPLv2
- More information at http://turingcodec.org/
---
LICENSE.md | 1 +
configure | 5 ++
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
lib
- The Turing codec is an open source HEVC encoder licensed under GPLv2
- More information at http://turingcodec.org/
---
LICENSE.md | 1 +
configure | 5 ++
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libturing.c | 229 +++
12 matches
Mail list logo
