On Sun, Nov 12, 2023 at 11:40:26AM +1100, Peter Ross wrote:
> Fixed ticket #10656.
> ---
> libavcodec/leaddec.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/leaddec.c b/libavcodec/leaddec.c
> index ede52fba5a..fd2018256d 100644
> --- a/libavcodec/lea
On 2/14/24 13:53, Andreas Rheinhardt wrote:
Leo Izen:
Write EXIF metadata exposed AV_FRAME_DATA_EXIF as an eXIf chunk
to PNG files, if present.
Signed-off-by: Leo Izen
---
libavcodec/pngenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
i
On Sun, Nov 12, 2023 at 11:41:23AM +1100, Peter Ross wrote:
> Fixes ticket #10660.
> ---
>
> thanks to the mysterious 'ami_stuff'.
>
> libavcodec/leaddec.c | 38 ++
> 1 file changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/leaddec.c b/li
> 在 2024年2月15日，下午3:57，Matthieu Bouron 写道：
>
> On Thu, Feb 15, 2024 at 12:13:59PM +0800, Zhao Zhili wrote:
>>
>>
On Feb 14, 2024, at 06:50, Matthieu Bouron
wrote:
>>>
>>> Hi,
>>>
>>> On Android, content providers are used for accessing files through shared
>>> mechanisms. One typ
Le jeu. 15 févr. 2024, 9:46 AM, Zhao Zhili a
écrit :
>
> > 在 2024年2月15日，下午3:57，Matthieu Bouron 写道：
> >
> > On Thu, Feb 15, 2024 at 12:13:59PM +0800, Zhao Zhili wrote:
> >>
> >>
> On Feb 14, 2024, at 06:50, Matthieu Bouron
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Android, content providers
Hi,
sorry for the delay, I've been busy fixing things for the release
Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
> On 2024-01-28 04:24 pm, Anton Khirnov wrote:
> >> a) it would mean essentially inlining this decoder in the demuxer.
> > Why is that a problem? This decoder seems like i
From: Frank Plowman
The PPS should be used instead of the SPS to get the current picture's
dimensions. Using the SPS can cause issues if the resolution changes
mid-sequence. In particular, it was leading to invalid memory accesses
if the resolution decreased.
Patch replaces sps->{width,height}
On 2024-02-15 04:17 pm, Anton Khirnov wrote:
Hi,
sorry for the delay, I've been busy fixing things for the release
Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
On 2024-01-28 04:24 pm, Anton Khirnov wrote:
a) it would mean essentially inlining this decoder in the demuxer.
Why is
Andreas Rheinhardt:
> We currently mostly do not empty the MMX state in our MMX
> DSP functions; instead we only do so before code that might
> be using x87 code. This is a violation of the System V i386 ABI
> (and maybe of other ABIs, too):
> "The CPU shall be in x87 mode upon entry to a function.
> Will apply this patch tomorrow unless there are objections.
>
LGTM
___
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 s
Quoting Marton Balint (2024-02-13 21:27:34)
>
>
> On Tue, 13 Feb 2024, James Almer wrote:
>
> > On 2/12/2024 6:15 PM, Marton Balint wrote:
> >> Signed-off-by: Marton Balint
> >> ---
> >>libavutil/channel_layout.h | 4
> >>1 file changed, 4 insertions(+)
> >>
> >> diff --git a/lib
Quoting Marton Balint (2024-02-12 22:15:37)
> - native order, and that a single channel only appears once was always assumed
> for less than 64 channels, obviously this was incorrect
Could you add a test for the case where it's not true?
--
Anton Khirnov
___
On 05/02/2024 01:19, Tomas Härdin wrote:
[...]
Which entry in the table would the provided file correspond to? To me
it seems none of them fit. There's two fields, meaning two j2k
codestreams, in each corresponding essence element KLV packet (I think,
unless CP packets get reassembled somewhere e
Quoting Connor Worley (2024-02-15 06:44:38)
> This change decouples the frame dimensions from avctx, which is useful
> for DXV decoding, and fixes incorrect behavior in the existing
> implementation.
>
> Tested with `make fate THREADS=7` and
> `make fate THREADS=7 THREAD_TYPE=slice`.
>
> Signed-o
Quoting Gyan Doshi (2024-02-15 13:31:59)
> On 2024-02-15 04:17 pm, Anton Khirnov wrote:
> > Hi,
> > sorry for the delay, I've been busy fixing things for the release
> > Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
> >> On 2024-01-28 04:24 pm, Anton Khirnov wrote:
> a) it would me
Quoting J. Dekker (2024-02-13 08:34:25)
> Signed-off-by: J. Dekker
> ---
>
> These devices are fundamentally broken and usecases should be switched
> away from output devices in general. Discussion in the thread tended towards
> deprecation rather than immediate removal to give time for users to
On 2024-02-15 09:40 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-15 13:31:59)
On 2024-02-15 04:17 pm, Anton Khirnov wrote:
Hi,
sorry for the delay, I've been busy fixing things for the release
Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
On 2024-01-28 04:24 pm, Anton Khi
On Thu, Feb 15, 2024 at 07:20:32AM +0100, Anton Khirnov wrote:
> I remember wondering why was this not run as a FATE test.
the full reference file is > 100mb and the full test takes longer than the
full fate test.
This patchset makes it possibly to run random subsets of the test
so its a step tow
This together with adjusting the inclusion define allows for the
build to not fail with latest Vulkan-Headers that contain the
stabilized Vulkan AV1 decoding definitions.
Compilation fails currently as the AV1 header is getting included
via hwcontext_vulkan.h -> -> vulkan_core.h, which
finally in
Feb 15, 2024, 20:18 by jee...@gmail.com:
> This together with adjusting the inclusion define allows for the
> build to not fail with latest Vulkan-Headers that contain the
> stabilized Vulkan AV1 decoding definitions.
>
> Compilation fails currently as the AV1 header is getting included
> via hwco
On Mon, Feb 5, 2024 at 12:07 PM Michael Niedermayer
wrote:
> assuming atom.size is an arbitrary 64bit value
> then the value of FFMIN() is also 64bit but entries is unsigned 32bit,
> this truncation
> would allow setting entries to values outside whats expected from FFMIN()
> also we seem to disa
On Thu, 15 Feb 2024 at 16:48, Gyan Doshi wrote:
>
>
> On 2024-02-15 09:40 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2024-02-15 13:31:59)
> >> On 2024-02-15 04:17 pm, Anton Khirnov wrote:
> >>> Hi,
> >>> sorry for the delay, I've been busy fixing things for the release
> >>> Quoting Gyan Do
On Thu, 15 Feb 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-02-12 22:15:37)
- native order, and that a single channel only appears once was always assumed
for less than 64 channels, obviously this was incorrect
Could you add a test for the case where it's not true?
Actually f
On Thu, Feb 15, 2024 at 12:07:05PM -0800, Dale Curtis wrote:
> On Mon, Feb 5, 2024 at 12:07 PM Michael Niedermayer
> wrote:
>
> > assuming atom.size is an arbitrary 64bit value
> > then the value of FFMIN() is also 64bit but entries is unsigned 32bit,
> > this truncation
> > would allow setting e
On Thu, Feb 15, 2024 at 4:02 PM Jerome Martinez
wrote:
> In other words, I would like to know if AVFrame is intended at long term
> to handle also fields in addition to frames, and if so is there a way to
> signal that the AVFrame structure actually contains a field
>
I may be missing something
>
> I may be missing something from the previous discussion, but the
> AV_FRAME_FLAG_INTERLACED should indicate when that is the case.
> I am not familiar enough with j2k code to know if that flag is correctly
> set or not.
>
>
AV_FRAME_FLAG_INTERLACED signals two fields which are interleaved. What
On Tue, Feb 13, 2024 at 7:26 PM James Zern wrote:
>
> On Mon, Feb 12, 2024 at 10:34 PM Dariusz Marcinkiewicz via
> ffmpeg-devel wrote:
> >
> > This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
> >
> > Co-authored-by: Erik Språng
> > Signed-off-by: Dariusz Marcinkiewicz
> > ---
> >
On Fri, Jan 19, 2024 at 10:47:30PM -0300, James Almer wrote:
> Finishes fixing vp5/potter512-400-partial.avi
>
> The fate-matroska-ms-mode test ref is updated to reflect that the Speex
> decoder
> can now read the stream.
>
> Signed-off-by: James Almer
> ---
> libavcodec/speexdec.c |
On 2024-02-16 01:56 am, Kieran Kunhya wrote:
On Thu, 15 Feb 2024 at 16:48, Gyan Doshi wrote:
On 2024-02-15 09:40 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-15 13:31:59)
On 2024-02-15 04:17 pm, Anton Khirnov wrote:
Hi,
sorry for the delay, I've been busy fixing things for the r
On Thu, Feb 15, 2024 at 7:54 PM wrote:
> From: Frank Plowman
>
> The PPS should be used instead of the SPS to get the current picture's
> dimensions. Using the SPS can cause issues if the resolution changes
> mid-sequence. In particular, it was leading to invalid memory accesses
> if the resol
30 matches
Mail list logo
