Add more detailed documenation for the libjxl encoder
wrapper than is present currently inside libavcodec.
---
doc/encoders.texi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index aac9f25e55..99399d4674 100644
--- a/d
On Mon, Apr 25, 2022 at 09:44:58PM +0200, Jean-Baptiste Kempf wrote:
>
>
> On Mon, 25 Apr 2022, at 20:40, Michael Niedermayer wrote:
> > On Mon, Apr 25, 2022 at 08:04:25PM +0200, Jean-Baptiste Kempf wrote:
> >> On Mon, 25 Apr 2022, at 19:19, Michael Niedermayer wrote:
> >> > On Mon, Apr 25, 2022
Hi Nicolas,
thanks for your feedback. I think there is a misunderstanding due to my
little experience with this community.
I'm actually modifying the drawtext filter to enhance some of its
features, as I described in the IRC channel, but in my message I
mentioned only the "line spacing" since
Use h264_sei to parse SEI data got from MediaSDK. Extract frame
packing arrangement information from SEI data and config AVStereo3D
side data for decoded frame.
Signed-off-by: Wenbin Chen
Signed-off-by: Tong Wu
---
libavcodec/qsv_internal.h | 2 +
libavcodec/qsvdec.c | 160 +
On 26/04/2022 09:29, Hendrik Leppkes wrote:
On Tue, Apr 26, 2022 at 9:08 AM Tobias Rapp wrote:
On 23/04/2022 22:56, Nil Admirari wrote:
Newer versions of Windows (Windows 10 1607 and newer) can support path
names longer than MAX_PATH (260 characters). To take advantage of that, an
application
> On Apr 22, 2022, at 4:37 PM, Malviya, Janpriya
> wrote:
>
> Hello ffmpeg Dev team,
>
> While integrating FFmpeg for M4A , MP4 stream & facing issue that mov demuxer
> trying to request seek for invalid seek offset.
>
> Issue details:-
> - Modified doc/examples/demuxing_decoding.c
---
libavformat/mov.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6116078b1a..e948c6cd0f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7693,12 +7693,12 @@ static int mov_read
---
libavformat/mov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index e948c6cd0f..429f9fcbf7 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7691,10 +7691,12 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb
---
libavformat/mov.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 26aeeaea0c..6116078b1a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7693,9 +7693,6 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
The main loop processes blocks of 16 pixels. The tail processes blocks
of size 4.
---
libswscale/x86/scale_avx2.asm | 44 ++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/libswscale/x86/scale_avx2.asm b/libswscale/x86/scale_avx2.asm
index 20acdbd633
Hi Paul, Michael,
Thanks for your responses and review.
Paul: I have tested this on many input sizes (primes etc) and it works. It
has the same restriction as the original SSSE3 version, it processes pixels
in blocks of 4, however, sufficient memory is allocated so that reads and
writes are safe.
On Tue, Apr 26, 2022 at 9:08 AM Tobias Rapp wrote:
>
> On 23/04/2022 22:56, Nil Admirari wrote:
> > Newer versions of Windows (Windows 10 1607 and newer) can support path
> > names longer than MAX_PATH (260 characters). To take advantage of that, an
> > application needs to opt in, by including a
On Mon, 25 Apr 2022, Andre Kempe wrote:
This patch fixes a wrong type of BTI landing pad when branching to
functions instantiated via the fft*_neon macro.
Although the previously employed paciasp instruction serves as a landing
pad, for the ways that this function is invoked it is the wrong typ
On 23/04/2022 22:56, Nil Admirari wrote:
Newer versions of Windows (Windows 10 1607 and newer) can support path
names longer than MAX_PATH (260 characters). To take advantage of that, an
application needs to opt in, by including a small manifest as a resource.
Application must be prepared to han
14 matches
Mail list logo
