> > On Jul 24, 2023, at 10:41, hung kuishing
> wrote:
> >
> > Signed-off-by: clarkh
> > ---
> > libavformat/movenc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > index f1cc80b1b3..d08c056438 100644
> > ---
> On Jul 26, 2023, at 00:28, Raphaël Zumer wrote:
>
> Encoding PCM in MP4 currently causes subsequent decoding to fail due to a
> sample size of 0.
This doesn’t give a context on which case the sample size is 0.
> Use bits per coded sample instead, which are set correctly based on my tests
> On Jul 24, 2023, at 10:41, hung kuishing wrote:
>
> Signed-off-by: clarkh
> ---
> libavformat/movenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index f1cc80b1b3..d08c056438 100644
> --- a/libavformat/movenc.c
>
From: Zhao Zhili
---
tests/fate/mov.mak | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index d795445691..6cb493ceab 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -17,6 +17,7 @@ FATE_MOV = fate-mov-3elist \
From: Zhao Zhili
bits_per_raw_sample might not set when remux raw PCM.
Fix #10433.
---
libavformat/movenc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index f1cc80b1b3..7ef6cef46a 100644
--- a/libavformat/movenc.c
+++
On Tue, Jul 25, 2023 at 12:47:12AM +0200, Lynne wrote:
> Jul 25, 2023, 00:19 by andreas.rheinha...@outlook.com:
>
> > Lynne:
> >
> >> Subject: [PATCH 2/2] lavc/avfft: deprecate the API
> >>
> >> This deprecates the currently unused API.
> >>
> > ^
> > superseded
> >
> >> ---
> >> doc/APIchanges
On Tue, Jul 25, 2023 at 02:05:43PM +0200, J. Dekker wrote:
>
> Hi Devin,
>
> Devin Heitmueller writes:
> > On Fri, Jul 21, 2023 at 9:38 AM J. Dekker wrote:
> >
> > I appreciate the value of stats so I can tell that the stream had
> > errors, but how is this side data "helpful to a renderer
A POLLERR occurs when libavcodec attempts to dequeue output buffers
before enqueuing capture buffers. This could happen to an application
deciding to send the first coded packet. Suppress these POLLERRs when
the buffers are uninitialized.
See https://trac.ffmpeg.org/ticket/9957 for the original
On 7/25/2023 6:03 PM, Michael Niedermayer wrote:
On Mon, Jul 24, 2023 at 10:54:20PM -0300, James Almer wrote:
On 7/24/2023 9:46 PM, Michael Niedermayer wrote:
Fixes: division by zero
Fixes:
60306/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5538913553612800
Found-by:
On Mon, Jul 24, 2023 at 10:54:20PM -0300, James Almer wrote:
> On 7/24/2023 9:46 PM, Michael Niedermayer wrote:
> > Fixes: division by zero
> > Fixes:
> > 60306/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5538913553612800
> >
> > Found-by: continuous fuzzing process
> >
On Mon, Jul 24, 2023 at 11:28:20PM -0300, James Almer wrote:
> On 7/24/2023 9:46 PM, Michael Niedermayer wrote:
> > The unchecked read caused the 2nd subsequent tell call to move backward
> > resulting
> > in a negative length
> >
> > Fixes: assertion failure
> > Fixes:
> >
On Mon, Jul 24, 2023 at 09:35:22PM -0700, Pierre-Anthony Lemieux wrote:
> LGTM.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
signature.asc
Description: PGP
On Tue, Jul 25, 2023 at 1:58 AM Thilo Borgmann wrote:
>
> Still images fixed from v2. Now includes a fate test for animated webp.
>
> Patch 5/7 is still there for making changes in lavc/webp reviewable but
> shall be stashed when pushing.
>
> -Thilo
>
>
> Josef Zlomek (2):
> libavcodec/webp:
On Tue, Jul 25, 2023 at 7:18 AM Thilo Borgmann wrote:
>
> Am 25.07.23 um 14:24 schrieb Tomas Härdin:
> >> +// Extremely simplified key frame detection:
> >> +// - the first frame (containing headers) is marked as a key
> >> frame
> >> +// - other frames are marked as non-key frames
>
Thanks for the reply; I wasn't looking to merge the RFC as-is, but rather to
figure out the preferred approach, and most importantly make sure that there is
no fundamental disagreement on suppressing codec-level metadata in situations
where it conflicts with format-level.
I will see which of
Mostly done to be able to update the comment so that it no longer
mentions the same flag twice.
---
libavcodec/hevcdec.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 1fe91238d4..15276edd33 100644
---
This allows this common H.274 SEI to be parsed from both H.264
as well as HEVC, as well as probably from VVC in the future.
Generally attempts to keep the original code as similar as possible.
FATE test refererence changes only change the order of side data
export within a single frame. Nothing
This allows this common H.274 SEI to be parsed from both H.264
as well as HEVC, as well as probably from VVC in the future.
Generally attempts to keep the original code as similar as possible.
FATE test refererence changes only change the order of side data
export within a single frame. Nothing
This allows parsing code to be re-utilized from H.264, as well as probably
from VVC in the future.
This additionally eases verification of the AVCodecContext side data patch
set, which includes libx264 integration for HDR10 side data.
Changes from v1:
* Reordered the new h2645_sei include to
Quoting Vittorio Giovara
>
> Any comments on this patch? If no objections I'd like to push it at the end
> of the week
Sorry, not acceptable. This is the wrong place to do it.
AVCodecParameters is a dumb container for parameters. It MUST NOT make
any assumptions about who calls it or for what
On Sat, Jul 15, 2023 at 4:51 PM Raphaël Zumer
wrote:
> Hello,
>
> Tagging this as RFC in case there is disagreement on the correct/desired
> behavior.
>
> For context:
> I am working with spatial audio and noticed that FFmpeg does not honor the
> SA3D box metadata, which is used to signal
Signed-off-by: James Almer
---
Now inserting a filter into the graph.
fftools/ffmpeg.h| 3 +++
fftools/ffmpeg_demux.c | 6 ++
fftools/ffmpeg_enc.c| 19 +++
fftools/ffmpeg_filter.c | 22 ++
fftools/ffmpeg_opt.c| 3 +++
5 files changed,
Hello,
On 7/25/2023 12:21 PM, hung kuishing wrote:
> Signed-off-by: clarkh
> ---
> libavcodec/Makefile| 1 +
> libavcodec/parsers.c | 1 +
> libavcodec/prores_parser.c | 107 +
> libavformat/Makefile | 2 +
> libavformat/allformats.c
Encoding PCM in MP4 currently causes subsequent decoding to fail due to a
sample size of 0.
Use bits per coded sample instead, which are set correctly based on my tests
and allow muxed files to be decoded as expected.
Note: PCM in MP4 muxed with versions of FFmpeg 6.0 and prior (before
On Tue, Jul 25, 2023 at 2:56 PM Nicolas George wrote:
> If you would rather FFmpeg be a perfect pearl of beautiful design
> developed in an ivory tower with no regards for the satisfaction of
> users…
You can have satisified users without having to implement SDR in a
multimedia library, nor xml
Am 25.07.23 um 14:24 schrieb Tomas Härdin:
+ // Extremely simplified key frame detection:
+ // - the first frame (containing headers) is marked as a key
frame
+ // - other frames are marked as non-key frames
Is there a more proper way of doing this?
All frames (except the ANMF
mån 2023-07-24 klockan 00:56 +0200 skrev Michael Niedermayer:
> And here comes the 3rd step, connect libavfilter to libavradio, move
> the components
> into libavfilter. Do demodulation and probing in filters.
Paul already said no to this
> filters will not need to deal with mpeg-ts or AAC
Kieran Kunhya (12023-07-25):
> As we have seen in FFmpeg, APIs are "designed" around basic things
> like AVI and hacks upon hacks are needed to support anything more
> complex. The API being written around AM/FM is history clearly
> repeating itself.
>
> Unlike you, quite a lot of people are able
tis 2023-07-25 klockan 12:40 + skrev hung kuishing:
> Hi, width and height use u(16) descriptor in prores specification,
> and spec does not limit scope,
> I guess 1~65535 are allowable. So I think I'll change it to check if
> they are equal to 0.
> What do you propose?
If the spec says any
Hi, width and height use u(16) descriptor in prores specification, and spec
does not limit scope,
I guess 1~65535 are allowable. So I think I'll change it to check if they are
equal to 0.
What do you propose?
-邮件原件-
发件人: ffmpeg-devel 代表 Tomas H?rdin
发送时间: 2023年7月25日 19:48
收件人: FFmpeg
> + // Extremely simplified key frame detection:
> + // - the first frame (containing headers) is marked as a key
> frame
> + // - other frames are marked as non-key frames
Is there a more proper way of doing this? Looking briefly at the spec
one wonders why they didn't just use regular
Hi Devin,
Devin Heitmueller writes:
> On Fri, Jul 21, 2023 at 9:38 AM J. Dekker wrote:
>
> I appreciate the value of stats so I can tell that the stream had
> errors, but how is this side data "helpful to a renderer attempting to
> filter or conceal video decoding errors and artifacts" if
tis 2023-07-25 klockan 11:56 +0200 skrev Nicolas George:
> Kieran Kunhya (12023-07-25):
> > This is a completely incorrect and poorly thought through
> > statement.
> > AM/FM are a microscopically small subset of SDR.
> > SDR is a massively complex field, bigger than multimedia itself.
> > There
>
> +static int prores_check_frame_header(const uint8_t *buf, const int
> data_size)
> +{
> + int hdr_size, width, height;
> + int version, alpha_info;
> +
> + hdr_size = AV_RB16(buf);
> + if (hdr_size < FRAME_FIXED_HEADER_SIZE)
> + return AVERROR_INVALIDDATA;
> +
> + version =
On Sun, 23 Jul 2023 17:04:55 -0300, you wrote:
>On 7/23/2023 4:40 PM, Paul B Mahol wrote:
>> On Sun, Jul 23, 2023 at 9:26?PM Nicolas George wrote:
>>
>>> James Almer (12023-07-23):
What about when FF_FILTER_FLAG_HWFRAME_AWARE filters are present in the
graph? hw_frames_ctx from
Signed-off-by: clarkh
---
libavcodec/Makefile| 1 +
libavcodec/parsers.c | 1 +
libavcodec/prores_parser.c | 107 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/proresdec.c| 66
Add a callback to enable user allocation of video frames on the final
stage of a filter chain.
Signed-off-by: John Cox
---
libavfilter/buffersink.c | 38 ++
libavfilter/buffersink.h | 51
libavfilter/version.h| 2 +-
3
This patch adds the ability for the user to allocate frames rather than
being forced to use avfilters default allocator.
This useful for applications like Kodi that wish to be able to control
how the final filter stage frame is allocated so that it is compatible
with whatever it wishes to do next
Signed-off-by: Sven Martinov
---
libavcodec/hevcdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index fcf19b4..1ec382e 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -338,6 +338,7 @@ static void
On Tue, Jul 25, 2023 at 10:56 AM Nicolas George wrote:
>
> Kieran Kunhya (12023-07-25):
> > This is a completely incorrect and poorly thought through statement.
> > AM/FM are a microscopically small subset of SDR.
> > SDR is a massively complex field, bigger than multimedia itself. There
> > are
Kieran Kunhya (12023-07-25):
> This is a completely incorrect and poorly thought through statement.
> AM/FM are a microscopically small subset of SDR.
> SDR is a massively complex field, bigger than multimedia itself. There
> are permutations and complexity in things like DAB/DVB etc much more
>
> But far from “already seeing evidence” of the apocalypse you predict, we
> see that the avradio code already delivers features while being
> self-contained and only required extending the signal processing
> abilities of our libraries a little, and in ways that are useful to
> other developers.
Required for DCT-I and DST-I.
Patch attached.
>From 2e95c3a7128b7f826db8394eb238c5405c47864b Mon Sep 17 00:00:00 2001
From: Lynne
Date: Tue, 25 Jul 2023 10:57:21 +0200
Subject: [PATCH 2/2] lavu/tx: add a half-complex R2C transform
Required for DCT-I and DST-I.
---
doc/APIchanges | 3
They're presently broken, and not really needed anywhere.
They can be fixed at a later date, but for
Patch attached.
>From 01925c08bcd2073770c0c627fc64232a7593a321 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Tue, 25 Jul 2023 11:01:41 +0200
Subject: [PATCH 1/2] lavu/tx: disable odd-length RDFTs
Hello Everyone,
I am trying to build ffmpeg for the xilinx microblaze processor, using the
microblaze xilinx SDK toolchain. The microblaze will host petalinux.
What should be the --arch= ? option while running the ./configure command
for microblaze processor in ffmpeg configuration? When I
Tomas Härdin (12023-07-24):
> Such libraries already exist. Libraries that need talented developers
> working on them. Something that I have already suggested, but it
> appears to be falling on deaf ears. Which is a shame.
>
> GNU Radio Companion can be used to generate Python code that does
>
Tomas Härdin (12023-07-24):
> Features either are or aren't in scope. I don't see how you can
> compromise on that.
The scope is what we decide it is, collectively, based on arguments.
Your conception of the scope is only a small part of that, and even
smaller if you cannot sustain it with
Am 24.07.23 um 22:44 schrieb James Zern:
On Thu, Jul 20, 2023 at 4:08 PM Thilo Borgmann wrote:
All issues of v2 fixed. Makes tsan happy now as well.
Patch 5/6 is still there for making changes in lavc/webp reviewable but
shall be stashed when pushing.
This looks to fail fate:
---
tests/fate/image.mak | 3 +++
tests/ref/fate/webp-anim | 22 ++
2 files changed, 25 insertions(+)
create mode 100644 tests/ref/fate/webp-anim
diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 400199c28a..2e0d1e8e3f 100644
--- a/tests/fate/image.mak
+++
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the
---
libavcodec/webp.c | 143 +++---
1 file changed, 71 insertions(+), 72 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 773ac171e6..83e1ed6778 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1351,7 +1351,77 @@ static int
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
---
libavcodec/webp_parser.c | 130 +++
1 file changed, 89 insertions(+), 41 deletions(-)
diff --git a/libavcodec/webp_parser.c b/libavcodec/webp_parser.c
index bd5f94dac5..da853bb1f5 100644
--- a/libavcodec/webp_parser.c
+++ b/libavcodec/webp_parser.c
@@
---
libavcodec/webp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index b0475c344a..6ba81a6a99 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -60,8 +60,6 @@
#define VP8X_FLAG_ALPHA 0x10
#define VP8X_FLAG_ICC
---
libavcodec/webp.c | 1 +
libavcodec/webp.h | 38 ++
2 files changed, 39 insertions(+)
create mode 100644 libavcodec/webp.h
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index d35cb66f8d..b0475c344a 100644
--- a/libavcodec/webp.c
+++
Still images fixed from v2. Now includes a fate test for animated webp.
Patch 5/7 is still there for making changes in lavc/webp reviewable but
shall be stashed when pushing.
-Thilo
Josef Zlomek (2):
libavcodec/webp: add support for animated WebP decoding
libavformat/webp: add WebP demuxer
On Tue, 25 Jul 2023, Lynne wrote:
I think, however, the process has become rather opaque in this case.
Usually, there has to be a clear writeup of the issue, with all context
removed, that all parties have to agree on is presentable to the TC
for guidelines. In the past, whenever developers
Hi,
Sorry, I totally missed the last version. I'll see if I can dig it out of the
archives or patchwork.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On Mon, Jul 24, 2023 at 8:46 PM Tomas Härdin wrote:
> mån 2023-07-24 klockan 10:57 +0200 skrev Paul B Mahol:
> > On Mon, Jul 24, 2023 at 10:34 AM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> > > Michael Niedermayer:
> > > > On Sat, Jun 17, 2023 at 12:20:44AM +0200,
59 matches
Mail list logo
