Is it possible to allow ffmpeg to read tags off from videos? Tags were
manually inputted in Windows 10.
https://emby.media/community/index.php?/topic/110246-allow-scan-media-to-detect-tags-in-videos/#comment-1162342
___
ffmpeg-devel mailing list
ffmpeg-
For ipcm and fpcm streams, big-endian format is the default, but it can be
changed
with additional 'pcmC' sub-atom of audio sample description.
Details can be found in ISO/IEC 23003-5:2020
Fixes ticket #9763
Fixes ticket #9790
---
libavformat/mov.c | 60 +
Ping
ср, 27 апр. 2022 г. в 18:00, Ivan Baykalov <4ru...@gmail.com>:
> mov_mdhd_language_map table doesn't contain ISO 639 codes for some of
> the languages. I added a few which have no contradictory mappings
>
> Fixes ticket #9743
> ---
> libavformat/isom.c | 10 ++
mov_mdhd_language_map table doesn't contain ISO 639 codes for some of
the languages. I added a few which have no contradictory mappings
Fixes ticket #9743
---
libavformat/isom.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/isom.c b/libavformat/isom.c
Some streams contain closed caption data embedded using several wrapping
types. For example stream can contain CC wrapped as ATSC A53 packets +
the same data wrapped as SCTE-20 packets. Prior to the patch CC data was
extracted from both types of packets, so it gave duplicated character
pairs on the
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.
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".
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
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".
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".
$ ./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
When mov_create_timecode_track function is executed,
track->st->avg_frame_rate becomes inverted due to
track->st->avg_frame_rate = av_inv_q(rate);
, where "rate" is frame per second here.
I didn't find any obvious negative effect of this operation, but this may
lead to some misunderstanding.
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.
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
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
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-
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
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
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
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/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
---
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
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
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
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
| !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
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
_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.
/* 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
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
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
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 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
)
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
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
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
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
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
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
___
1 - 100 of 255 matches
Mail list logo
