Signed-off-by: Andreas Rheinhardt
---
libavformat/libmodplug.c | 37 -
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/libavformat/libmodplug.c b/libavformat/libmodplug.c
index 6e567f5f98..b85269341b 100644
--- a/libavformat/libmodplug.c
+++
Signed-off-by: Andreas Rheinhardt
---
libavformat/libgme.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/libgme.c b/libavformat/libgme.c
index ad59971fcd..a9c487bdb4 100644
--- a/libavformat/libgme.c
+++ b/libavformat/libgme.c
@@ -166,7 +166,6 @@ static int
Signed-off-by: Andreas Rheinhardt
---
libavformat/libgme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/libgme.c b/libavformat/libgme.c
index f9d9abaad5..ad59971fcd 100644
--- a/libavformat/libgme.c
+++ b/libavformat/libgme.c
@@ -142,7 +142,7 @@ static int
Also free the gme_info_t structure immediately after its use.
This simplifies cleanup, because it might be unsafe to call
gme_free_info(NULL) (or even worse, gme_track_info() might even
on error set the pointer to the gme_info_t structure to something
else than NULL).
Signed-off-by: Andreas
Signed-off-by: Andreas Rheinhardt
---
libavformat/aadec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/aadec.c b/libavformat/aadec.c
index 80ca2c12d7..2575e98153 100644
--- a/libavformat/aadec.c
+++ b/libavformat/aadec.c
@@ -229,8 +229,11 @@ static int
Signed-off-by: Andreas Rheinhardt
---
libavformat/jacosubdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/jacosubdec.c b/libavformat/jacosubdec.c
index b44e3b7783..828c33057f 100644
--- a/libavformat/jacosubdec.c
+++ b/libavformat/jacosubdec.c
@@ -199,6 +199,7 @@ static int
On 2021-03-24 03:38, Andrey Rikunov wrote:
---
libavformat/movenc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index cdbc407..8a152c0 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -29,7 +29,7 @@
On 2021-03-24 08:17, Li Jinyao wrote:
The patches for the custom feature are in a private cvs, it's about 400+
commits. I tried to link against 4.3.1, found about 10 functions are missing.
If it hard to add tone map back, maybe patch these feature to a newer ffmpeg
version is more feasible?
This removes the only use of st->codec in compute_muxer_pkt_fields()
Signed-off-by: James Almer
---
libavformat/mux.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index e98b86a81e..5d907cfaee 100644
--- a/libavformat/mux.c
The patches for the custom feature are in a private cvs, it's about 400+
commits. I tried to link against 4.3.1, found about 10 functions are missing.
If it hard to add tone map back, maybe patch these feature to a newer ffmpeg
version is more feasible?
Li Jinyao
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Wenlong Ding
> Sent: 2021年3月22日 16:20
> To: ffmpeg-devel@ffmpeg.org
> Cc: Ding, Wenlong
> Subject: [FFmpeg-devel] [PATCH 2/2] tests/dnn/dnn-layer-mathunary-test: add
> unit test for exp
>
> Signed-off-by: Wenlong Ding
> ---
>
Also remove keyframe from vmd_frame, it is unused.
Signed-off-by: Andreas Rheinhardt
---
libavformat/sierravmd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/sierravmd.c b/libavformat/sierravmd.c
index 11a883614f..cfbf1843d4 100644
---
The check has been added at a time when the code performed the
multiplication itself instead of deferring it to av_malloc_array()
and when our allocation functions used unsigned instead of size_t.
Signed-off-by: Andreas Rheinhardt
---
libavformat/sierravmd.c | 4
1 file changed, 4
The check has been added at a time when the code performed the
multiplication itself instead of deferring it to av_malloc_array()
and when our allocation functions used unsigned instead of size_t.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilm.c | 2 --
1 file changed, 2
This check is outdated because the caller doesn't need to check that
the multiplication overflows when using av_realloc_array() (the code
in question used av_realloc() before that); furthermore, the check
is also a remnant of the time in which our allocation functions
didn't use size_t parameters.
Andreas Rheinhardt:
> Fixes decoding of https://samples.ffmpeg.org/V-codecs/KMVC/LOGO2.AVI
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/kmvc.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
> index
---
libavformat/movenc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index cdbc407..8a152c0 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -29,7 +29,7 @@
#define MOV_FRAG_INFO_ALLOC_INCREMENT 64
#define
On 3/23/2021 6:29 PM, Alok Priyadarshi wrote:
This produces true wallclock time at rtp source instead of the
local wallclock time at rtp client.
---
libavformat/internal.h | 8
libavformat/rtpdec.c | 20
libavformat/utils.c| 9 +
3 files
This produces true wallclock time at rtp source instead of the
local wallclock time at rtp client.
---
libavformat/internal.h | 8
libavformat/rtpdec.c | 20
libavformat/utils.c| 9 +
3 files changed, 37 insertions(+)
diff --git
Am Di., 23. März 2021 um 21:00 Uhr schrieb Michael Niedermayer
:
>
> On Sun, Mar 21, 2021 at 01:39:28AM +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes ticket #8930 for me.
> >
> > Please comment, Carl Eugen
>
> > mjpegdec.c |1 +
> > 1 file changed, 1 insertion(+)
> >
On Tue, Mar 23, 2021 at 02:09:55PM +0100, Nicolas George wrote:
> Michael Niedermayer (12021-03-06):
> > Fixes: signed integer overflow: 9223372036854775807 + 864 cannot be
> > represented in type 'long'
> > Fixes:
> >
On Tue, Mar 23, 2021 at 02:09:22PM +0100, Nicolas George wrote:
> Michael Niedermayer (12021-03-06):
> > Fixes: signed integer overflow: 2314885530818453536 - -9070214327174160352
> > cannot be represented in type 'long'
> > Fixes:
> >
On 3/23/2021 4:52 PM, Alok Priyadarshi wrote:
This produces true wallclock time at rtp source instead of the
local wallclock time at rtp client.
---
libavformat/internal.h | 8
libavformat/rtpdec.c | 27 +++
libavformat/utils.c| 9 +
3 files
Signed-off-by: James Almer
---
Changes since v1:
idx is now unsigned.
The functions now allocate an AVIndexEntry the user must free, so
sizeof(AVIndexEntry) is not tied to the ABI.
libavformat/avformat.h | 41
libavformat/utils.c| 43
On 3/23/2021 4:40 PM, Nicolas George wrote:
James Almer (12021-03-23):
I recall many people have said before that just because it was done before
doesn't mean it should be done again. That's how bad practices spread.
I will happily concede you this. All the more happily that I will keep
it
James,
Thanks for reviewing the patch. I have addressed your comments in the new
patch.
You are right - the use case is remuxing in particular rtsp stream to
fragmented mp4 using the following command:
ffmpeg -i -c copy -movflags
frag_keyframe+empty_moov+default_base_moof -write_prft wallclock
On Sun, Mar 21, 2021 at 01:39:28AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #8930 for me.
>
> Please comment, Carl Eugen
> mjpegdec.c |1 +
> 1 file changed, 1 insertion(+)
> 092c45ecc5789ce34c9f905ce55d7c573f39fce5
>
This produces true wallclock time at rtp source instead of the
local wallclock time at rtp client.
---
libavformat/internal.h | 8
libavformat/rtpdec.c | 27 +++
libavformat/utils.c| 9 +
3 files changed, 44 insertions(+)
diff --git
James Almer (12021-03-23):
> I recall many people have said before that just because it was done before
> doesn't mean it should be done again. That's how bad practices spread.
I will happily concede you this. All the more happily that I will keep
it warm to serve it back when you oppose to one
On 3/23/2021 4:11 PM, Nicolas George wrote:
Nicolas George (12021-03-23):
And it is exactly what we are doing when we let users access fields
directly.
I mean:
AVStream **streams = ctx->streams;
av_read_frame(ctx, );
AVStream *stream = streams[packet.stream_index];
On 3/23/2021 4:07 PM, Nicolas George wrote:
James Almer (12021-03-23):
I really don't like the idea of returning a pointer to some offset within an
internal struct that may either start pointing at some other entry or even
to freed memory, especially when the alternative of giving the user a
Nicolas George (12021-03-23):
> And it is exactly what we are doing when we let users access fields
> directly.
I mean:
AVStream **streams = ctx->streams;
av_read_frame(ctx, );
AVStream *stream = streams[packet.stream_index];
That should work, right?
Regards,
--
James Almer (12021-03-23):
> I really don't like the idea of returning a pointer to some offset within an
> internal struct that may either start pointing at some other entry or even
> to freed memory, especially when the alternative of giving the user a copy
> of a single entry is trivial to do
On 3/23/2021 3:47 PM, Nicolas George wrote:
James Almer (12021-03-23):
Signed-off-by: James Almer
---
Following "lavf: move AVStream.*index_entries* to AVStreamInternal", it was
revealed that some library users apparently found these fields useful and were
accessing them despite not being
James Almer (12021-03-23):
> Signed-off-by: James Almer
> ---
> Following "lavf: move AVStream.*index_entries* to AVStreamInternal", it was
> revealed that some library users apparently found these fields useful and were
> accessing them despite not being public.
> This patch introduces a few
Signed-off-by: James Almer
---
Following "lavf: move AVStream.*index_entries* to AVStreamInternal", it was
revealed that some library users apparently found these fields useful and were
accessing them despite not being public.
This patch introduces a few functions to recover this functionality in
On Tue, Mar 23, 2021 at 7:32 AM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:
> Do you agree with my definition or not? And which code are you referring
> to - the master branch or my patches?
>
Just do not introduce regressions into existing code.
>
> I'd like to get these
Am Di., 23. März 2021 um 15:44 Uhr schrieb Li Jinyao :
> I was working on a project with ffmpeg 3.2.7 libraries, and I need use
> tonemap filter to do a HDR to SDR convert, but tonemap is not implemented
> in 3.2.7. The ffmpeg libraries used by the project had been modified a lot,
> added some
ping again, would rather not have to maintain this and the
logical_processor patch out of tree
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On 3/22/2021 11:51 AM, James Almer wrote:
On 3/22/2021 11:48 AM, James Almer wrote:
This reverts commit cea7c19cda0ea1630ae1de8c102ab14231b9db10.
Until an API is added to make index_entries public in a proper way, we
should
keep this here.
Signed-off-by: James Almer
---
Some library users
Hi,
On Tue, 23 Mar 2021 at 16:01, Alireza Heidar-Barghi <
arhdr-at-yahoo@ffmpeg.org> wrote:
> Hello,
> I am wondering how I can obtain documentation on the detail of FFmpeg's
> threading architecture?
> Thank you in advance.
> Regards,
> Alireza
>
Hello,
I am wondering how I can obtain documentation on the detail of FFmpeg's
threading architecture?
Thank you in advance.
Regards,
Alireza
- Forwarded Message - From: Alireza Heidar-Barghi
To: r...@ffmpeg.org Sent: Monday, March 22,
2021, 03:19:51 PM EDTSubject: Fw: Question
Hi
I was working on a project with ffmpeg 3.2.7 libraries, and I need use tonemap
filter to do a HDR to SDR convert, but tonemap is not implemented in 3.2.7. The
ffmpeg libraries used by the project had been modified a lot, added some custom
business feature, so It’s hard to upgrade ffmpeg.
Allows "ffplay -loop" to work.
Signed-off-by: Zane van Iperen
---
libavformat/alp.c | 50 ++-
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git a/libavformat/alp.c b/libavformat/alp.c
index f2b0c37730..222cc246a2 100644
---
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index f154188b5d..8aab07e334 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -2124,6 +2124,7 @@ static void adpcm_flush(AVCodecContext
Allows "ffplay -loop" to work.
Signed-off-by: Zane van Iperen
---
libavformat/kvag.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavformat/kvag.c b/libavformat/kvag.c
index 8f641873b9..91d1d8a518 100644
--- a/libavformat/kvag.c
+++ b/libavformat/kvag.c
@@
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index e31f68b076..f154188b5d 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -2123,6 +2123,7 @@ static void adpcm_flush(AVCodecContext
Signed-off-by: Zane van Iperen
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3b6cfad4fc..ed8eddb317 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,6 +138,7 @@ Codecs:
8bps.cRoberto Togni
8svx.c
Allows "ffplay -loop" to work.
Signed-off-by: Zane van Iperen
---
libavformat/pp_bnk.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/libavformat/pp_bnk.c b/libavformat/pp_bnk.c
index 5c89295d27..07eeca3cd5 100644
--- a/libavformat/pp_bnk.c
+++
Commit 003b5c800fef909fa84dd2fae43d66bd434d3f7e introduced seeking in argo_asf,
but this was missed, leading to non-deterministic output.
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 07fa1a65b3..e31f68b076 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -2123,6 +2123,7 @@ static void adpcm_flush(AVCodecContext
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index b145622f4f..b035406550 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -1811,11 +1811,6 @@ static int
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 5b6d1040af..5c28b745b9 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -100,7 +100,7 @@ static const int8_t
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 5c28b745b9..b145622f4f 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -2077,13 +2077,6 @@
Andreas Rheinhardt:
> Up until now, initializing the mutexes/condition variables wasn't
> checked by ff_frame_thread_init(). This commit changes this.
>
> Given that it is not documented to be save to destroy a zeroed but
> otherwise uninitialized mutex/condition variable, one has to choose
>
Michael Niedermayer (12021-03-06):
> Fixes: signed integer overflow: 9223372036854775807 + 864 cannot be
> represented in type 'long'
> Fixes:
> 31003/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-6256298771480576
>
> Found-by: continuous fuzzing process
>
Michael Niedermayer (12021-03-06):
> Fixes: signed integer overflow: 2314885530818453536 - -9070214327174160352
> cannot be represented in type 'long'
> Fixes:
> 31000/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-6558389742206976
>
> Found-by: continuous fuzzing process
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/avcodec.c | 48 +++-
> 1 file changed, 25 insertions(+), 23 deletions(-)
>
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index 2f3896dcc4..3088d2ff3f 100644
> ---
In case an error happened when setting up the child threads,
ff_frame_thread_init() would up until now call ff_frame_thread_free()
to clean up all threads set up so far, including the current, not
properly initialized one.
But a half-allocated context needs special handling which
Nuo Mi:
> On Fri, Feb 12, 2021 at 12:06 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Up until now, ff_frame_thread_init had several bugs:
>> 1. It did not check whether the condition and mutexes
>>could be successfully created.
>> 2. In case an error happened when
Signed-off-by: Andreas Rheinhardt
---
libavcodec/pthread_frame.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 1c17d8c3b6..ad3eba9016 100644
---
Up until now, initializing the mutexes/condition variables wasn't
checked by ff_frame_thread_init(). This commit changes this.
Given that it is not documented to be save to destroy a zeroed but
otherwise uninitialized mutex/condition variable, one has to choose
between two approaches: Either one
Signed-off-by: Andreas Rheinhardt
---
libavcodec/pthread_frame.c | 127 -
1 file changed, 68 insertions(+), 59 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 7bcb9a7bcc..311d6ed771 100644
---
I was using the public API to encode test data from softwaretest signal
generators when I came across the FIXME in latmenc.c. Thespecifications I
reference regularly gives approximately 25% of the informationrequired to do
the fix (i.e. 1 out of 4use cases). The attached patch updates the
sharp...@gmail.com:
> To Andreas Rheinhardt,
>
>> What does "will not accept a smaller value (such as 0)" mean?
>
> As your said, the max_dec_frame_buffering is limited to 16. Set
> it to 0 (on condition that we do know there is no reordered frames)
> is not possible.
>
Why is this not
To Andreas Rheinhardt,
> What does "will not accept a smaller value (such as 0)" mean?
As your said, the max_dec_frame_buffering is limited to 16. Set
it to 0 (on condition that we do know there is no reordered frames)
is not possible.
> Does it error out?
It is safe and will not break any
sharp...@gmail.com:
> To Andreas Rheinhardt,
>
>> This is wrong. Instead you should make the SPS that you are modifying
>> writable and update it. (The h264_metadata bsf uses separate
>> CodedBitstreamContexts for input and output and the SPS is normally
>> shared between them, so if someone
To Andreas Rheinhardt,
> This is wrong. Instead you should make the SPS that you are modifying
> writable and update it. (The h264_metadata bsf uses separate
> CodedBitstreamContexts for input and output and the SPS is normally
> shared between them, so if someone wants to modify a field one
From: "Chen,Wenbin"
qsvvpp align the width and height with 16, and that may lead to error.
For example, when we use qsvvpp to resize frame to 1080p, qsvvpp will
align frame to 1088 which is different from the height of
encoder (1080) and this will be treated as resolution change. Now I
assign
From: "Chen,Wenbin"
FFmpeg-qsv decoder reinit codec when width and height change, but there
are not only resolution change need to reinit codec. I change it to use
return value from DecodeFrameAsync() to decide whether decoder need to
be reinitialized.
Signed-off-by Wenbin Chen
---
> -Original Message-
> From: Xiang, Haihao
> Sent: Tuesday, March 23, 2021 1:44 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Chen, Wenbin
> Subject: Re: [FFmpeg-devel] [PATCH] libavfilter/qsvvpp: change the output
> frame's width and height
>
> On Mon, 2021-03-22 at 14:43 +0800,
> -Original Message-
> From: Xiang, Haihao
> Sent: Tuesday, March 23, 2021 12:10 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Chen, Wenbin
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec: use the param from
> decodeHeader to configure surface
>
> On Mon, 2021-03-22 at 14:31 +0800,
Do you agree with my definition or not? And which code are you referring to
- the master branch or my patches?
I'd like to get these patches to a point where they can be applied, but
it's going to be difficult if we can't agree on the goal.
On Tue, Mar 23, 2021 at 5:15 PM Paul B Mahol wrote:
>
> -Original Message-
> From: Xiang, Haihao
> Sent: Tuesday, March 23, 2021 11:49 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Chen, Wenbin
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec: reinit decoder
> according to decode() return value
>
> On Mon, 2021-03-22 at 14:27 +0800,
On Tue, Mar 23, 2021 at 5:00 AM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:
> What exactly is your definition of fisheye?
>
Take look at source code. I do not see how your definition matches one in
source code.
>
> The definition I'm working with is the equidistant fisheye
75 matches
Mail list logo
