On 08/30/2017 03:01 PM, Pavel Koshevoy wrote:
On Wed, Aug 30, 2017 at 2:00 PM, Marton Balint wrote:
On Mon, 19 Dec 2016, Marton Balint wrote:
On Sat, 17 Dec 2016, pkoshe...@gmail.com wrote:
From: Pavel Koshevoy
Steps to reproduce:
./ffmpeg_g -f s16be -i /dev/null -af atempo=0.5 -y /tmp/at
From: Anton Khirnov
(cherry picked from commit e6bff23f1e11aefb16a2b5d6ee72bf7469c5a66e)
Signed-off-by: James Almer
---
This is (afaics) the last API introduced to libav before the major bump.
Now checking all the x86 flags that would require aligment of 16 bytes
or more.
doc/APIchanges
On 02/09/17 21:11, Jorge Ramirez-Ortiz wrote:
> This patchset enhances Alexis Ballier's original patch and validates
> it using Qualcomm's Venus hardware (driver recently landed upstream
> [1]).
>
> This has been tested on Qualcomm's DragonBoard 410c and 820c
> Configure/make s
On Fri, 1 Sep 2017, Gildas Fargeas wrote:
I removed the option bm_v210 as it is replaced with a more complete pixel
format selection option.
Well, you can't do that, you can only deprecate an option and keep
compatibility for some time. E.g. if bm_v210 is set then force pixel
format to 10
On 9/2/2017 7:26 PM, Clément Bœsch wrote:
> This code is disabled since 2012. V4L1 was dropped from the kernel more
> than 10 years ago.
> ---
> configure| 2 -
> libavdevice/Makefile | 1 -
> libavdevice/alldevices.c | 1 -
> libavdevice/v4l.c| 364
> ---
Intended for use with hardware frames for which rawvideo is not
sufficient.
---
Kindof nasty. Any thoughts on better ways of achieving the same result
(hardware frames out of lavd) very welcome!
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 2 +-
libavcodec/wrapped_avfra
This code is disabled since 2012. V4L1 was dropped from the kernel more
than 10 years ago.
---
configure| 2 -
libavdevice/Makefile | 1 -
libavdevice/alldevices.c | 1 -
libavdevice/v4l.c| 364 ---
4 files changed, 368
---
The idea here is to be able to capture the screen with little CPU interaction
by encoding KMS scanout planes. Given X running on KMS, it can capture both X
and virtual consoles, including transitions between them while recording.
Unfortunately, it's rather inconvenient to use: the KMS API d
---
Supports RGB formats so that we can use them in patch 4.
libavutil/hwcontext_vaapi.c | 215 +++-
1 file changed, 214 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 3970726d30..c69db39238 10064
---
Updated for recent reviews. (I'm still going to wait to apply this with the
first actual user of it.)
configure | 3 +
libavutil/Makefile | 2 +
libavutil/hwcontext.c | 4 +
libavutil/hwcontext.h | 1 +
libavutil/hwcontext_drm.c
On 9/2/2017 6:47 PM, Michael Niedermayer wrote:
> On Fri, Sep 01, 2017 at 03:00:16PM -0300, James Almer wrote:
>> This flag replaces the deprecated, non-prefixed
>> HWACCEL_CODEC_CAP_EXPERIMENTAL
>> one.
>>
>> Signed-off-by: James Almer
>> ---
>> No HWAccel uses HWACCEL_CODEC_CAP_EXPERIMENTAL at
On Fri, Sep 01, 2017 at 03:00:16PM -0300, James Almer wrote:
> This flag replaces the deprecated, non-prefixed HWACCEL_CODEC_CAP_EXPERIMENTAL
> one.
>
> Signed-off-by: James Almer
> ---
> No HWAccel uses HWACCEL_CODEC_CAP_EXPERIMENTAL at all. I wonder if we
> shouldn't instead just not bother rep
ping
On Wed, 30 Aug 2017 at 14:44 Kieran Kunhya wrote:
> Padded SPS/PPS is perfectly legal.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Le 29/08/2017 à 15:16, Tobias Rapp a écrit :
On 27.08.2017 19:13, Marton Balint wrote:
I agree that a lot of stuff in the codebase is consistent with the
updated descriptions. However, as far as I see libavformat/mxfdec.c
seems to follow the existing docs, so I think that needs changing as
w
On Fri, Sep 01, 2017 at 07:56:10PM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: 1168175789 + 1168178473 cannot
> be represented in type 'int'
> Fixes: 3081/clusterfuzz-testcase-minimized-4807564879462400
> Fixes: 2844/clusterfuzz-testcase-minimized-55617158381
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
This has been tested on Qualcomm's DragonBoard 410c and 820c
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 11 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_convolve.c | 360 ++
4 files changed, 373 insertions(+)
create mode 100644 libavfilter/vf_convolve.
Signed-off-by: Paras Chadha
---
This fixes the failed fate tests on msvc12:
http://fate.ffmpeg.org/report.cgi?time=20170901190511&slot=x86_32-msvc12-windows-native
http://fate.ffmpeg.org/report.cgi?time=20170901211336&slot=x86_64-msvc12-windows-native
Tests failed because snprintf was filling the
Signed-off-by: Timo Rothenpieler
---
libavcodec/nvenc.c | 65 -
libavcodec/nvenc.h | 6 +
libavcodec/nvenc_h264.c | 6 +
libavcodec/nvenc_hevc.c | 4 +++
4 files changed, 70 insertions(+), 11 deletions(-)
diff --git a/libavcode
Signed-off-by: Paras Chadha
---
This fixes the failed fate tests on mingw32:
http://fate.ffmpeg.org/report.cgi?time=20170902182311&slot=x86_32-mingw-w64-dll-windows-native
libavcodec/fitsdec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/fitsdec.c b/libavco
On 9/2/2017 3:48 PM, Hendrik Leppkes wrote:
> On Sat, Sep 2, 2017 at 8:29 PM, Clément Bœsch wrote:
>> On Sat, Sep 02, 2017 at 02:07:01PM -0300, James Almer wrote:
>> [...]
>>> +size_t av_cpu_max_align(void)
>>> +{
>>> +int av_unused flags = av_get_cpu_flags();
>>> +
>>> +#if ARCH_ARM || ARCH_A
Hello,
I am currently dealing with an issue regarding interlaced encoding with
nvenc.
NVENC uses field mode encoding, which means there are two slices(or
rather, double the amount than usual, depending on
sliceMode/sliceModeData) per input frame and output packet.
Now I had hoped I could jus
On 9/2/2017 3:29 PM, Clément Bœsch wrote:
> On Sat, Sep 02, 2017 at 02:07:01PM -0300, James Almer wrote:
> [...]
>> +size_t av_cpu_max_align(void)
>> +{
>> +int av_unused flags = av_get_cpu_flags();
>> +
>> +#if ARCH_ARM || ARCH_AARCH64
>> +if (flags & AV_CPU_FLAG_NEON)
>> +return 1
On Sat, Sep 2, 2017 at 8:29 PM, Clément Bœsch wrote:
> On Sat, Sep 02, 2017 at 02:07:01PM -0300, James Almer wrote:
> [...]
>> +size_t av_cpu_max_align(void)
>> +{
>> +int av_unused flags = av_get_cpu_flags();
>> +
>> +#if ARCH_ARM || ARCH_AARCH64
>> +if (flags & AV_CPU_FLAG_NEON)
>> +
On Sat, Sep 02, 2017 at 02:07:01PM -0300, James Almer wrote:
[...]
> +size_t av_cpu_max_align(void)
> +{
> +int av_unused flags = av_get_cpu_flags();
> +
> +#if ARCH_ARM || ARCH_AARCH64
> +if (flags & AV_CPU_FLAG_NEON)
> +return 16;
> +#elif ARCH_PPC
> +if (flags & AV_CPU_FLAG_A
From: Clément Bœsch
This commit is meant to reduce the diff in the following one.
---
libavutil/timer.h | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/libavutil/timer.h b/libavutil/timer.h
index ed3b047870..da0761b607 100644
--- a/libavutil/time
From: Clément Bœsch
Refer to "checkasm: use perf API on Linux ARM*" commit for the
rationale.
The implementation is somehow duplicated with checkasm, but so is the
current usage of AV_READ_TIME(). Until these implementations and
heuristics are made consistent, I don't see a way of sharing that c
From: Clément Bœsch
On ARM platforms, accessing the PMU registers requires special user
access permissions. Since there is no other way to get accurate timers,
the current implementation of timers in FFmpeg is using these registers.
Unfortunately, enabling user access to these registers on Linux
From: Anton Khirnov
(cherry picked from commit e6bff23f1e11aefb16a2b5d6ee72bf7469c5a66e)
Signed-off-by: James Almer
---
This is (afaics) the last API introduced to libav before the major bump.
doc/APIchanges | 3 +++
libavutil/cpu.c | 22 ++
libavutil/cpu.h |
From: Vittorio Giovara
This disables almost everything that was deprecated at least two years ago
Readjust the minimum API version as needed, postponing any
API-incompatible changes until the next bump.
(cherry picked from commit 07a2b155949eb267cdfc7805f42c7b3375f9c7c5)
Signed-off-by: Vittorio
On Sat, Sep 02, 2017 at 04:30:53PM +0200, Carl Eugen Hoyos wrote:
>
>
> > Am 02.09.2017 um 16:17 schrieb Clément Bœsch :
>
> > Patchset applied, thanks
>
> Please write a news entry.
>
Why? default behaviour doesn't change. The new switch is mentioned in the
Changelog.
--
Clément B.
signa
> Am 02.09.2017 um 16:17 schrieb Clément Bœsch :
> Patchset applied, thanks
Please write a news entry.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sat, Sep 02, 2017 at 03:57:22PM +0300, Jan Ekstrom wrote:
> Hi,
>
> On Wed, Aug 30, 2017 at 3:08 PM, Clément Bœsch wrote:
> > ...
> > Thanks to people who review the previous patchset and tested it. If
> > someone wants to test without messing with patches, the changes are
> > available on git
On 01/09/17 18:48, Jorge Ramirez wrote:
> On 09/01/2017 05:44 PM, LongChair . wrote:
>> +static int drm_map_frame(AVHWFramesContext *hwfc,
>> + AVFrame *dst, const AVFrame *src, int flags)
>> +{
>> +const AVDRMFrameDescriptor*desc = (AVDRMFrameDescriptor*)src->data[0];
>
Hi,
On Wed, Aug 30, 2017 at 3:08 PM, Clément Bœsch wrote:
> ...
> Thanks to people who review the previous patchset and tested it. If
> someone wants to test without messing with patches, the changes are
> available on github/ubitux/FFmpeg#autodetect.
>
Just got to testing this patch set, and it
This should already be fixed in master and release/3.3
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
36 matches
Mail list logo
