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
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
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
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
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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
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".
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 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 SAO band
function, will up
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
was 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 +++
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
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
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
___
ffmpeg-devel mailing
. 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
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
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
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 ab
he 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-devel
To unsubscribe, visit
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
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
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
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
.
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 link above
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
k 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
To u
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
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
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
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
ould 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
___
ffmpeg-d
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
ng) tomorrow if no objections.
Thanks for updating the set, this is what I had in mind. I can't
properly LGTM it since I haven't tested it myself but it looks mostly
fine with a precursory glance.
--
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".
As you said in the commit message, h264 already does this so it would be
nice if you didn't duplicate the code. Split both parts of s12m decoding
you've copied into a common h2645 or just an s12m file maybe?
--
Josh
___
ffmpeg-devel mailing list
ffmpeg
On 17/06/2020 18:16, Josh de Kock wrote:
On 17/06/2020 15:16, Zhong Li wrote:
Signed-off-by: Zhong Li
---
.mailmap | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index d1925bfab0..f14770d800 100644
--- a/.mailmap
+++ b/.mailmap
@@ -15,7 +15,8
would like the last two emails to be displayed as
lizhong1...@gmail.com.
rcombs
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg
for the patch. Almost a 3x speedup on my machine.
Pushed.
--
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
this is the best way to solve it.
--
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".
To prepare for using the cached bitstream reader, which only defines the
inline functions rather than the macros, with CAVLC decoding.
Signed-off-by: Josh de Kock
---
libavcodec/h264_cavlc.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavcodec
On 16/05/2020 11:50, Carl Eugen Hoyos wrote:
Am Fr., 15. Mai 2020 um 12:27 Uhr schrieb Josh de Kock :
On 08/05/2020 12:25, Michael Niedermayer wrote:
On Thu, May 07, 2020 at 12:25:34PM +0100, Josh de Kock wrote:
The NEON hscale function only supports X8 filter sizes and should only
gb.h
index 3569254df9..48bba1586a 100644
--- a/libswscale/rgb2rgb.h
+++ b/libswscale/rgb2rgb.h
@@ -169,6 +169,7 @@ extern void (*yuyvtoyuv422)(uint8_t *ydst, uint8_t *udst,
uint8_t *vdst, const u
void ff_sws_rgb2rgb_init(void);
+void rgb2rgb_init_aarch64(void);
void rg
On 15/05/2020 19:35, Martin Storsjö wrote:
From: Josh de Kock
The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used. At the moment filterAlign is
set to 8 but in the future when extra NEON assembly for specific sizes is
added
On 14/05/2020 22:28, Martin Storsjö wrote:
On Thu, 14 May 2020, Josh de Kock wrote:
From: Martin Storsjö
This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0).
Signed-off-by: Josh de Kock
---
tests/checkasm/checkasm.c | 42 +++
tests
On 15/05/2020 09:41, Martin Storsjö wrote:
On Thu, 14 May 2020, Josh de Kock wrote:
This tests the hscale 8bpp to 14bpp functions with different filter
sizes.
Signed-off-by: Josh de Kock
---
Adds support for checking corner cases for signed and large
coefficients. Also makes the padded
On 08/05/2020 12:25, Michael Niedermayer wrote:
On Thu, May 07, 2020 at 12:25:34PM +0100, Josh de Kock wrote:
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
This tests the hscale 8bpp to 14bpp functions with different filter
sizes.
Signed-off-by: Josh de Kock
---
Adds support for checking corner cases for signed and large
coefficients. Also makes the padded coefficients random data.
Tested on x86_64 and aarch64.
tests/checkasm/Makefile
From: Martin Storsjö
This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0).
Signed-off-by: Josh de Kock
---
tests/checkasm/checkasm.c | 42 +++
tests/checkasm/checkasm.h | 16 +++
2 files changed, 58 insertions(+)
diff --git
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
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
---
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 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
> > 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
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
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 were chosen.
--
Josh
;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
-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
://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
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
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".
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 maili
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
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 x264_
id, 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 that a user would have to end up looking into code to know ho
> > > 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
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
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
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
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
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 af09a7c3d33db90092be3dea57ba449
- 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. I ha
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
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
> > > ---
>
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
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
+++
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
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
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
---
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
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
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 |
ning 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-email-joshua.allm...@gmail.com/
Josh
_
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
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
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
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 :)
--
Josh
#
On Sun, Feb 23, 2020, at 4:07 PM, Thilo Borgmann wrote:
> [...]
>
> How is it automatically generated?
I wrote a small script to parse author names/emails and group
emails together based on names. In the future, additions should
be added manually.
her individually then you won't be eligible for the
general assembly. You can still see which commits are on each
email (since this is important for copyright reasons).
It is just a visual thing: I will swap your association to show
your gmail email first.
--
Josh
_
for themselves (but it can always be changed later).
--
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".
This allows for easy shortlog/log parsing, useful in determining
eligible members of the general assembly for the new FFmpeg voting
system.
Signed-off-by: Josh de Kock
---
This list was automatically generated based off of commits from
people with the same names. If you want this adjusted/your
discussed.
I will make sure to take notes in any future meetings. I think that this
is the best way to ensure that it properly gets done by holding myself,
rather than others, accountable.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
eone is willing to implement a fix, then the answer
to this doesn't even matter at all, and should always be 'yes'--you have
my support for this set, at least.
--
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 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 t
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 flushes, break
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
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/ae9e5a97e794e364a6dfe51
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:
> >>&
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
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
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
+++
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
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
1 - 100 of 403 matches
Mail list logo
