From: Josh de Kock
---
doc/examples/filter_audio.c | 2 --
doc/examples/filtering_audio.c | 2 --
doc/examples/filtering_video.c | 2 --
doc/examples/transcoding.c | 2 --
fftools/ffmpeg.c | 6 --
fftools/ffplay.c | 7 ---
fftools/ffprobe.c
From: Josh de Kock
---
tests/checkasm/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 0520e264e2..ae7e810d25 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -61,7 +61,7 @@ tests/checkasm
From: Josh de Kock
---
fftools/cmdutils.c | 239 +
1 file changed, 112 insertions(+), 127 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 708a849f51..2da313cc0a 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
From: Josh de Kock
---
configure| 24 +-
doc/APIchanges | 4 +
doc/writing_filters.txt | 6 +-
libavfilter/allfilters.c | 818 +--
libavfilter/avfilter.c | 45 ---
libavfilter/avfilter.h | 29 +-
libavfilter
In intra-only mode, frameIntervalP is 0, which means the frame
data array is smaller than the number of surfaces. This causes a
crash when closing the encoder.
Fix this by making sure the frame data array is at least as big as
the number of surfaces.
---
libavcodec/nvenc.c | 2 +-
1 file changed,
On Thu, 20 Jun 2024 at 17:39, Josh Allmann wrote:
>
> In intra-only mode, frameIntervalP is 0, which means the frame
> data array is smaller than the number of surfaces. This causes a
> crash when closing the encoder.
>
> Fix this by making sure the frame data array is at lea
Makes certain usages of the lavfi API easier.
---
libavfilter/vf_scale_cuda.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index b7cdb81081..6b1ef2bb6f 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libav
On Fri, 24 May 2019 at 06:00, Timo Rothenpieler wrote:
>
> On 24/05/2019 01:49, Josh Allmann wrote:
> > Makes certain usages of the lavfi API easier.
> > ---
> > libavfilter/vf_scale_cuda.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
&g
The first frame is scaled correctly, and subsequent frames are
over-scaled / cropped since the frame data is reset with the
hwframe after each invocation of the scaler.
The hwframe-allocated frame has a width/height that is 32-bit
aligned. The scaler uses this aligned width / height as its target,
On Fri, 24 May 2019 at 09:55, Timo Rothenpieler wrote:
>
> On 24.05.2019 18:27, Josh Allmann wrote:
> > On Fri, 24 May 2019 at 06:00, Timo Rothenpieler
> > wrote:
> >>
> >> On 24/05/2019 01:49, Josh Allmann wrote:
> >>&
Hi,
On Sat, 24 Mar 2018 at 14:40, Josh de Kock wrote:
>
> Signed-off-by: Josh de Kock
> ---
> configure| 29 +-
> doc/APIchanges | 4 +
> doc/writing_filters.txt | 6 +-
> libavfilt
cessing one segment at a time,
where closing and re-opening a new encoder is expensive (as is the
case with HW / nvenc). The original writeup for the motivation leading
up to "encoder flush" can be found here:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1574125994-7782-1-git-send-
On Tue, 14 Apr 2020 at 01:53, Josh de Kock wrote:
>
> Hi,
>
> On Mon, Apr 13, 2020, at 10:32 PM, Josh Allmann wrote:
> > Hi,
> >
> > On Sat, 24 Mar 2018 at 14:40, Josh de Kock wrote:
> > >
> > > Signed-off-by: Josh de Kock
> > > ---
>
Hell, can someone please review this patch? It fixes a wrong reference frame
computation problem when using parameters such as "-level 31" instead of
"-level 3.1".
From 9f9dcb3cceebb360468fea762b01780f65764a47 Mon Sep 17 00:00:00 2001
From: Josh Brewster
Date: Thu, 16 Apr
.
>
> - Linjie
>
> 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".
Hi Linjie, thanks for the feedback.
the level simply wouldn't be present in x264_levels.
>
> I'd say yes, level_idc = 0 is possible but invalid by PARSE_X264_OPT(), which
> seems
> make no sense to calculate refs from x264_levels[] table.
>
> - Linjie
Changed to > 0, thanks.
From af09a7c3d33db90092be3
> > > I only made sure that the level was positive because its initial
> > > value was -1.
> > >
> > > > else if (x4->params.i_level_idc >= 0) {
> > > > Let me know if I need to reject 0 too. It seemed like premature
> > > > optimization
> > > > as the level simply wouldn't be present in x264_leve
Set pushed with all Martin's changes implemented. More NEON & updates soon.
--
Josh
On 2021-02-04 12:32, Josh Dekker wrote:
Hi,
Rebases the unpushed part of my patches on top of Reimar's set. Also
implements Martin's suggestions except 'unrolling the loop' for S
Signed-off-by: Josh Dekker
---
configure| 2 +
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c| 19 -
tests/checkasm/checkasm.h| 10 ++-
tests/checkasm/macos_kperf.c | 143 +++
tests/checkasm/macos_kperf.h | 23
Set applied.
--
Josh
___
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".
> > From: ffmpeg-devel ffmpeg-devel-boun...@ffmpeg.org On Behalf Of
> > Josh de Kock
> > Sent: Tuesday, April 28, 2020 23:47
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference
> > frame computation ba
in between segments?
* If there is no alternative, would you be open to a more formalized
addition to the avcodec API around "flushable" or "resumable"
encoders?
Thanks for your thoughts!
Josh
[0] https://github.com/livepeer/lpms
[1] https://gist.github.com/j0sh/ae9e5a97
On Fri, 20 Dec 2019 at 15:36, Philip Langdale wrote:
>
> On 2019-11-18 17:13, Josh Allmann wrote:
> > This patch is meant to be an entry point for discussion around an
> > issue we are having with flushing the nvenc encoder while doing
> > segmented transcoding. Hopefu
is behavior.
Right now, it works, but perhaps only coincidentally? Being flushable
and resumable like this isn't explicitly part of the "contract" for
nvenc, as far as I can see. Could future changes inadvertently
introduce state that isn't reset in between flus
On Mon, 30 Dec 2019 at 16:40, Philip Langdale wrote:
>
> On Sat, 21 Dec 2019 14:54:38 -0800
> Philip Langdale wrote:
>
> > On Fri, 20 Dec 2019 16:07:18 -0800
> > Josh Allmann wrote:
> >
> > > One concern I had was about the long-term stability of this
&
sane. I think it's fine to use it whilst I'm working on refractoring
it due to the large speedup: the code-weight in the binary should be
relatively similar even after that anyway.
Also, updated kperf patch as per Lynne's request.
--.
Josh
__
Signed-off-by: Josh Dekker
---
configure | 2 +
libavutil/Makefile| 1 +
libavutil/macos_kperf.c | 140 ++
libavutil/macos_kperf.h | 23 +++
libavutil/timer.h | 17 -
tests/checkasm/checkasm.c | 14 +++-
tests
Previously, one or the other would have been ignored, but not both.
Since the probe terminates at three streams, it could exit
prematurely if both data and subtitles are present along with
slightly trailing media, usually video trailing audio.
Trailing media is common in RTMP, and encoders write s
On Thu, 13 May 2021 at 16:38, Josh Allmann wrote:
>
> Previously, one or the other would have been ignored, but not both.
> Since the probe terminates at three streams, it could exit
> prematurely if both data and subtitles are present along with
> slightly trailing media, usually
---
libavformat/rtmpproto.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index faf2a6f244..b741e421af 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2431,8 +2431,10 @@ static int get_packet(URLConte
Fixes a leak that occurs if avctx->extradata contains any data
prior to opening the codec, eg left over from an initialization
call to avcodec_parameters_from_context.
---
libavcodec/aacenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 6d
On 6 February 2018 at 03:16, Rostislav Pehlivanov
wrote:
> On 6 February 2018 at 06:56, Josh Allmann
> wrote:
>
> > Fixes a leak that occurs if avctx->extradata contains any data
> > prior to opening the codec, eg left over from an initialization
> > call to a
---
doc/bitstream_filters.texi | 5 +
libavcodec/noise_bsf.c | 12
libavcodec/version.h | 2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index cfd81fa12d..a9f17f32ec 100644
--- a/doc/bitstrea
On 7 March 2018 at 18:03, Michael Niedermayer wrote:
> On Tue, Mar 06, 2018 at 12:47:15PM -0800, Josh Allmann wrote:
>> ---
>> doc/bitstream_filters.texi | 5 +
>> libavcodec/noise_bsf.c | 12
>> libavcodec/version.h | 2 +-
>> 3 f
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references
On Sat, 6 Jul 2024 at 09:37, Michael Niedermayer wrote:
>
> On Wed, Jul 03, 2024 at 02:05:06PM -0700, Josh Allmann wrote:
> > Encoders may emit a buffering period SEI without a corresponding
> > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >
> > D
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references
On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffer
On Mon, 15 Jul 2024 at 10:48, Josh Allmann wrote:
>
> On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
> >
> > Encoders may emit a buffering period SEI without a corresponding
> > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >
> > During An
On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffer
On Mon, 22 Jul 2024 at 17:17, Timo Rothenpieler wrote:
>
> On 23/07/2024 01:01, Josh Allmann wrote:
> > On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
> >>
> >> Encoders may emit a buffering period SEI without a corresponding
> >> SPS/PPS if the SPS/P
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references
On Thu, 1 Aug 2024 at 00:58, Anton Khirnov wrote:
>
Thanks for the review.
> Quoting Josh Allmann (2024-07-09 21:05:47)
> > Encoders may emit a buffering period SEI without a corresponding
> > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >
> > D
On Thu, 1 Aug 2024 at 14:37, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffer
On Wed, 7 Aug 2024 at 09:13, Josh Allmann wrote:
>
> On Thu, 1 Aug 2024 at 14:37, Josh Allmann wrote:
> >
> > Encoders may emit a buffering period SEI without a corresponding
> > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >
> > During An
vio)
- Deprecating libpostproc
- Writing down development rules
- Switching to a merge request-like system
- Propose FFmpeg/SPI purchase a Mac Mini ARM machine for development (and FATE
if required).
## People Present (15)
- Jean-Baptiste Kempf
- Josh Dekker (Illya)
- Jan Ekström
- Michael Niederma
ion would be a machine with
both a modern nVidia GPU and AMD GPU for testing hardware acceleration
integration.
Kieran offered to host one Mac Mini, though I'm unsure what his capacity for
hosting is.
Any comments and suggestions welcome.
--
Josh
__
unc() instead.
+for(int i = 0; i < SRC_PIXELS; ++i){
+dither[i] = d_val;
+}
[...]
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
A negative start_dts value (eg, delay from edit lists) typically yields
a duration larger than end_pts. During edit list processing, the
delay is removed again, yielding the correct duration within the elst.
However, other duration-carrying atoms (tkhd, mvhd, mdhd) still have
the delay incorporate
On Fri, 11 Dec 2020 at 14:07, Martin Storsjö wrote:
>
> On Fri, 11 Dec 2020, Josh Allmann wrote:
>
> > A negative start_dts value (eg, delay from edit lists) typically yields
> > a duration larger than end_pts. During edit list processing, the
> > delay is removed
Hi Martin,
On Sat, 19 Dec 2020 at 15:10, Martin Storsjö wrote:
>
> On Fri, 11 Dec 2020, Josh Allmann wrote:
>
> > On Fri, 11 Dec 2020 at 14:07, Martin Storsjö wrote:
> >>
> >> On Fri, 11 Dec 2020, Josh Allmann wrote:
> >>
> >> > A negative
Ok from me too. I would suggest getting 2x, one for only FATE and the
other for general access & development for FFmpeg developers.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: Josh Dekker
---
checkasm: all 648 tests passed
hevc_add_res_4x4_8_c: 49.7
hevc_add_res_4x4_8_neon: 20.5
hevc_add_res_4x4_10_c: 46.0
hevc_add_res_4x4_10_neon: 19.0
hevc_add_res_8x8_8_c: 209.0
hevc_add_res_8x8_8_neon: 24.5
hevc_add_res_8x8_10_c: 192.7
hevc_add_res_8x8_10_neon: 27.0
ncorrectly.
IDCT (first) and QPEL functions in the works, then SAO edge, and
whatever is left for parity with ARM NEON.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 2 +
libavcodec/aarch64/hevcdsp_add_res_neon.S | 298 ++
libavcodec/aarch64/hevcdsp_init.c | 59 +
libavcodec/hevcdsp.c | 2 +
libavcodec/hevcdsp.h
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile| 3 +-
libavcodec/aarch64/hevcdsp_idct_neon.S | 74 ++
libavcodec/aarch64/hevcdsp_init.c | 19 +++
3 files changed, 95 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64
Only works for 8x8.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 3 +-
libavcodec/aarch64/hevcdsp_init.c | 7 +++
libavcodec/aarch64/hevcdsp_sao_neon.S | 87 +++
3 files changed, 96 insertions(+), 1 deletion(-)
create mode 100644
Co-authored-by: Niklas Haas
Signed-off-by: Josh Dekker
---
tests/checkasm/Makefile | 2 +-
tests/checkasm/checkasm.c | 10 +
tests/checkasm/checkasm.h | 10 +
tests/checkasm/hevc_pel.c | 523 ++
4 files changed, 544 insertions(+), 1 deletion(-)
create
porting this, I was in the process of writing HEVC
assembly (see my set on the ML) and would be interested to rebase this
on top of that set.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-deve
Hi Martin,
On Fri, 15 Jan 2021 at 04:59, Martin Storsjö wrote:
>
> Hi Josh,
>
> On Tue, 22 Dec 2020, Josh Allmann wrote:
>
> > Thank you for taking the time to look into this! Tested with your
> > alternative patch and it does seem to be an improvement. I was able
default="dumpbin.exe -symbols"
ar_default="lib.exe"
- case "$arch" in
+ case "${arch:-$arch_default}" in
aarch64|arm64)
as_default="armasm64.exe"
;;
--
2.30.0
LGTM, thanks!
// Martin
Thanks, p
On 2021-01-07 13:10, Josh Dekker wrote:
Co-authored-by: Niklas Haas
Signed-off-by: Josh Dekker
---
tests/checkasm/Makefile | 2 +-
tests/checkasm/checkasm.c | 10 +
tests/checkasm/checkasm.h | 10 +
tests/checkasm/hevc_pel.c | 523 ++
4 files
. Applied with a slightly edited commit message to conform to our
conventions & a small reference to the spec.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link a
Hi,
Rebases the unpushed part of my patches on top of Reimar's set. Also
implements Martin's suggestions except 'unrolling the loop' for SAO band
function, will update the band function when I fix non 8x8 cases.
--
Josh
___
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 54 +++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 16 +++
2 files changed, 70 insertions(+)
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
b/libavcodec/aarch64/hevcdsp_idct_neon.S
index
From: Reimar Döffinger
Speedup is fairly small, around 1.5%, but these are fairly simple.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 190 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 24 +++
2 files changed, 214 insertions(+)
diff --git
the first 300 frames of "LG 4K HDR Demo - New York.ts",
running on Apple M1.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 2 +
libavcodec/aarch64/hevcdsp_idct_neon.S| 380 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++
Only works for 8x8.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 3 +-
libavcodec/aarch64/hevcdsp_init_aarch64.c | 7 ++
libavcodec/aarch64/hevcdsp_sao_neon.S | 87 +++
3 files changed, 96 insertions(+), 1 deletion(-)
create mode 100644
On 16/10/2018 12:33, Michael Niedermayer wrote:
On Mon, Oct 15, 2018 at 01:32:03PM +0100, jos...@ob-encoder.com wrote:
From: Josh de Kock
This test ensures that you are able to send N number of slice NALUs in slice
threaded mode to be decoded simultaneously
---
Tested on Linux 32/64, MinGW
On 24/10/2018 19:02, jos...@ob-encoder.com wrote:
From: Josh de Kock
This test ensures that you are able to send N number of slice NALUs in slice
threaded mode to be decoded simultaneously
---
tests/api/Makefile | 1 +
tests/api/api-h264-slice-test.c | 221
Hi Steven,
On Mon, Feb 24, 2020, at 2:03 AM, Steven Liu wrote:
> [...]
> How can I get the script :D
>
> Thanks
>
> Steven
I won't be looking to upstream this script (the other one yes), but I will
share it here for you. You'll have to excuse my poor scripting :)
-
On Mon, Feb 24, 2020, at 11:19 AM, Thilo Borgmann wrote:
> Am 23.02.20 um 21:40 schrieb Josh de Kock:
> > On Sun, Feb 23, 2020, at 4:07 PM, Thilo Borgmann wrote:
> >> [...]
> >>
> >> How is it automatically generated?
> >
> > I wrote a sma
On Tue, Mar 3, 2020, at 12:55 PM, sumaklos rembert wrote:
> We are hiring a remote FFMPEG engineer
>
> [...]
You already posted this a week ago, there is no need to spam the
list with the same job multiple times.
--
Josh
___
ffmpeg-devel mai
Hi,
On Mon, Apr 13, 2020, at 10:32 PM, Josh Allmann wrote:
> Hi,
>
> On Sat, 24 Mar 2018 at 14:40, Josh de Kock wrote:
> >
> > Signed-off-by: Josh de Kock
> > ---
> > configure| 29 +-
> > doc/APIchanges |
On Tue, Apr 14, 2020, at 9:09 AM, Anton Khirnov wrote:
> ---
> fftools/cmdutils.c | 33 +++--
> 1 file changed, 19 insertions(+), 14 deletions(-)
>
> [...]
LGTM, thanks. I will apply this a bit later after my set (or you can if you
want it soo
Signed-off-by: Josh de Kock
---
libavcodec/options.c | 5 +++--
libavcodec/tests/utils.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index 35e8ac9313..babab599fc 100644
--- a/libavcodec/options.c
+++ b/libavcodec
Signed-off-by: Josh de Kock
---
tools/enum_options.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/enum_options.c b/tools/enum_options.c
index 28631d1a6b..548e427b7a 100644
--- a/tools/enum_options.c
+++ b/tools/enum_options.c
@@ -113,13 +113,14 @@ static void
Signed-off-by: Josh de Kock
---
libavformat/utils.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index a58e47fabc..4f777ba849 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -222,7 +222,8 @@ static const AVCodec
Works around a bug in the newer Xcode 11's clang with -fstack-check
emitting bad code with misaligned call instructions.
---
configure | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index 4d4c429be9..c872a2932d 100755
--- a/configure
+++ b/configure
@@ -5358,6 +5358
Works around a bug in the newer Xcode 11's clang with -fstack-check
emitting bad code with misaligned call instructions.
This fixes Trac #8073
---
configure | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index 4d4c429be9..2ede4e7163 100755
--- a/configure
+++ b/con
On Wed, Apr 15, 2020, at 3:54 PM, Jan Ekström wrote:
> [...]
>
> Thank you, LGTM from me.
>
> Jan
Pushed.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscr
On 14/04/2020 13:37, Josh de Kock wrote:
On Tue, Apr 14, 2020, at 9:09 AM, Anton Khirnov wrote:
---
fftools/cmdutils.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
[...]
LGTM, thanks. I will apply this a bit later after my set (or you can if
On 14/04/2020 13:38, Josh de Kock wrote:
Signed-off-by: Josh de Kock
---
tools/enum_options.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/enum_options.c b/tools/enum_options.c
index 28631d1a6b..548e427b7a 100644
--- a/tools/enum_options.c
+++ b/tools
This script aims to extract contributors who are eligible for the
general assembly.
Signed-off-by: Josh de Kock
---
Better late than never, this patch will continue to put in place the
voting systems for FFmpeg discussed at VDD 2019 and FOSDEM 2020.
There is probably a better way to do this
On 24/04/2020 11:29, Nicolas George wrote:
Josh de Kock (12020-04-24):
This script aims to extract contributors who are eligible for the
general assembly.
Signed-off-by: Josh de Kock
---
Better late than never, this patch will continue to put in place the
voting systems for FFmpeg
t (check first
this works).
Like Marton said, it's probably a bit on the verbose side, just have a
read over and see if you can say the same thing with less words. I don't
think being verbose is necessarily bad either, as you said there's less
chance t
On 26/04/2020 12:46, Josh Brewster wrote:
I only made sure that the level was positive because its initial
value was -1.
else if (x4->params.i_level_idc >= 0) {
Let me know if I need to reject 0 too. It seemed like premature optimization
as the level simply wouldn't be present in
Signed-off-by: Josh de Kock
---
tools/probetest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Small fix for compiler warning caused by my earlier change.
diff --git a/tools/probetest.c b/tools/probetest.c
index cfa309cabd..6f0e002b74 100644
--- a/tools/probetest.c
+++ b/tools
eekable", "Use HTTP partial requests, 0 = disable, 1 = enable, -1 =
auto",
Whilst I'm not against a stop-gap change for this, did you already open
a ticket for this? I think it would be good to track it.
--
Josh
___
ffmpeg-devel mail
vc2-422p12 \
This was applied.
--
Josh
___
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".
On 24/04/2020 11:44, Josh de Kock wrote:
On 24/04/2020 11:29, Nicolas George wrote:
Josh de Kock (12020-04-24):
This script aims to extract contributors who are eligible for the
general assembly.
Signed-off-by: Josh de Kock
---
Better late than never, this patch will continue to put in
://trac.ffmpeg.org/ticket/7485
Are you Nick Ryan / did you write the attached patches?
The LinkedIn on his website suggests he is.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
-h264-slice-test.c
@@ -24,7 +24,6 @@
#include "config.h"
-#include
Good idea.
Carl Eugen
Ping for this, thx.
- Linjie
Thanks, applied.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listi
;fin_pad"},
{ "fout_pad", "fixed output cubemap pads", OFFSET(fout_pad), AV_OPT_TYPE_INT,
{.i64=0}, 0, 100,TFLAGS, "fout_pad"},
{ "yaw", "yaw rotation", OFFSET(yaw), AV_OP
o hence we have this
to begin somewhere.
The community and technical committees will be decided by the
bootstrapped general assembly, along with formalising the voting
procedures and processes. Going forward from there it should be a pretty
simple case of just continuing the methods which we
On 29/04/2020 20:58, Michael Niedermayer wrote:
On Wed, Apr 29, 2020 at 12:00:23PM +0100, Josh de Kock wrote:
Signed-off-by: Josh de Kock
---
tools/probetest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Small fix for compiler warning caused by my earlier change.
LGTM
This tests the hscale 8bpp to 14bpp functions with different filter
sizes.
Signed-off-by: Josh de Kock
---
Not quite ready to be committed but I wanted to submit it anyway so I
could get some comments. I still need to do the rest of the scale sizes
(such as 8bpp to 19bpp) and make the
The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used.
Signed-off-by: Josh de Kock
---
libswscale/aarch64/swscale.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libswscale/aarch64/swscale.c b/libswscale/aarch64
On 05/05/2020 17:02, Fu, Linjie wrote:
From: ffmpeg-devel On Behalf Of
Josh Brewster
Sent: Tuesday, May 5, 2020 23:52
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference
frame computation based on level
From: ffmpeg-devel
This tests the hscale 8bpp to 14bpp functions with different filter
sizes.
Signed-off-by: Josh de Kock
---
Should address all previous comments.
tests/checkasm/Makefile | 2 +-
tests/checkasm/checkasm.c | 1 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/sw_scale.c | 114
1 - 100 of 423 matches
Mail list logo
