for sps/pps.
Signed-off-by: Ivan
---
libavcodec/h264.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index f1399b8..88768af 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -1781,7 +1781,7 @@ static int is_extra(const
Signed-off-by: Ivan
---
libavformat/flvenc.c | 130 ++-
1 file changed, 78 insertions(+), 52 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index d62ff70..3536e9a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
---
libavformat/flvenc.c | 116 ---
1 file changed, 64 insertions(+), 52 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index d62ff70..cf8d221 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -343,12 +343,74 @@
---
libavformat/flvenc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index cf8d221..6fd7792 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -566,6 +566,19 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
The purpose of this patch is to preserve timestamps when using ffmpeg for
publishing RTMP streams, e.g. ffmpeg -i rtmp://source/stream -f flv
rtmp://target/stream.
There is a setting "copyts" for that purpose. Unfortunately it doesn't work
with FLV muxer because it has its own timestamp correcti
$ ./ffplay gophers://codemadness.org/9/paste/warmelul.mkv
[0] https://github.com/curl/curl/commit/48b85c46f16f04e803e00b0bad42a4fa0295f517
Best regards,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo
Pinging for review.
Best regards,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Ping for review. Thank you.
Best regards,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Bump for review. Test instructions:
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276913.html
Best regards,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
Bump for review.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
put size. fails
ffmpeg -i red.jpg -vf pad=iw:ih:0:0 pad1.png
# input at bottom right of output. fails
ffmpeg -i red.jpg -vf pad=iw+16:ih+16:ow-iw:oh-ih pad2.png
Ivan
From 52030219e09b5f9611ca6232b1f24197363fc23b Mon Sep 17 00:00:00 2001
From: Ivan Middleton
Date: Sun, 26 Jan 2020 20:25:59 -0700
g:
>
> # create 15x15 test jpeg with 4:2:0 subsampling
> ffmpeg -f lavfi -i color=red:15x15,format=rgb24 -vframes 1 -vf
> format=yuvj420p red.jpg
>
> # output size = input size. fails
> ffmpeg -i red.jpg -vf pad=iw:ih:0:0 pad1.png
>
> # input at bottom right of output.
on on the Mac, except
Chromium >V87 when (i believe) this patch
<https://chromium-review.googlesource.com/c/chromium/src/+/2412732> was
merged.
I am looking for a developer that would be able to help with this issue and
potentially finish up work with the rest of the addon.
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 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_
---
libavcodec/h264_ps.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 7858361..09e2290 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -136,6 +136,7 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecCon
*). 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 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
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 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/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, 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, 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, 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/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/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/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
This is already supported per https://www.webmproject.org/docs/container/#Tags
and
https://github.com/nbirkbeck/matroska-specification/commit/28a54f991f118fff31fe6bfe256c2dfab46d00e5
---
libavformat/matroskaenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfo
This is already supported per https://www.webmproject.org/docs/container/#Tags
and
https://github.com/nbirkbeck/matroska-specification/commit/28a54f991f118fff31fe6bfe256c2dfab46d00e5
Signed-off-by: Ivan Janatra
---
libavformat/matroskaenc.c | 8
1 file changed, 4 insertions(+), 4
SGTM, I'll just wait for your patch then.
On Fri, Sep 8, 2017 at 3:33 PM, James Almer wrote:
> On 9/8/2017 12:59 PM, Ivan Janatra wrote:
> > This is already supported per https://www.webmproject.org/
> docs/container/#Tags and https://github.com/nbirkbeck/
> matroska-
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 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
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
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
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
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, 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
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/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
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/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.
&
if (ret < 0) {
> av_packet_unref(&new_pkt);
I'm agree, existing check is not correct.
LGTM.
--
Best regards,
Ivanmailto:ivan.us...@nablet.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello Mark,
Friday, July 15, 2016, 1:37:54 PM, you wrote:
MT> On 15/07/16 07:15, Chao Liu wrote:
>> Ivan Uskov nablet.com> writes:
>>
>>>
>>> Hello All,
>>>
>>> After commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e qsv-based
>>
pril 25 but was ignored.
If it is acceptable for your purposes I would like to recommend you to look
libav. The qsv-related modules in libav should be more advanced this time.
--
Best regards,
Ivanmailto:ivan.us...@nablet.com
___
Hello Mark,
Saturday, July 23, 2016, 11:42:46 PM, you wrote:
MT> On 23/07/16 20:33, Ivan Uskov wrote:
>> If you are use qsv, I would like to recommend to roll-back to version before
>> d30cf57a7b2097b565db02ecfffbdc9c16423d0e
>> Really the d30cf57a7b2097b565db02ecfffbdc
Hello Michael,
Sunday, July 24, 2016, 12:16:59 AM, you wrote:
MN> On Sat, Jul 23, 2016 at 11:19:59PM +0300, Ivan Uskov wrote:
>> Hello 张玉晓,
>>
>> Friday, July 22, 2016, 4:10:36 AM, you wrote:
>>
>> 张> I have a question when learning ffmpeg qsv decoder and
decoder crash.
So it should be reverted.
Please review.
--
Best regards,
Ivan mailto:ivan.us...@nablet.com
0001-Revert-Merge-commit-3c53627ac17fc6bdea5029be57da1e03.patch
Description: Binary data
___
ffmpeg-devel mailing list
ssor condition to
disable
MFX_EXTBUFF_CODING_OPTION3 by correct way. If you have got some
constructive suggestions to improve disabling MFX_EXTBUFF_CODING_OPTION3 by
condition (possible in real-time code, not by preprocessor) please provide.
But stupid disabling of a feature is not the good solution.
--
Best regards,
Ivanmailto:ivan.us...@nablet.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
)
Have anybody the idea how it can be correctly fixed?
Looks like has_decode_delay_been_guessed() should be corrected.
--
Best regards,
Ivan mailto:ivan.us...@nablet.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello All,
This patch applies same changes as commit
e3dfef8e3c85a64dbe6388117303f5819fa3c6a2
of libav: instead obsolete AVBitStreamFilterContext now new AVBSFContext
filter uses to restore annex-B prefixes.
Please review.
--
Best regards,
Ivan mailto:ivan.us
Hello Michael,
Sunday, July 24, 2016, 11:11:32 PM, you wrote:
MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
>> Hello All,
>>
>> I have discovered the following issue:
>> Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based
&
Hello Michael,
Sunday, July 24, 2016, 11:25:29 PM, you wrote:
MN> On Sun, Jul 24, 2016 at 11:18:38PM +0300, Ivan Uskov wrote:
>> Hello Michael,
>>
>> Sunday, July 24, 2016, 11:11:32 PM, you wrote:
>>
>> MN> On Sun, Jul 24, 2016 at 09:55:21PM +030
Hello Michael,
Sunday, July 24, 2016, 11:25:29 PM, you wrote:
MN> On Sun, Jul 24, 2016 at 11:18:38PM +0300, Ivan Uskov wrote:
>> Hello Michael,
>>
>> Sunday, July 24, 2016, 11:11:32 PM, you wrote:
>>
>> MN> On Sun, Jul 24, 2016 at 09:55:21PM +030
By the way, what is your platform? Linux? Do you use a patched kernel
recommended by Intel for specific sdk version?
--
Best regards,
Ivanmailto:ivan.us...@nablet.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
/* Reset input bitstream fifo */
> -av_fifo_reset(q->input_fifo);
+if (q->>input_fifo)
> +av_fifo_reset(q->input_fifo);
> }
>
> int ff_qsv_decode_close(QSVContext *q)
--
Best regards,
Ivanmailto:ivan.us...@nablet.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_unref(&pkt);
> }
>
> /* Reset input bitstream fifo */
> -av_fifo_reset(q->input_fifo);
+if (q->>input_fifo)
> +av_fifo_reset(q->input_fifo);
> }
>
> int ff_qsv_decode_close(QSVContext *q)
Really, makes sense.
Looks good for me.
Hello Michael,
Sunday, August 7, 2016, 8:18:54 PM, you wrote:
> On Sun, Jul 24, 2016 at 10:05:27PM +0300, Ivan Uskov wrote:
>> Hello All,
>>
>> This patch applies same changes as commit
>> e3dfef8e3c85a64dbe6388117303f5819fa3c6a2
>> of libav: instead obsolete
| !ist->dec || !ist->dec->pix_fmts)
> return 0;
> for (pix_fmt = ist->dec->pix_fmts; *pix_fmt != AV_PIX_FMT_NONE;
> pix_fmt++)
> if (*pix_fmt == AV_PIX_FMT_QSV)
Thank, makes sense.
LGTM.
--
Best regards,
Ivan
eate(&priv->child_device_ctx, child_device_type,
> + e ? e->value : NULL, NULL, 0);
> +if (ret < 0)
> +return ret;
> +
> +{
> +AVHWDeviceContext *child_device_ctx =
> (AVHWDeviceContext*)priv->child_device_ct
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
_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
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
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: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, 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/
sition works perfectly.
breaks:
https://www.dropbox.com/s/z4r4hwexyf99mv8/video_breaks.flv?dl=0
works:
https://www.dropbox.com/s/rge7b6888stsyta/video_works.flv?dl=0
Thank you,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mail
in commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e.
Please review.
--
Best regards,
Ivan mailto:ivan.us...@nablet.com
0001-libavcodec-qsvdec.c-Restoring-decoding-functionality.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@
Hello All,
The attached patch does fixes the issue of frames duplication when
elementary h.264 stream decodes by qsvdec.
Please review.
--
Best regards,
Ivan mailto:ivan.us...@nablet.com
0001-libavcodec-qsvdec_h2645.c-Bug-fixed-wrong-ticks_per_.patch
Hello Derek,
Monday, April 25, 2016, 4:50:28 PM, you wrote:
DB> On 4/25/2016 2:14 PM, Ivan Uskov wrote:
>> The attached patch does fixes the issue of frames duplication when
>> elementary h.264 stream decodes by qsvdec.
DB> Could you perhaps elaborate in the commit m
Hello All,
Monday, April 25, 2016, 6:50:18 PM, you wrote:
HL> On Mon, Apr 25, 2016 at 5:44 PM, Ivan Uskov wrote:
>> Hello Derek,
>>
>> Monday, April 25, 2016, 4:50:28 PM, you wrote:
>>
>> DB> On 4/25/2016 2:14 PM, Ivan Uskov wrote:
>>>> The atta
because it was really the bug which force decoder to
produce doubled frames output.
--
Best regards,
Ivanmailto:ivan.us...@nablet.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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
is changes by two reasons:
1. The dump_video_param() intended to dump parameters returned by
MFXVideoENCODE_GetVideoParam(); You can not use q->extco and q->extco2 here
because are can be differ that values really used by en
Resubmitted as two separate commits
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195162.html
Ivan Grigoriev
On Fri, Jun 10, 2016 at 1:39 PM, Carl Eugen Hoyos wrote:
> Ivan gmail.com> writes:
>
> > +flv_write_codec_header(s, s->streams[i]->codecpar);
>
>
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 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/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/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/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/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 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 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 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
een precision and speed.
At my benchmarks the pvq_search_sse42 is about 2x the speed of
the current C implementation. The v1 was closer to 2.5x .
I'd be glad to see some benchmarks,
preferably with different defines enabled and disabled,
so I can tune the code for different CPU's.
Best
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
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
> [...]
>> +
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
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
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
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/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:
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/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
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/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/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/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/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 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 "
1 - 100 of 255 matches
Mail list logo
