p...@sandflow.com:
> From: Pierre-Anthony Lemieux
>
> Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299685.html
>
> ---
> libavformat/avformat.c | 68
> libavformat/fifo.c | 8 ++---
> libavformat/internal.h | 12 +++
> li
Andreas Rheinhardt:
> These buffers are not shared in any way.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/error_resilience.c | 18 +-
> libavcodec/error_resilience.h | 4 ++--
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/error_r
Fixes Coverity issues #1442912, #1442913, #1442916 and #1442917.
Signed-off-by: Andreas Rheinhardt
---
Given that hevc_ps.c checks these values, it is actually impossible
for this error to be triggered.
libavcodec/nvdec_hevc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
On 06.08.2022 08:01, Andreas Rheinhardt wrote:
Fixes Coverity issues #1442912, #1442913, #1442916 and #1442917.
Signed-off-by: Andreas Rheinhardt
---
Given that hevc_ps.c checks these values, it is actually impossible
for this error to be triggered.
libavcodec/nvdec_hevc.c | 4 ++--
1 file
The fLaC and dfLa box IDs have been registered with the MP4 RA
(they are now listed at https://mp4ra.org/#/codecs) and support
for muxing FLAC in MP4 has been experimental in ffmpeg for
6 years now, since Nov 21, 2016
This patch removes the experimental status and removes the MP4
object type, as n
There are currently three possible modes for an output stream:
1) The stream is produced by encoding output from some filtergraph. This
is true when ost->enc_ctx != NULL, or equivalently when
ost->encoding_needed != 0.
2) The stream is produced by copying some input stream's packets. This
Michael Niedermayer (12022-08-04):
> I suspect several filters are somewhat "wrong"
> for example hflip fliping 4:1:1
> would turn a: *--- into ---*
> where * is teh chroma sample location, i dont think it updates the chroma
> sample location metadata nor does it apply some filter to chroma to sh
It's not modified, so we can simply use a const pointer to it.
Also check the return value of the other copy in the function while at it.
Signed-off-by: James Almer
---
libavfilter/avfiltergraph.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavfilter/avf
James Almer (12022-08-05):
> It's not modified, so we can simply use a const pointer to it.
> Also check the return value of the other copy in the function while at it.
>
> Signed-off-by: James Almer
> ---
> libavfilter/avfiltergraph.c | 15 ---
> 1 file changed, 8 insertions(+), 7 d
rcombs:
> This is fully backwards-compatible in both ABI and API,
> so it's only a minor bump.
It is not fully backwards-compatible API-wise: If you use a function
pointer for swr_alloc_set_opts2 by hardcoding its type, you will get
warnings now (or even errors depending upon your -Werror; it is a
Quoting Fu, Ting (2022-08-05 05:34:30)
> Hi Anton,
>
> Thank you for comment.
> After double checked the OpenVINO, it is true that the code would corrupt if
> the binary file does not exist.
Can you be more specific about what do you mean by "corrupt"?
> We would have nothing to do in this cas
Quoting Andreas Rheinhardt (2022-08-06 13:50:37)
> rcombs:
> > This is fully backwards-compatible in both ABI and API,
> > so it's only a minor bump.
>
> It is not fully backwards-compatible API-wise: If you use a function
> pointer for swr_alloc_set_opts2 by hardcoding its type, you will get
> wa
Quoting Anton Khirnov (2022-08-06 15:15:58)
> Quoting Andreas Rheinhardt (2022-08-06 13:50:37)
> > rcombs:
> > > This is fully backwards-compatible in both ABI and API,
> > > so it's only a minor bump.
> >
> > It is not fully backwards-compatible API-wise: If you use a function
> > pointer for swr
Quoting Martijn van Beurden (2022-08-06 10:39:42)
> The fLaC and dfLa box IDs have been registered with the MP4 RA
> (they are now listed at https://mp4ra.org/#/codecs) and support
> for muxing FLAC in MP4 has been experimental in ffmpeg for
> 6 years now, since Nov 21, 2016
>
> This patch removes
Quoting Zhao Zhili (2022-08-04 12:48:48)
> From: Zhao Zhili
>
> Signed-off-by: Zhao Zhili
> ---
> libavutil/hwcontext_videotoolbox.h | 1 +
> 1 file changed, 1 insertion(+)
Looks ok.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
The NLQ pivots are not documented but should be present
in the header for profile 7 RPU format.
It has been verified using Dolby's verification toolkit.
With the pivots parsed, the parsed values for
num_{x,y}_partitions are correct and usually equal to 1.
v3: https://ffmpeg.org/pipermail/ffmpeg-d
The NLQ pivots are not documented but should be present
in the header for profile 7 RPU format.
It has been verified using Dolby's verification toolkit.
Signed-off-by: quietvoid
---
libavcodec/dovi_rpu.c | 9 -
libavutil/dovi_meta.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
Signed-off-by: quietvoid
---
fftools/ffprobe.c | 4
1 file changed, 4 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index ad633ccc44..fa53004654 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2003,6 +2003,10 @@ static void print_dovi_metadata(WriterContext *w,
Signed-off-by: quietvoid
---
libavfilter/vf_showinfo.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 2c8514fc80..bcd93de568 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -535,6 +535,12 @@ static vo
Signed-off-by: quietvoid
---
tests/fate/hevc.mak | 3 +
tests/ref/fate/hevc-dovi-profile7-rpu | 296 ++
2 files changed, 299 insertions(+)
create mode 100644 tests/ref/fate/hevc-dovi-profile7-rpu
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
This updates the list closer to reality.
Iam not a professional server admin, iam happy to help maintain the box as i
have
done in the past. But iam not qualified nor volunteering to fix sudden problems
nor do i do major upgrades (i lack the experience to recover the box remotely if
something goes
It (unfortunately) involves an allocation and can therefore fail.
Signed-off-by: Andreas Rheinhardt
---
I don't have any nvidia hardware, so all these patches are untested
(apart from ensuring that they compile without creating new warnings).
libavcodec/nvdec.c | 7 +--
1 file changed, 5 in
Signed-off-by: Andreas Rheinhardt
---
libavcodec/nvdec.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 15665b83bb..fbaedf0b6b 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -524,12 +524,9 @@ static int nvdec_r
Said function has a block intended for failure on the main code path
that is jumped over when no error happens:
goto finish;
copy_fail:
/* cleanup code */
finish:
/* more code */
return ret;
This commit changes this to the more common:
finish:
/* more code */
return ret;
copy_f
Regression since 97d9a3293854eda84f05c22e2eaefae7406ac969.
Fixes Coverity issue #1503072.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libspeexdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libspeexdec.c b/libavcodec/libspeexdec.c
index daa6dec64a..af0f2
lör 2022-07-30 klockan 18:42 +0200 skrev Michael Niedermayer:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxf.c | 3 +++
> libavformat/mxf.h | 1 +
> libavformat/mxfdec.c | 48
>
> 3 files changed, 52 insertions(+)
Looks fine.
/T
fre 2022-08-05 klockan 00:03 +0100 skrev Gavin Smith:
> Some NLVEs may insert a KLV packet for EIA-608 data even though
> the number of encapsulated ANC packets is zero.
> ---
> libavformat/mxfdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Looks OK. Also I'm looking at maybe adding
From: Pierre-Anthony Lemieux
Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299726.html
---
libavformat/avformat.c | 66
libavformat/fifo.c | 8 ++---
libavformat/internal.h | 11 +++
libavformat/mux.h| 9 --
l
From: Pierre-Anthony Lemieux
---
libavformat/imfdec.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index 71dfb26958..5bbe7a53f8 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -573,18 +573,14 @@ stati
On Sat, Aug 6, 2022 at 2:43 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299685.html
> >
> > ---
> > libavformat/avformat.c | 68
> > libavfor
Signed-off-by: James Almer
---
libswscale/output.c | 57
libswscale/utils.c | 2 +-
tests/ref/fate/filter-pixdesc-vuya | 1 +
tests/ref/fate/filter-pixfmts-copy | 1 +
tests/ref/fate/filter-pixfmts-crop | 1
On 8/6/2022 8:42 AM, Nicolas George wrote:
James Almer (12022-08-05):
It's not modified, so we can simply use a const pointer to it.
Also check the return value of the other copy in the function while at it.
Signed-off-by: James Almer
---
libavfilter/avfiltergraph.c | 15 ---
1
Signed-off-by: James Almer
---
libavcodec/raw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index a371bb36c4..1e5b48d1e0 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -72,6 +72,7 @@ static const PixelFormatTag raw_pix_fmt_tags[] = {
{ AV_
There's no need to keep using a custom decoder for this pixel format.
Signed-off-by: James Almer
---
What's the process to remove a decoder? Deprecation period, or just git rm?
libavformat/riff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/riff.c b/libavforma
On 8/6/2022 9:34 PM, James Almer wrote:
There's no need to keep using a custom decoder for this pixel format.
Signed-off-by: James Almer
---
What's the process to remove a decoder? Deprecation period, or just git rm?
Actually, it's a decoder, encoder, *and* the AVCodecID, the latter which
de
35 matches
Mail list logo
