On 6/10/18, Josh de Kock wrote:
> On 2018/05/14 17:50, Derek Buitenhuis wrote:
>> It was never enforced, and there is no documented way to enforce it,
>> rendering it useless.
>>
>> [...]
>
> I think this is the best thing to do first. We could always re-add a
> more 'proper' CoC later, but for no
On 3/1/18, Michael Niedermayer wrote:
> On Wed, Feb 28, 2018 at 10:14:15PM +0200, Ivan Kalvachev wrote:
>> Replace two bit handling loops and internal conditional branch
>> with simple formula using few logical operations.
>>
>> The old function would generate wrong
ecially because currently coefficients bellow
2048 are written using lookup table and bypass this function.
If you like it, use it.
Best Regards
Ivan Kalvachev.
From 1f7fd38fcb6c64281bc458c09c711fc567b3ef0f Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Wed, 28 Feb 2018 17:48:40 +0200
Subject:
On 10/13/17, Carl Eugen Hoyos wrote:
> 2017-10-09 2:04 GMT+02:00 Ivan Kalvachev :
>> The public functions av_alloc_vdpaucontext() and
>> av_vdpau_alloc_context() are allocating AVVDPAUContext
>> structure that is supposed to be placed in avctx->hwaccel_context.
&
On 10/11/17, Ivan Kalvachev wrote:
> On 10/10/17, wm4 wrote:
>> On Tue, 10 Oct 2017 03:24:56 +0300
>> Ivan Kalvachev wrote:
>>
>>> On 10/9/17, wm4 wrote:
>>> > On Mon, 9 Oct 2017 03:04:53 +0300
>>> > Ivan Kalvachev wrote:
>>
On 10/10/17, wm4 wrote:
> On Tue, 10 Oct 2017 03:24:56 +0300
> Ivan Kalvachev wrote:
>
>> On 10/9/17, wm4 wrote:
>> > On Mon, 9 Oct 2017 03:04:53 +0300
>> > Ivan Kalvachev wrote:
>> >
>> >> The public functions av_alloc_vdpauconte
se of long history of compiler bugs related to it.
>> You could remove this entirely from the slice processing code by simply
>> pre-calculating the values in the init function once for the whole stream,
>> there's only 224 qscale values so it's 224*64*2 multiplications
On 10/9/17, wm4 wrote:
> On Mon, 9 Oct 2017 03:04:53 +0300
> Ivan Kalvachev wrote:
>
>> The public functions av_alloc_vdpaucontext() and
>> av_vdpau_alloc_context() are allocating AVVDPAUContext
>> structure that is supposed to be placed in avctx->hwaccel_cont
On 10/9/17, Michael Niedermayer wrote:
> On Mon, Oct 09, 2017 at 09:02:38AM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Mon, Oct 9, 2017 at 6:46 AM, Ivan Kalvachev
>> wrote:
>>
>> > On 10/9/17, Ronald S. Bultje wrote:
>> > > On S
On 10/9/17, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Oct 8, 2017 at 6:52 PM, Ivan Kalvachev wrote:
> [..]
>
> Indentation is off in the second hunk, can you fix that?
You want it 4 spaces to the right
or to start from the first position?
BTW, I think it would be better t
programmer who wrote this has been aware of the problem,
because av_vdpau_bind_context reallocates the structure.
It might be good idea to check the other usages of this reallocation function.
Best Regards
Ivan Kalvachev
From c9dafbf5402ebf8c68bf8648ecea7a74282113a8 Mon Sep 17 00:00:00 2001
doesn't seem right. (I'm not sure why vdpau needs it...)
I also was thinking of using "-1" number for the define, but ...
I didn't want to risk with it.
Best Regards
Ivan Kalvachev.
From 88a5f15f8ea04a5fb4eb135e1e773f92bb56a6e0 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
On 9/10/17, James Almer wrote:
> On 9/10/2017 2:55 PM, Ivan Kalvachev wrote:
>> On 9/2/17, James Almer wrote:
>> [...]
>>> Notes:
>>> I have no way to test what effect the removal of XVMC truly has.
>>> The decoders are removed but unlike libav we have
On 9/2/17, James Almer wrote:
[...]
> Notes:
> I have no way to test what effect the removal of XVMC truly has.
> The decoders are removed but unlike libav we have hwaccels that are not
> removed by this. Similarly, the pixfmt is also not removed in our case.
> Commit dcc39ee10e82833ce24aa57926c00
On 8/26/17, Martin Vignali wrote:
> Hello,
>
> in attach new patch for SSE simd of reorder pixels in exr decoder (use by
> zip and rle uncompress),
> after comments on the previous patch by Ivan Kalvachev.
>
> After testing only on a small buffer, i fix the overread prob
On 8/24/17, Carl Eugen Hoyos wrote:
> 2017-08-23 0:56 GMT+02:00 Ivan Kalvachev :
>> On 8/22/17, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Mon, Aug 21, 2017 at 11:16 AM, Carl Eugen Hoyos
>>> wrote:
>>>
>>>> Hi!
>>>
On 8/25/17, Rostislav Pehlivanov wrote:
> On 25 August 2017 at 16:38, Ivan Kalvachev wrote:
>
>> Instead of returning all zeroes as result and Syy=1.0,
>> place all the K pulses in the first element y[0]
>> and return Syy=K*K.
>>
>> This is how the ori
On 8/25/17, Rostislav Pehlivanov wrote:
> On 25 August 2017 at 16:38, Ivan Kalvachev wrote:
>
>> Instead of returning all zeroes as result and Syy=1.0,
>> place all the K pulses in the first element y[0]
>> and return Syy=K*K.
>>
>> This is how the ori
r(i=1;iFrom 33d29a33dcf5ad8c4850edf9ed8d83292f10b03f Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Fri, 25 Aug 2017 17:14:28 +0300
Subject: [PATCH] opus_pvq_search.asm: Handle zero vector input differently.
Instead of returning all zeroes as result and Syy=1.0,
place all the K pulses in the first element y[0]
and r
On 8/22/17, Rodrigo Severo wrote:
> Hi,
>
>
> My company does some video recording and internal streaming.
>
> Our current solution (on Ubuntu 16.10 servers) uses ffmpeg and
> ffserver (versions 3.0.7). It works great.
>
> Unfortunately, on Ubuntu 17.04, it stopped working. I believe the
> problem
On 8/25/17, James Almer wrote:
> On 8/24/2017 8:26 PM, Ivan Kalvachev wrote:
>> On 8/24/17, James Almer wrote:
>>> On 8/24/2017 12:01 PM, wm4 wrote:
>>>> On Thu, 24 Aug 2017 11:20:17 +0200
>>>> Michael Niedermayer wrote:
>>>>
>>>&g
On 8/24/17, James Almer wrote:
> On 8/24/2017 12:01 PM, wm4 wrote:
>> On Thu, 24 Aug 2017 11:20:17 +0200
>> Michael Niedermayer wrote:
>>
>>> On Thu, Aug 24, 2017 at 10:52:55AM +0200, wm4 wrote:
On Wed, 23 Aug 2017 19:23:12 -0300
James Almer wrote:
> On 8/21/2017 2:51 PM, wm4
On 8/22/17, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Aug 21, 2017 at 11:16 AM, Carl Eugen Hoyos
> wrote:
>
>> Hi!
>>
>> Attached patch tries to slightly simplify and clean up the usage of
>> put_bits* in libavcodec: put_bits_le() functions exist for the
>> little-endian G.726 encoder, so the def
The issue has been resolved.
The patch has been pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ch to make the code as
I think it should have been done from the start and
I do ask you to push it without further bikeshedding.
That would be enough of an apology.
From 18324e5535dd0c928a3ec2e8f25babc583b031d5 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Sat, 19 Aug 2017 14:29:40 +0300
Subject
On 8/10/17, maxime taisant wrote:
>> From: Ivan Kalvachev
>> On 8/8/17, maxime taisant wrote:
>> > From: Maxime Taisant
>> >
>> > Hi,
>> >
>> > Here is some SSE optimisations for the dwt function used to decode
>> > JPEG2000.
On 8/8/17, maxime taisant wrote:
> From: Maxime Taisant
>
> Hi,
>
> Here is some SSE optimisations for the dwt function used to decode JPEG2000.
> I tested this code by using the time command while reading a JPEG2000
> encoded video with ffmpeg and, on average, I observed a 4.05% general
> improv
1bbaa155090851e8b2b52d2302a0c17d6ab Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Thu, 8 Jun 2017 22:24:33 +0300
Subject: [PATCH 2/6] SIMD opus pvq_search implementation
Explanation on the workings and methods used by the
Pyramid Vector Quantization Search function
could be found in the foll
On 8/6/17, Henrik Gramner wrote:
> On Sat, Aug 5, 2017 at 9:10 PM, Ivan Kalvachev wrote:
>> +%macro VBROADCASTSS 2 ; dst xmm/ymm, src m32/xmm
>> +%if cpuflag(avx2)
>> +vbroadcastss %1, %2; ymm, xmm
>> +%elif cpuflag(avx)
>> +%ifnum
On 8/5/17, Martin Vignali wrote:
> Hello,
>
> Based on pull request in the official openexr library :
> https://github.com/openexr/openexr/pull/229/commits/4198128397c033d4f69e5cc0833195da500c31cf
>
> i try to port the reorder part (used in zip and rle decompression), to asm
> Tested on OS X
> pas
Improved version of VBROADCASTSS that works like the avx2 instruction.
Emulation of vpbroadcastd.
Horizontal sum HSUMPS that places the result in all elements.
Emulation of blendvps and pblendvb.
From cf4dc8fcd974a845b91aaa8685c06fa145b01786 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Sat
On 8/5/17, Hendrik Leppkes wrote:
> On Sat, Aug 5, 2017 at 12:21 PM, Ivan Kalvachev
> wrote:
>> On 8/5/17, Rostislav Pehlivanov wrote:
>>> On 4 August 2017 at 23:58, Ivan Kalvachev wrote:
>>>
>>>>
>>>> >> I had it mixed bef
On 8/5/17, Rostislav Pehlivanov wrote:
> On 4 August 2017 at 23:58, Ivan Kalvachev wrote:
>
>>
>> >> I had it mixed before, but I changed it to be consistent.
>> >> Some new avx instruction are not overloaded or
>> >> available without their &quo
On 8/4/17, Henrik Gramner wrote:
> On Thu, Aug 3, 2017 at 11:36 PM, Ivan Kalvachev
> wrote:
>>> 1234_1234_1234_123
>>> VBROADCASTSS ym1, xm1
>>> BLENDVPS m1, m2, m3
>>>
>>> is the most commonly used alignment.
>>
&
On 8/2/17, Henrik Gramner wrote:
> On Tue, Aug 1, 2017 at 11:46 PM, Ivan Kalvachev
> wrote:
>> On 7/31/17, Henrik Gramner wrote:
>>> Use rN instead of rNq for numbered registers (q suffix is used for
>>> named args only due to preprocessor limitations).
>>
On 8/1/17, Clément Bœsch wrote:
> On Tue, Aug 01, 2017 at 09:18:33AM +, Davinder Singh wrote:
> [...]
>> > In particular, the main policy of FFmpeg is to not depend on external
>> > libraries for core features. Therefore, if your project is a separate
>> >
>>
>> Just to be clear, it won't be "
On 7/31/17, Henrik Gramner wrote:
> On Wed, Jul 26, 2017 at 4:56 PM, Ivan Kalvachev
> wrote:
>> +++ b/libavcodec/x86/opus_pvq_search.asm
>
> Generic minor stuff:
>
> Use rN instead of rNq for numbered registers (q suffix is used for
> named args only due to preprocess
On 7/29/17, Dominik 'Rathann' Mierzejewski wrote:
> On Saturday, 29 July 2017 at 00:20, Hendrik Leppkes wrote:
>> On Fri, Jul 28, 2017 at 12:07 PM, James Le Cuirot
>> wrote:
> [...]
>> > This Makefile snippet allows libffmpeg to be created without the help
>> > of Chromium's build system. It uses
On 7/27/17, Rostislav Pehlivanov wrote:
> On 27 July 2017 at 09:38, Ivan Kalvachev wrote:
>
>> On 7/27/17, Rostislav Pehlivanov wrote:
>> > On 26 July 2017 at 15:56, Ivan Kalvachev wrote:
>> >
>> >> +if (ARCH_X86 && CONFIG_O
On 7/27/17, Rostislav Pehlivanov wrote:
> On 26 July 2017 at 15:56, Ivan Kalvachev wrote:
>
>> +if (ARCH_X86 && CONFIG_OPUS_ENCODER)
>> +ff_opus_dsp_init_x86(s);
>>
>
> Just change it to
> +if (ARCH_X86)
>
> The init function is
On 7/24/17, Ivan Kalvachev wrote:
> On 7/23/17, Rostislav Pehlivanov wrote:
>> On 22 July 2017 at 12:18, Ivan Kalvachev wrote:
>>
>>> This patch is ready for review and inclusion.
>>>
>>>
>>>
>>>+%macro emu_blendvps 3 ; dst/sr
On 7/23/17, Rostislav Pehlivanov wrote:
> On 22 July 2017 at 12:18, Ivan Kalvachev wrote:
>
>> This patch is ready for review and inclusion.
>>
>>
>>
>>+%macro emu_blendvps 3 ; dst/src_a, src_b, mask
>>+%macro lea_pic_base 2; reg, const_label
> Capit
6878 6934 6879 6921 6899// C
-b:a 48kbps, 96kbps, 510kbps
sse4: 2049, 1826, 955
sse2: 2065, 1874, 943
avx: 2106, 1868, 950
c: 9202, 7080,1392
From 522ed9d47db739c9c0559f4c040ef5262c685335 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Thu, 8 Jun 2017 22:2
On 7/11/17, Michael Niedermayer wrote:
> On Sun, Jul 02, 2017 at 01:33:16PM +0200, Michael Niedermayer wrote:
>> On Sun, Jul 02, 2017 at 01:14:31PM +0200, wm4 wrote:
>> > On Sun, 2 Jul 2017 04:28:54 +0200
>> > Michael Niedermayer wrote:
>> >
>> > > Fixes: runtime error: signed integer overflow:
On 7/9/17, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jul 9, 2017 at 4:39 AM, Reimar Döffinger
> wrote:
>
>> On 09.07.2017, at 02:52, "Ronald S. Bultje" wrote:
>> > On Sat, Jul 8, 2017 at 5:17 PM, Michael Niedermayer
>>
>> > wrote:
>> >
>> >>
>> >> Does anyone object to this patch ?
>> >> Or doe
On 7/9/17, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Jul 8, 2017 at 5:17 PM, Michael Niedermayer
> wrote:
>
>> On Mon, Jul 03, 2017 at 01:37:09AM +0200, Michael Niedermayer wrote:
>> > On Sun, Jul 02, 2017 at 02:24:53PM +0100, Rostislav Pehlivanov wrote:
>> > > On 2 July 2017 at 03:28, Michael Ni
should never be negative, so the
sign is not needed.
All 32bit operands should also clear the high bits.
Still I'm not sure if there is guarantee that
the high bits won't contain garbage.
Best Regards
From 4591ad752d1d111615f320b17ad19d5fad0d91d4 Mon Sep 17 00:00:00 2001
From: Ivan
ter, sometimes worse.
If you find a file with dramatic difference, I'm interested. :D
If there are no more issues, v4 would be cleaned up and ready for review.
Best Regards.
From 17cbb22f1f3a9021332f95e38003b8ac4d714aec Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Thu, 8 Jun 2017
On 6/26/17, Henrik Gramner wrote:
> On Sat, Jun 24, 2017 at 10:39 PM, Ivan Kalvachev
> wrote:
>> +%define HADDPS_IS_FAST 0
>> +%define PHADDD_IS_FAST 0
> [...]
>> +haddps %1, %1
>> +haddps %1, %1
> [...]
>> +
On 6/27/17, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavfilter/x86/vf_blend.asm| 25 +
> libavfilter/x86/vf_blend_init.c | 4
> tests/checkasm/vf_blend.c | 1 +
> 3 files changed, 30 insertions(+)
>
> diff --git a/libavfilter/x86/vf_blend
dsp_init.c
new file mode 100644
index 00..ddccf6fe9e
--- /dev/null
+++ b/libavcodec/x86/opus_dsp_init.c
@@ -0,0 +1,47 @@
+/*
+ * Opus encoder assembly optimizations
+ * Copyright (C) 2017 Ivan Kalvachev
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redist
On 6/11/17, Hendrik Leppkes wrote:
> On Sun, Jun 11, 2017 at 11:34 AM, Ivan Kalvachev
> wrote:
>> On 6/10/17, James Darnley wrote:
>>> On 2017-06-09 13:41, Ivan Kalvachev wrote:
>>>> On 6/9/17, Michael Niedermayer wrote:
>>>>> seems this bre
On 6/10/17, James Darnley wrote:
> On 2017-06-09 13:41, Ivan Kalvachev wrote:
>> On 6/9/17, Michael Niedermayer wrote:
>>> seems this breaks build with mingw64, didnt investigate but it
>>> fails with these errors:
>>>
>>> libavcodec/libav
On 6/10/17, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Jun 8, 2017 at 8:57 PM, Michael Niedermayer
> wrote:
>
>> On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S. Bultje wrote:
>> > Hi,
>> >
>> > On Thu, Jun 8, 2017 at 6:10 PM, Michael Niedermayer
>>
>> > wrote:
>> >
>> > > Signed value in
>> >
On 6/9/17, wm4 wrote:
> On Fri, 9 Jun 2017 00:10:49 +0200
> Michael Niedermayer wrote:
>
>> On Sat, May 27, 2017 at 12:24:16PM +0200, wm4 wrote:
>> > On Sat, 27 May 2017 03:56:42 +0200
>> > Michael Niedermayer wrote:
>> >
>> > > On Fri, May 26, 2017 at 07:06:44PM -0400, Ronald S. Bultje wrote:
>
On 6/9/17, Ilia Valiakhmetov wrote:
> Signed-off-by: Ilia Valiakhmetov
> ---
> libavcodec/x86/vp9dsp_init_16bpp.c| 2 ++
> libavcodec/x86/vp9intrapred_16bpp.asm | 56
> +++
> 2 files changed, 58 insertions(+)
>
> diff --git a/libavcodec/x86/vp9dsp_init_16bpp.
On 6/9/17, Hendrik Leppkes wrote:
> On Fri, Jun 9, 2017 at 2:51 PM, James Darnley wrote:
>> I propose that we drop support for all assemblers older than NASM version
>> 2.11.
>> That was released on 2013-12-31 with several point releases over the
>> following
>> year with 2.11.08 being released o
On 6/9/17, Ivan Kalvachev wrote:
> On 6/9/17, Michael Niedermayer wrote:
>> On Fri, Jun 09, 2017 at 01:36:07AM +0300, Ivan Kalvachev wrote:
>>> opus_pvq.c |9
>>> opus_pvq.h |5
>>> x86/Makefile|1
>>>
On 6/9/17, Michael Niedermayer wrote:
> On Fri, Jun 09, 2017 at 01:36:07AM +0300, Ivan Kalvachev wrote:
>> opus_pvq.c |9
>> opus_pvq.h |5
>> x86/Makefile|1
>> x86/opus_dsp_init.c | 47 +++
>>
On 6/8/17, Ilia Valiakhmetov wrote:
> vp9_diag_downright_16x16_12bpp_c: 149.0
> vp9_diag_downright_16x16_12bpp_sse2: 67.8
> vp9_diag_downright_16x16_12bpp_ssse3: 45.6
> vp9_diag_downright_16x16_12bpp_avx: 36.6
> vp9_diag_downright_16x16_12bpp_avx2: 25.5
>
> ~30% faster than avx
>
> Signed-off-by:
On 6/9/17, Michael Niedermayer wrote:
> On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Thu, Jun 8, 2017 at 6:10 PM, Michael Niedermayer
>>
>> wrote:
>>
>> > Signed value in
>> > Unsigned
>> > INTeger type
>>
>> [..]
>> > Both SUINT and unsigned should produce id
*). It is mostly useful if
you want to try YMM on AVX1 (AVX1 lacks 256 integer ops).
For some reason enabling this makes the whole function 4 times slower
on my CPU. ^_^
I've left some commented out code. I'll remove it for sure in the final version.
I just hope I haven't done
On 3/31/17, Paolo Prete wrote:
> ---
> configure | 2 +
> doc/Makefile| 41 ++--
> doc/examples/.gitignore | 1 +
> doc/examples/Makefile | 1 +
> doc/examples/encode_raw_audio_file_
On 4/15/17, wm4 wrote:
> On Sat, 15 Apr 2017 00:28:19 +0200
> Carl Eugen Hoyos wrote:
>
>> 2017-04-14 23:27 GMT+02:00 Clément Bœsch :
>> > On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote:
>> > [...]
>> >> We know that the avconv developers are violating the
>> >> copyright of man
On 2/25/17, wm4 wrote:
> I'm documenting existing practice.
>
> I'm pulling the "6 months" timeout out of my ass, but I think it's
> pretty suitable.
> ---
> doc/developer.texi | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/doc/developer.texi b/doc/developer.te
On 7/2/16, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
> vigneshv-at-google@ffmpeg.org> wrote:
>
>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje
>> wrote:
>> > Hi,
>> >
>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje
>> wrote:
>>
On 7/2/16, Vignesh Venkatasubramanian wrote:
> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje
> wrote:
>> Hi,
>>
>> On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje
>> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
>>> vigneshv-at-google@ffmpeg.org>
On 6/17/16, Eric Beuque wrote:
> 2016-06-17 19:16 GMT+02:00 Michael Niedermayer :
>
>> On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote:
>> > Hi,
>> >
>> > i'm posting here for a feature that is missing in ffmpeg (or may be i
>> > missed something), which consist of decoding H.264 frame
On 6/16/16, Michael Niedermayer wrote:
> On Wed, Jun 15, 2016 at 10:50:51AM -0300, James Almer wrote:
>> On 6/15/2016 10:14 AM, Michael Niedermayer wrote:
>> > Hi all
>> >
>> > As noone is doing anything about the situation and what is being
>> > done will not lead anywhere (the vote likely wont l
On 6/16/16, James Almer wrote:
> On 6/15/2016 8:16 PM, Ivan Kalvachev wrote:
>>Loads of crap
>
> No one, and i mean no one reply to this email.
>
> You will not get a single answer to any question you make. All you'll get is
> counter questions. He will make quest
On 6/15/16, Michael Niedermayer wrote:
> Hi all
>
> As noone is doing anything about the situation and what is being
> done will not lead anywhere (the vote likely wont lead anywhere as
> likely few would ban a active developer 4 month and then if not
> some will feel injustice prevailed thus
>
>
On 6/13/16, Paul B Mahol wrote:
> On 6/13/16, Ivan Kalvachev wrote:
>> On 6/12/16, Paul B Mahol wrote:
>>> Hi,
>>>
>>> As requested in the IRC meeting I hereby request for the
>>> voting committee to begin voting on whatever to ban Carl
>>
On 6/12/16, Paul B Mahol wrote:
> Hi,
>
> As requested in the IRC meeting I hereby request for the
> voting committee to begin voting on whatever to ban Carl
> Eugen Hoyos from mailing list, trac and IRC for 4 months,
> starting after the voting has finished.
I don't remember such thing to have b
On 5/20/16, Christophe Gisquet wrote:
> Hi,
>
> 2016-05-20 1:55 GMT+02:00 Lukasz Marek :
>> Is Derek revoked to commit or what? Couldn't he just commit this patch and
>> leave? :P I was a problem for some people, but I see they still have
>> problems. Let people with problems go away with they pr
On 2/15/16, Hendrik Leppkes wrote:
> On Mon, Feb 15, 2016 at 3:13 PM, Ivan Kalvachev
> wrote:
>> On 2/15/16, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Mon, Feb 15, 2016 at 8:26 AM, Ivan Kalvachev
>>> wrote:
>>>
>>>> On 2/
On 2/15/16, Hendrik Leppkes wrote:
> On Mon, Feb 15, 2016 at 2:23 PM, Ivan Kalvachev
> wrote:
>> Keep the new XVMC pixfmt at the old position.
>> It was moved away to preserve ABI compatibility with the fork.
>>
>> I'm not really sure this one is better,
>&g
On 2/15/16, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Feb 15, 2016 at 8:26 AM, Ivan Kalvachev
> wrote:
>
>> On 2/15/16, Hendrik Leppkes wrote:
>> > On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev
>> > wrote:
>> >> Do not remove HWACCEL flag w
On 2/15/16, Hendrik Leppkes wrote:
> On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev
> wrote:
>> Do not remove HWACCEL flag with FF_API_XVMC since the
>> flag is supposed to be used as generic one.
>>
>
> The flag is unused except by the XVMC decoder, so removing
On 2/15/16, Hendrik Leppkes wrote:
> On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev
> wrote:
>> Do not remove HWACCEL flag with FF_API_XVMC since the
>> flag is supposed to be used as generic one.
>>
>
> The flag is unused except by the XVMC decoder, so removing
_YUV440P12LE, ///< planar YUV 4:4:0,24bpp, (1 Cr & Cb
sample per 1x2 Y samples), little-endian
--
2.6.4
From 0ef3403ea39045787d7f610130f1b62249f050d1 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Mon, 15 Feb 2016 13:38:15 +0200
Subject: [PATCH 2/2] Keep the new XVMC pixfmt at the old pos
decoder requires flushing with NULL input at the end in order to
* give the complete and correct output.
--
From 5d0973a6d1ec8b53d1335bed393bf3e67dc8223a Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Mon, 15 Feb 2016 13:16:52 +0200
Subject: [PATCH 1/2] Do not remove HWACCEL flag with
On 10/10/15, Ganesh Ajjanagadde wrote:
> This fixes a warning observed on Clang 3.7:
> "warning: attribute 'deprecated' is ignored, place it after "struct" to
> apply attribute to type declaration [-Wignored-attributes]"
> and thus enables deprecation warning for the relevant struct.
>
> Signed-of
On 8/29/15, wm4 wrote:
> On Sat, 29 Aug 2015 04:28:41 +0200
> Michael Niedermayer wrote:
>
>> Hi all
>>
>> Its about 2 and a half month since 2.7
>> if there are no objections then ill branch of release/2.8 from
>> some revission prior to the next API bump and will then make a 2.8
>> release from
On 8/30/15, wm4 wrote:
> On Sun, 30 Aug 2015 18:09:05 + (UTC)
> Carl Eugen Hoyos wrote:
>
>> wm4 googlemail.com> writes:
>>
>> > Change the default to blend with black, which
>> > gives generally expected results.
>>
>> Given that this introduces a speed regression, is
>> rarely needed and i
On 3/28/15, Peter Ross wrote:
> On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote:
>> On Sun, 29 Mar 2015 08:10:29 +1100
>> Peter Ross wrote:
>>
>> > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote:
>> > > On 28.03.2015 20:13, Nicolas George wrote:
>> > > >L'octidi 8 germinal, an C
On 3/22/15, wm4 wrote:
> On Sun, 22 Mar 2015 15:12:04 +0100
> Michael Niedermayer wrote:
>
>> Hi anton, everyone else
>
> I appreciate that you contacted the author of these patches as well.
>
>> the "cosmetic" commits from yesterday
>> (665e0c10a63d31dd6c7b1fba14db074625d54614..fa7c08d5e192aea77
On 12/13/14, Carl Eugen Hoyos wrote:
> Clément Bœsch pkh.me> writes:
>
>> > > > Attached patch fixes ticket #4183.
>
>> >--libdir=DIR install libs in DIR [PREFIX/lib]
>> > - --shlibdir=DIR install shared libs in DIR [PREFIX/lib]
>> > + --shlibdir=DIR install
On 12/12/14, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #4183.
>
> Please review, Carl Eugen
You should also update the configure help text, as the default is not
PREFIX/lib anymore.
Best Regards
___
ffmpeg-devel mailing list
ffmpeg-
der the condition that Michael is
helping with FFmpeg AND Libav patching (only for jessie).
6. Something else...
Other people have said that FFmpeg should provide help and resources
to the security team. Please elaborate what more can FFmpeg do to
please you.
Best Regards
Ivan Kalvachev
iive
On 8/18/14, Kieran Kunhya wrote:
> On 18 August 2014 02:26, Ivan Kalvachev wrote:
>
>> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to
>> do that too.
>
> Scale doesn't have much (any?) knowledge of interlaced chroma.
> That said I could
On 8/18/14, Carl Eugen Hoyos wrote:
> Ivan Kalvachev gmail.com> writes:
>
>> softpulldown - turns soft into hard telecine.
>
> Do you remember how this filter was used with MEncoder?
> I have a suspicion that it cannot work with FFmpeg.
I have written about it before:
O
On 8/18/14, compn wrote:
> libav brought up the point again that it doesnt like libmpcodecs.
>
> is there anyone using the remaining libmpcodecs filters ?
> most of the filters have been ported to libavfilter already.
They doesn't like Michael too.
They doesn't like that we merge their code.
They
_only_ FFmpeg could be included back
in Debian. Optionally.
The inclusion would allow for a real-life estimate to be done of the
FFmpeg performance, security, bug and feature wise.
Only after assessing real-life data, a final decision could be
reached, if there is still demand for such thing.
Best Regards
Ivan Kalvachev
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 8/13/14, Reimar Döffinger wrote:
> On 12.08.2014, at 02:21, Ivan Kalvachev wrote:
>> It would be decided by the gcc -I inclusion option.
>> It modifies the search paths for header files, so that it checks these
>> paths before the system/default ones (When using `#i
On 8/12/14, Andreas Cadhalpun wrote:
> Hi,
>
> On 12.08.2014 02:21, Ivan Kalvachev wrote:
>> On 8/11/14, Andreas Cadhalpun wrote:
>>> Assuming it would be possible to install development packages for both
>>> at the same time, which one should be used, when buil
On 8/11/14, Andreas Cadhalpun wrote:
> Hi Ivan,
>
> On 11.08.2014 01:23, Ivan Kalvachev wrote:
>> The patch is inspired by something I read in the Debian discussion.
>> Libav and FFmpeg could be installed side by side without conflicts in
>> the libraries, thanks t
ght be good idea next major release (e.g. 3.0)
to have the $prefix/include/ffmpeg as default include path (for
non-comapt build).
Best Regards
Ivan Kalvachev
iive
From 5760ef5c29c02f5e137d4af3199eb71371b02ce1 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev
Date: Mon, 4 Aug 2014 21:40:48 +0300
97 matches
Mail list logo
