> -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, wenbin.c...@
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
---
libavcodec/
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 the
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 needs
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 wants
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 file
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 possible
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 comm
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
--- a/libavcodec/pthread_frame.
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 d
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
--- a/libavcodec/pthread_frame.
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 settin
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
ff_frame_thread_fr
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
> --- a/l
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
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
> https://github.com/goog
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
> betw
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 @@
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 mtf_index
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 adpc
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 *avc
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
index
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
+++ b/libav
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
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 *avc
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 f154188b5d..8aab07e334 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -2124,6 +2124,7 @@ static void adpcm_flush(AVCodecContext *avc
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
--- a/libavformat/al
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. Th
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 abou
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
>
https://github.com/FFmpeg/FFmpeg/blob/maste
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 l
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
ffmpeg-devel-
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 cu
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 patches
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
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 func
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 publi
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 an
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, &packet);
AVStream *stream = streams[packet.stream_index];
That should work, right?
Regards,
--
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 cop
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, &packet);
AVStream *stream = streams[packet.stream_inde
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 of
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 a/libavformat/i
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
> 0001-lavc-mjpegdec-Decode-format-211121-as-
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 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 war
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: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 c
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:
> > 31000/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAV
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:
> > 31003/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-62562987714
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(+)
> > 092c
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 a/libavformat/internal
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 changed,
---
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 MOV_IN
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 cd9e32f443..8d9f
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.
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 deletions(-)
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 deletions
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
--- a/libavformat/sierravmd
> -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
> ---
> t
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
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
+
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?
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 @@
#defi
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 j
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 aa
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 Rheinh
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 read_
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 read_packet_gme(AVForm
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
+++ b/l
On Mon, 2021-03-22 at 20:12 +0800, Linjie Fu wrote:
> On Wed, Feb 24, 2021 at 9:44 AM Fei Wang
> wrote:
> >
> > The option allow user to set diffenent scaling mode from
> > auto/low-power/high-quality.
> >
> > More details:
> >
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasd
To Andreas Rheinhardt,
> Why is this not possible? I just told you how you could set
> max_dec_frame_buffering to a lower value. It seems you haven't tried it.
Ahh...I thought what you care about is the unsafety of directly modifing
num_reorder_frames and num_reorder_frames to a lower value.
We
73 matches
Mail list logo
