Was looking to create a filter to process video and audio in a filter graph,
can find examples in movie or a source that has both video and audio but not
anything that takes both, any pointers to something to use as a reference?
David
___
ffmpeg
On Tue, Oct 17, 2023 at 7:09 PM wrote:
>
>
> On 17 Oct 2023, at 17:51, Dave Johansen wrote:
>
> > ---
> > doc/muxers.texi | 3 +++
> > libavformat/hlsenc.c | 7 ++-
> > 2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/muxers.texi b/doc/muxers.texi
> > index f6071
On Thu, Oct 26, 2023 at 7:12 PM Dave Johansen
wrote:
> ---
> doc/muxers.texi | 3 +++
> libavformat/hlsenc.c | 41 +
> 2 files changed, 28 insertions(+), 16 deletions(-)
>
I submitted a revised set of patches with additional features with this as
th
>
> LGTM
>
>
> Thanks
> Steven
>
I'm new to ffmpeg development so what's the process for this to be merged?
Do I need to do something or is it taken care of by a different
process/someone else?
Thanks,
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
libavutil/hwcontext_vaapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..c3ecd90077
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v2: Fix warning
libavutil/hwcontext_vaapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fe
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v3: Fix another warning
libavutil/hwcontext_vaapi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
On Fri, Oct 27, 2023 at 7:14 PM Mark Thompson wrote:
>
> On 27/10/2023 11:00, David Rosca wrote:
> > This allows some optimizations in driver, such as not having to read
> > back the data if write-only mapping is requested.
> > ---
> > v3: Fix another warning
> &g
On Fri, Oct 27, 2023 at 1:33 AM Steven Liu wrote:
> David Johansen 于2023年10月27日周五 12:03写道：
> >
> > >
> > > LGTM
> > >
> > >
> > > Thanks
> > > Steven
> > >
> >
> > I'm new to ffmpeg development so what&#x
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v4: overwrite + note about vaMapBuffer libva fallback
libavutil/hwcontext_vaapi.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.
On Fri, Oct 27, 2023 at 4:58 AM wrote:
> On 27 Oct 2023, at 5:59, Dave Johansen wrote:
> > @item second_level_segment_index
> > Makes it possible to use segment indexes as %%d in hls_segment_filename
> expression
> > besides date/time values when strftime is on.
> > diff --git a/libavformat/hl
Currently, I have to put the subtitles on the video stream and when I make
the subtitles their own stream, I get this error:
No streams to mux were specified
Would it be possible to have the subtitles as their own stream or is too
engrained of an assumption that there's an output stream tied to ea
On Sun, Nov 5, 2023 at 1:21 AM Marton Balint wrote:
>
>
> On Fri, 27 Oct 2023, David Johansen wrote:
>
> > On Fri, Oct 27, 2023 at 4:58 AM wrote:
> >
> >> On 27 Oct 2023, at 5:59, Dave Johansen wrote:
> >> > @item second_level_segment_index
> &
On Fri, Oct 27, 2023 at 1:33 AM Steven Liu wrote:
> David Johansen 于2023年10月27日周五 12:03写道：
> >
> > >
> > > LGTM
> > >
> > >
> > > Thanks
> > > Steven
> > >
> >
> > I'm new to ffmpeg development so what&#x
This is to fix a build failure on macOS < 10.13.
This is a build failure in release 6.1. The issue also exists at the
top of the master branch, and the patch applies there.
---
libavcodec/videotoolboxenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/videotoolbox
On Fri, Nov 24, 2023 at 9:01 AM Zhao Zhili wrote:
>
> > On Nov 24, 2023, at 23:40, David Bohman wrote:
> >
> > This is to fix a build failure on macOS < 10.13.
> >
> It looks like kVTCompressionPropertyKey_EncoderID is the root cause of build
> failure.
>
On Fri, Nov 24, 2023 at 8:09 PM Zhao Zhili wrote:
>
>
>
> > On Nov 25, 2023, at 05:32, David Bohman wrote:
> >
> > On Fri, Nov 24, 2023 at 9:01 AM Zhao Zhili wrote:
> >>
> >>> On Nov 24, 2023, at 23:40, David Bohman wrote:
> >&g
Previously, prompeg_write() would only report to caller that bytes we
written when a FEC packet was actually created. Not all RTP packets are
expected to generate a FEC packet however, so this behavior was causing
avio to retry writing the RTP packet, eventually forcing the FEC state
machine to se
Hi,
As I promised late last year, here is a patch to add a WavPack DSD decoder.
Thanks!
-David Bryant
From d80f4fb59e4afec1e2c539391a7b4484f5ae8436 Mon Sep 17 00:00:00 2001
From: David Bryant
Date: Sun, 21 Jul 2019 15:43:25 -0700
Subject: [PATCH] avcodec: add a WavPack DSD decoder
Signed-off
On 7/21/19 11:23 PM, Paul B Mahol wrote:
> On 7/22/19, David Bryant wrote:
>> Hi,
>>
>> As I promised late last year, here is a patch to add a WavPack DSD decoder.
>>
>> Thanks!
>>
>> -David Bryant
>>
>>
> Please correct me if I'm w
On 7/23/19 12:47 AM, Paul B Mahol wrote:
> On 7/23/19, David Bryant wrote:
>> On 7/21/19 11:23 PM, Paul B Mahol wrote:
>>> On 7/22/19, David Bryant wrote:
>>>> Hi,
>>>>
>>>> As I promised late last year, here is a patch to add a WavPack DSD
&
On 7/21/19 5:57 PM, Lynne wrote:
> Jul 22, 2019, 12:03 AM by da...@wavpack.com:
>
>> Hi,
>>
>> As I promised late last year, here is a patch to add a WavPack DSD decoder.
>>
>> Thanks!
>>
>> -David Bryant
>>
>> + unsigned char p
ed the freeing of the
frame contexts, which I put back. Oops!
>
>
> Rest looks fine to me.
Thanks for your feedback.
It turns out that this patch has been categorically rejected because it creates
a new codec ID for the new DSD codec. I don't
have time at this point to refactor it app
On 7/24/19 12:26 AM, Paul B Mahol wrote:
> On 7/23/19, David Bryant wrote:
>> On 7/23/19 12:47 AM, Paul B Mahol wrote:
>>> On 7/23/19, David Bryant wrote:
>>>> On 7/21/19 11:23 PM, Paul B Mahol wrote:
>>>>> On 7/22/19, David Bryant wrote:
>>
On 7/28/19 10:27 AM, Paul B Mahol wrote:
> On Sun, Jul 28, 2019 at 6:02 AM David Bryant wrote:
>
>> On 7/24/19 12:26 AM, Paul B Mahol wrote:
>>> On 7/23/19, David Bryant wrote:
>>>> On 7/23/19 12:47 AM, Paul B Mahol wrote:
>>>>> On 7/23/19, David B
re samples being
processed, indicating it's probably just threading overhead.
The dsd2pcm conversion is pretty optimized and I suspect that's just way too
fast to be worth multi-threading.
As I suggested earlier, it's the DST decompression that is worth
On 7/31/19 11:49 PM, Paul B Mahol wrote:
> Hi,
>
> patches attached.
>
> This time DSD decoding is approx %50 faster on old Celeron N3050 CPUs and 2
> threads.
I see about 42% speedup on Core Duo E8400 (36x to 52x) for a 5-channel file.
On the same file encoded in DST, the improvement almost disa
Hi,
Was made aware of this problem on Kodi:
https://github.com/xbmc/xbmc/issues/14771
I'm going to try to add full WavPack DSD support, but thought in the meantime
it would be a good idea to detect and error out early.
Thanks!
David
>From c86aacdf98c3d34a3f8d63233e01c4a3ab55577e Mo
On 11/20/18 10:58 PM, Peter Ross wrote:
> On Tue, Nov 20, 2018 at 09:23:03PM -0800, David Bryant wrote:
>> Hi,
>>
>> Was made aware of this problem on Kodi:
>>
>> https://github.com/xbmc/xbmc/issues/14771
>>
>> I'm going to try to add full WavPa
an incompatible architecture
will fail with -mtune=native anyway.
Signed-off-by: David Michael
---
Hi,
I am building software in a ChromeOS-style environment where the native
build system creates a cross-compiler with a different vendor string for
each supported architecture, and cross-compiled
valgrind. Also, essentially the same DSD decoder has been extensively fuzzed on
OSS-Fuzz because WavPack is also part of that
project now.
Kind regards,
David
From 5d033a4628bdaa13694c5df88b185e7b099bfea5 Mon Sep 17 00:00:00 2001
From: David Bryant
Date: Mon, 9 Mar 2020 15:23:53 -0700
Subject
Support to generate dash SegmentBase manifests, by adding
"use_segmentbase" option to dash muxer. SegmentBase manifest
is defined in ISO DASH Specification section 5.3.9.2 and has as
prerequisite the option "global_sidx" as players will use this box
to have a reference to all fragments in the media
Support to generate dash SegmentBase manifests, by adding
"use_segmentbase" option to dash muxer. SegmentBase manifest
is defined in ISO DASH Specification section 5.3.9.2 and has as
prerequisite the option "global_sidx" as players will use this box
to have a reference to all fragments in the media
all fragments in the media.
Signed-off-by: David Martin
---
doc/muxers.texi | 5 +
libavformat/dashenc.c | 16
2 files changed, 21 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d304181671..fbaa357f2d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.te
On Sat, Mar 7, 2020 at 10:32 AM David Michael wrote:
> Using a compiler with a different host triplet is considered
> cross-compiling, even when it is for the same architecture as the
> build system. With such a cross-compiler, it is still valid to
> optimize builds with --cpu=hos
On 3/20/20 1:54 AM, Paul B Mahol wrote:
> lgtm
Looks good to me too, sorry about that!
>
> On 3/20/20, Michael Niedermayer wrote:
>> Fixes: out of array access
>> Fixes:
>> 21193/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5125168956702720
>>
>> Found-by: continuous fuzzing
On Mon, Mar 16, 2020 at 9:16 AM David Michael wrote:
> On Sat, Mar 7, 2020 at 10:32 AM David Michael wrote:
> > Using a compiler with a different host triplet is considered
> > cross-compiling, even when it is for the same architecture as the
> > build system. With such a
On 3/23/20 9:49 AM, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-03-20 21:50:18)
>> On Fri, Mar 20, 2020 at 10:18:49AM +0100, Anton Khirnov wrote:
>>> Quoting Michael Niedermayer (2020-03-20 01:03:36)
Fixes: out of array access
Fixes:
21193/clusterfuzz-testcase-minimized
n all threads. I am happy to fix and test this case once the patch goes
in, but is the intent of this patch that the
respective authors will find and fix all the breakages? Or did I just happen to
catch the one case you missed?
Cheers!
-David
___
ff
On 3/28/20 6:23 AM, Anton Khirnov wrote:
> Quoting David Bryant (2020-03-27 23:51:19)
>> On 3/27/20 5:57 AM, Anton Khirnov wrote:
>>> The current design, where
>>> - proper init is called for the first per-thread context
>>> - first thread's private dat
On Sun, Mar 22, 2020 at 11:01 PM David Michael wrote:
> On Mon, Mar 16, 2020 at 9:16 AM David Michael wrote:
> > On Sat, Mar 7, 2020 at 10:32 AM David Michael wrote:
> > > Using a compiler with a different host triplet is considered
> > > cross-compiling, e
On Mon, Mar 30, 2020 at 1:00 PM Derek Buitenhuis
wrote:
> On 07/03/2020 15:32, David Michael wrote:
> > Using a compiler with a different host triplet is considered
> > cross-compiling, even when it is for the same architecture as the
> > build system. With such a cross-
a cross-compiler for an
incompatible architecture will fail with -mtune=native anyway.
Signed-off-by: David Michael
---
Changes since v1:
* Use a warning instead of dropping the condition altogether
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b
t every WavPack block
>> encountered as invalid data (unless the WavPack stream is to be
>> discarded (i.e. the streams discard is >= AVDISCARD_ALL)) and try to
>> resync to the next level 1 element.
>>
>> Luckily, the WavPack version is currently not really important;
On 3/31/20 2:47 AM, Anton Khirnov wrote:
> Quoting David Bryant (2020-03-28 21:22:40)
>> On 3/28/20 6:23 AM, Anton Khirnov wrote:
>>> Quoting David Bryant (2020-03-27 23:51:19)
>>>> On 3/27/20 5:57 AM, Anton Khirnov wrote:
>>>>> The current design, wher
On Thu, Apr 2, 2020 at 5:38 PM Michael Niedermayer
wrote:
> On Wed, Apr 01, 2020 at 12:07:55AM -0400, David Michael wrote:
> > Using a compiler with a different host triplet is considered
> > cross-compiling, even when it is for the same architecture as the
> > build syste
On 4/2/20 2:13 AM, Anton Khirnov wrote:
> Quoting David Bryant (2020-04-01 23:35:13)
>> On 3/31/20 2:47 AM, Anton Khirnov wrote:
>>>>> Looking at wavpack, the code looks suspicious to me. You allocate one
>>>>> dsdctx per channel at init, but AFAIU the numb
On 4/5/20 1:32 PM, Anton Khirnov wrote:
> Fix invalid memory access on DSD streams with changing channel count.
> ---
> libavcodec/wavpack.c | 122 +++
> 1 file changed, 90 insertions(+), 32 deletions(-)
>
> diff --git a/libavcodec/wavpack.c b/libavcodec/wav
On 4/2/20 11:32 PM, Anton Khirnov wrote:
> Quoting David Bryant (2020-04-03 07:14:21)
>> On 4/2/20 2:13 AM, Anton Khirnov wrote:
>>> Quoting David Bryant (2020-04-01 23:35:13)
>>>> On 3/31/20 2:47 AM, Anton Khirnov wrote:
>>>>>>> Looking at wav
On 4/5/20 1:32 PM, Anton Khirnov wrote:
> They are not forbidden by the specification.
> ---
> libavformat/wvdec.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/libavformat/wvdec.c b/libavformat/wvdec.c
> index b9fc6a59f9..4159bf1253 100644
> --- a/libavformat/wvdec.c
: 74b2181f3e9829d9a5b98edd037984ac)
decoded MD5 (f32le): a3a88bba95f809025dce01ecb9064091
Thanks!
-David Bryant
From 8e11e2068f1e763c46903d52da6489cb360b8f8e Mon Sep 17 00:00:00 2001
From: David Bryant
Date: Fri, 17 Apr 2020 15:48:05 -0700
Subject: [PATCH] tests/fate/wavpack: add a lossless DSD file
On 4/18/20 9:49 AM, Carl Eugen Hoyos wrote:
> Am Sa., 18. Apr. 2020 um 17:36 Uhr schrieb David Bryant :
>> As suggested in another thread, I have created a WavPack DSD test file that
>> exercises all three of the DSD modes (fast, high, and copy).
>>
>> If someone would
On 4/18/20 10:32 AM, Carl Eugen Hoyos wrote:
> Am Sa., 18. Apr. 2020 um 19:31 Uhr schrieb David Bryant :
>> On 4/18/20 9:49 AM, Carl Eugen Hoyos wrote:
>>> Am Sa., 18. Apr. 2020 um 17:36 Uhr schrieb David Bryant :
>>>> As suggested in another thread, I have c
load' -c:v h264_vaapi /dev/video4
From ce5f0ebd8e1d40b0f876b0d1b0b0cf564389b874 Mon Sep 17 00:00:00 2001
From: Roger
Date: Sat, 4 Nov 2017 16:32:41 -0400
Subject: [PATCH] avdevice/v4l2enc: Allow writing h264 to v4l2.
Signed-off-by: David Manouchehri
---
libavdevice/v4l2enc.c | 5 ++---
1 file change
Thanks for catching that bug! I tested rawvideo again this time, and
it works as expected with this new patch.
From d125fea410dea1c2d4bd791a7472a72822de54a3 Mon Sep 17 00:00:00 2001
From: David Manouchehri
Date: Sat, 4 Nov 2017 16:32:41 -0400
Subject: [PATCH] avdevice/v4l2enc: Allow writing non
Resubmit of a previous patch, not sure why the diff didn't come through.
From d125fea410dea1c2d4bd791a7472a72822de54a3 Mon Sep 17 00:00:00 2001
From: David Manouchehri
Date: Sat, 4 Nov 2017 16:32:41 -0400
Subject: [PATCH] avdevice/v4l2enc: Allow writing non-rawvideos to v4l2.
Signed-o
On 5/2/20 2:08 PM, Michael Niedermayer wrote:
> Fixes: shift exponent 32 is too large for 32-bit type 'int'
> Fixes:
> 21647/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5686168323883008
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/
Signed-off-by: David Andreoletti
---
doc/filters.texi | 16 +---
libavfilter/vf_drawtext.c | 19 ---
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index d19fd346ae..3a127369ea 100644
--- a/doc/filters.texi
drawtext allows a file to be reloaded per frame. However,
the file to be reloaded is constant across frame. With
textfile now supporting text expansion, a different file can
be reloaded per frame. Eg: textfile=/path/fo/file{frame_num}.txt
Signed-off-by: David Andreoletti
---
doc/filters.texi
://patchwork.ffmpeg.org/project/ffmpeg/patch/20200511143159.19390-1-da...@andreoletti.net/
Regards,
David Andreoletti
On Mon, May 11, 2020 2:31 PM, David Andreoletti da...@andreoletti.net wrote:
drawtext allows a file to be reloaded per frame. However,
the file to be reloaded is constant across
iables are expanded.
For a first improvement to an existing functionality, I would prefer to keep it
simple and focused :-)
[0]https://ffmpeg.org/ffmpeg-filters.html#Text-expansion
On Tue, May 19, 2020 9:34 AM, Manolis Stamatogiannakis msta...@gmail.com wrote:
Hi David,
Not a full review, b
FFmpeg team,
Is there any other discussion/changes needed to get this contribution merged in
?
Regards,
On Tue, May 19, 2020 12:36 PM, David Andreoletti da...@andreoletti.net wrote:
Manolis: drawtext's text expansion section [0] does not mention the special
variable %{frame_num}
> +
> bpp= av_get_bytes_per_sample(sample_fmt);
> orig_bpp = ((s->frame_flags & 0x03) + 1) << 3;
> multiblock = (s->frame_flags & WV_SINGLE_BLOCK) != WV_SINGLE_BLOCK;
Looks reasonable to me and passes my local test suite. Thanks!
On 11/21/18 9:50 PM, David Bryant wrote:
> On 11/20/18 10:58 PM, Peter Ross wrote:
>> On Tue, Nov 20, 2018 at 09:23:03PM -0800, David Bryant wrote:
>>> Hi,
>>>
>>> Was made aware of this problem on Kodi:
>>>
>>> https://github.com/xbmc/xbmc/iss
On 12/24/18 12:21 AM, Paul B Mahol wrote:
> On 12/24/18, David Bryant wrote:
>> On 11/21/18 9:50 PM, David Bryant wrote:
>>> On 11/20/18 10:58 PM, Peter Ross wrote:
>>>> On Tue, Nov 20, 2018 at 09:23:03PM -0800, David Bryant wrote:
>>>>> Hi,
>&
On 12/28/18 3:56 AM, Paul B Mahol wrote:
> On 12/24/18, Derek Buitenhuis wrote:
>> On 24/12/2018 17:47, David Bryant wrote:
>>> I want to do that, but am swamped at work right now, so it will probably
>>> be a few months before I can get to that.
>>>
>>&
ed captions too until I used
the --noscte20 option. After that, I got perfectly clean captions.
When I looked to see if ffmpeg had a comparable switch, I found this
thread. I build ffmpeg myself with this patch and sure enough I got
perfectly clean captions too without having to use ccextractor. I see
this patch hasn't been included in ffmpeg yet. Please reconsider
including it in some form as it is definitely needed out here in the
real world.
Please note that I am not subscribed to the ffmpeg-devel list. Please
copy me on any replies that you need me to see.
David
--
David Engel
da...@istwok.net
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 1/6/19 4:43 AM, Carl Eugen Hoyos wrote:
> 2019-01-03 6:19 GMT+01:00, David Bryant :
>> On 12/28/18 3:56 AM, Paul B Mahol wrote:
>>> On 12/24/18, Derek Buitenhuis wrote:
>>>> On 24/12/2018 17:47, David Bryant wrote:
>>>>> I want to do that, but am s
ffmpeg, would anybody be interested in taking on a contract to make
this work? If so, please contact me directly with an indication of
your availability.
Many thanks,
David Holroyd
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org
.)
Patchset is in the next mails.
till then, David.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
0001-avformat-mov-add-more-datatypes-in-metadata-handling.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
0002-avformat-movenc-add-option-to-use-keys-mdta-atoms-fo.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Wayland environment became quite popular with gnome 3. This patch adds the
ability to
initialize the VAAPI accelerator from a wayland display.
Signed-off-by: David Fort
---
configure | 4
libavutil/hwcontext_vaapi.c | 33 +
2 files
ce Headers bitstream filter
+ * Copyright (c) 2017 David Griffiths
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * v
Hi, I was not aware of that. I'm not that familiar with the
differences between ffmpeg and libav. Do you know if the libav "coded
bitstream editing" framework you mention is documented anywhere?
Cheers,
David
On 1 August 2017 at 19:05, Jan Ekstrom wrote:
> Hi,
>
> On
Hi, that certainly does sound as though it does the same as my patch plus
more. I will download libav and have a play.
Cheers,
David
On Tue, 1 Aug 2017 at 20:59, Mark Thompson wrote:
> On 01/08/17 19:05, Jan Ekstrom wrote:
> > Hi,
> >
> > On Tue, Aug 1, 2017 at 3:2
Andreas Cadhalpun wrote:
Hi all,
some of you may have noticed a weird ffmpeg package in the NEW queue[1].
Let me explain:
... ... ...
and make kittens cry...
... ... ...
Primary reason for Debian kittens crying right now... is ffmpeg being missing...
easy... Ugh... Not so...
Here's the problem... (All examples using latest git pull.)
David-Favor-iMac# git describe
n2.0-10562-g229a1e8
First... let's see if configure knows enough to ferret out avfoundation...
David-Favor-iMac# ./configure --list-indevs
alsa
Additional information related to my first message.
Building with gcc produces no trace of avfoundation support in full help.
Building with clang shows...
AVFoundation input device AVOptions:
-list_devices .D.. list available devices (from 0 to 1)
(default 0)
true
Thilo Borgmann wrote:
Hi,
as reported by David Favor, the AVFoundation device is not yet listed by "ffmpeg
-devices".
This patch fixes that. Please Apply.
-Thilo
Many thanks for the patch... ffmpeg -devices looks to be working now...
David-Favor-iMac> ffmpeg -devices
ffmpeg
---
libavcodec/vaapi_encode_av1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index a46b882ab9..02a31b894d 100644
--- a/libavcodec/vaapi_encode_av1.c
+++ b/libavcodec/vaapi_encode_av1.c
@@ -155,6 +155,8 @@ static av_cold int
On Fri, Nov 24, 2023 at 8:27 AM Xiang, Haihao wrote:
>
> On Vr, 2023-10-27 at 22:25 +0200, David Rosca wrote:
> > This allows some optimizations in driver, such as not having to read
> > back the data if write-only mapping is requested.
> > ---
> > v4: overwrite
---
libavcodec/vaapi_av1.c| 2 +-
libavcodec/vaapi_decode.c | 3 ++-
libavcodec/vaapi_decode.h | 1 +
libavcodec/vaapi_h264.c | 2 +-
libavcodec/vaapi_hevc.c | 4 ++--
libavcodec/vaapi_mjpeg.c | 2 +-
libavcodec/vaapi_mpeg2.c | 2 +-
libavcodec/vaapi_mpeg4.c | 2 +-
libavcodec/vaapi_vc1
When there are multiple tiles in one slice buffer, use multiple slice
params to avoid sending the same slice buffer multiple times and thus
increasing the bitstream size the driver will need to upload to hw.
---
libavcodec/vaapi_av1.c | 37 +++--
1 file changed, 23
This path can be hit when there are missing references while decoding
progressive stream and would completely break the DPB contents.
---
libavcodec/vaapi_h264.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vaapi_h264.c b/libavcode
If there are missing references, h264 decode does error concealment
by copying previous refs which means there will be duplicated surfaces
and this code would try to merge them instead of correctly appending
to DPB. Make sure the fields were actually merged before early return.
---
libavcodec/vaap
On Mon, May 6, 2024 at 9:55 PM Mark Thompson wrote:
>
> On 05/05/2024 17:36, David Rosca wrote:
> > This path can be hit when there are missing references while decoding
> > progressive stream and would completely break the DPB contents.
> > ---
> >
---
v2: No changes
libavcodec/vaapi_av1.c| 2 +-
libavcodec/vaapi_decode.c | 3 ++-
libavcodec/vaapi_decode.h | 1 +
libavcodec/vaapi_h264.c | 2 +-
libavcodec/vaapi_hevc.c | 4 ++--
libavcodec/vaapi_mjpeg.c | 2 +-
libavcodec/vaapi_mpeg2.c | 2 +-
libavcodec/vaapi_mpeg4.c | 2 +-
liba
When there are multiple tiles in one slice buffer, use multiple slice
params to avoid sending the same slice buffer multiple times and thus
increasing the bitstream size the driver will need to upload to hw.
---
v2: Avoid allocations every slice.
libavcodec/vaapi_av1.c | 47 ++
On Tue, May 7, 2024 at 10:01 PM Mark Thompson wrote:
>
> On 28/04/2024 08:26, David Rosca wrote:
> > When there are multiple tiles in one slice buffer, use multiple slice
> > params to avoid sending the same slice buffer multiple times and thus
> > increasing the bitstr
If there are missing references, h264 decode does error concealment
by copying previous refs which means there will be duplicated surfaces.
Check long_ref and frame_idx in addition to surface when looking for
the other field to avoid trying to merge with wrong picture.
Also allow to merge with mult
On Tue, May 7, 2024 at 10:22 PM Mark Thompson wrote:
>
> On 07/05/2024 07:00, David Rosca wrote:
> > If there are missing references, h264 decode does error concealment
> > by copying previous refs which means there will be duplicated surfaces
> > and this code would try
Matches other hwaccels.
---
libavcodec/vaapi_decode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 8e9f647c20..3c4030c073 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -157,6 +157,11 @@ int ff_vaapi
Matches other hwaccels.
---
v2: AVERROR
libavcodec/vaapi_decode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 8e9f647c20..7c91d50f7b 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -157,6 +157,11 @@
Quantization scaling seems to be a slight bottleneck,
this change allows the compiler to more easily vectorize
the loop. This improves total encoding performance in my
tests by about 10-20%.
Signed-off-by: David Murmann
---
libavcodec/proresenc_anatoliy.c | 12
1 file changed, 8
On 2/27/2018 9:58 PM, Hendrik Leppkes wrote:
> On Tue, Feb 27, 2018 at 9:35 PM, David Murmann
wrote:
>> Quantization scaling seems to be a slight bottleneck,
>> this change allows the compiler to more easily vectorize
>> the loop. This improves total encoding performa
---
libavcodec/vaapi_encode.c | 1 +
libavcodec/vaapi_encode.h | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index bfca315a7a..f161c76304 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -
v2: Add description in encoders.texi
---
doc/encoders.texi | 3 +++
libavcodec/vaapi_encode.c | 1 +
libavcodec/vaapi_encode.h | 9 -
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 25d6b7f09e..f146942aa5 100644
--- a/doc/e
Support for allocating frames with x2rgb10 format was added
in c00264f5013, this adds support for importing DMA-BUFs.
---
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6c3a227ddd..63544ce476 100644
Support for allocating frames with x2rgb10 format was added
in c00264f5013, this adds support for importing DMA-BUFs.
v2: Fix #ifdef -> #if
---
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6c3a22
1 - 100 of 184 matches
Mail list logo
