On Mon, Mar 13, 2023 at 12:10 AM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > Originally in 77b2cd7b41d7ec8008b6fac753c04f77824c514c this
> > counter was separate in av_frame_unref, in which the same counter
> > was re-utilized multiple times over multiple loops.
> >
> > This code was then refac
On Thu, Mar 9, 2023 at 8:57 PM Jan Ekström wrote:
>
> Generally if maxrate is set, the calculation should be maxrate over
> bufsize. This additionally enables CRF + maxrate & bufsize usage.
>
> In order to keep negative values from enabling zero to be treated
> as larger and causing a division by
On 3/11/23 17:18, Thomas Mundt wrote:
I'm not familiar with checkasm tests, but isn't this one limited to a bit
depth of 8?
Yes, that was the idea because I was only intending to modify the 8-bit
function, for now. The function pointer is the same for all depths so
you need to initializ
On 3/11/23 17:14, Thomas Mundt wrote:
+%if mmsize == 32
+vpbroadcastd m12, DWORD clip_maxm
I get a green pattern at bit depths > 8.
Looks good with:
vpbroadcastw m12, WORD clip_maxm
+%else
movdm12, DWORD clip_maxm
SPLATW m12, m12, 0
+%endif
Of
fre 2023-03-10 klockan 10:17 +0100 skrev Nicolas Gaullier:
> + if (i == c->nb_groups - 1
> + && count * size1 > get_bits_left(&s->gb)
> + && get_bits_left(&s->gb) >= 0
> + && (int)(mnt - c->mantissas) >= MIN_MANTISSAS) {
> +
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libx264.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index e59939a8a7..df70e9df9b 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -311,11 +311,8 @@ static v
This also fixes the number of planes for the NV formats
(this seems to not have caused any problems).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libx264.c | 24 +---
1 file changed, 1 insertion(+), 23 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libx264.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index df70e9df9b..94006d2b20 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -498,19 +498,19 @@
Quoting Raphaël Zumer (2023-03-12 22:50:27)
> I expanded on this in another email in the chain, but the buffer size needs
> to be communicated to the user, as it is not embedded in the payload. It
> seems needlessly convoluted to me to create a separate function solely to
> calculate the size of
The H.264 decoder does not support draw_horiz_band (it does not have
the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
practically dead.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dxva2_h264.c | 7 +--
libavcodec/h264_slice.c | 2 --
libavcodec/h264dec.c| 35 ---
>fre 2023-03-10 klockan 10:17 +0100 skrev Nicolas Gaullier:
>> + if (i == c->nb_groups - 1
>> + && count * size1 > get_bits_left(&s->gb)
>> + && get_bits_left(&s->gb) >= 0
>> + && (int)(mnt - c->mantissas) >= MIN_MANTISSAS) {
>
These filters have been disabled two years ago in commit
95054bfa48cc71db1c7bf66a6b6628cb62f262bf at the major bump
before the last major bump. No one stepped up to port them,
so this commit removes them.
Signed-off-by: Andreas Rheinhardt
---
LICENSE.md | 2 -
configu
Raphaël Zumer:
> Resending this patch set due to my mail client messing with the line wrapping
> in the messages I sent earlier today.
>
> Below is a copy of the initial explanation.
>
> This patch set implements serialization for HDR10+ dynamic metadata
> (AVDynamicHDRPlus), which is the inver
On 3/13/23 12:09, Andreas Rheinhardt wrote:
>>
>> +/**
>> + * Parse the user data registered ITU-T T.35 to AVbuffer
>> (AVDynamicHDRVivid).
>> + * @param s A pointer containing the decoded AVDynamicHDRVivid structure.
>> + * @param data The byte array containing the raw ITU-T T.35 data.
>> + * @
On 3/13/2023 1:56 PM, Raphaël Zumer wrote:
On 3/13/23 12:09, Andreas Rheinhardt wrote:
+/**
+ * Parse the user data registered ITU-T T.35 to AVbuffer (AVDynamicHDRVivid).
+ * @param s A pointer containing the decoded AVDynamicHDRVivid structure.
+ * @param data The byte array containing the r
On 3/13/23 12:58, James Almer wrote:
> On 3/13/2023 1:56 PM, Raphaël Zumer wrote:
>> On 3/13/23 12:09, Andreas Rheinhardt wrote:
+/**
+ * Parse the user data registered ITU-T T.35 to AVbuffer
(AVDynamicHDRVivid).
+ * @param s A pointer containing the decoded AVDynamicHD
Am 2023-02-16 18:14, schrieb emco...@ffastrans.com:
Am 2023-02-12 01:25, schrieb Tomas Härdin:
fre 2023-02-03 klockan 14:54 +0100 skrev emco...@ffastrans.com:
Am 2021-07-03 15:13, schrieb emco...@ffastrans.com:
> Am 2021-06-28 21:58, schrieb emco...@ffastrans.com:
> > Am 2021-06-28 03:00, schri
On 3/13/2023 2:05 PM, Raphaël Zumer wrote:
On 3/13/23 12:58, James Almer wrote:
On 3/13/2023 1:56 PM, Raphaël Zumer wrote:
On 3/13/23 12:09, Andreas Rheinhardt wrote:
+/**
+ * Parse the user data registered ITU-T T.35 to AVbuffer (AVDynamicHDRVivid).
+ * @param s A pointer containing the d
On 3/13/23 13:10, James Almer wrote:
> On 3/13/2023 2:05 PM, Raphaël Zumer wrote:
>> On 3/13/23 12:58, James Almer wrote:
>>> On 3/13/2023 1:56 PM, Raphaël Zumer wrote:
On 3/13/23 12:09, Andreas Rheinhardt wrote:
>>
>> +/**
>> + * Parse the user data registered ITU-T T.35 to A
On 3/13/2023 2:34 PM, Raphaël Zumer wrote:
On 3/13/23 13:10, James Almer wrote:
On 3/13/2023 2:05 PM, Raphaël Zumer wrote:
On 3/13/23 12:58, James Almer wrote:
On 3/13/2023 1:56 PM, Raphaël Zumer wrote:
On 3/13/23 12:09, Andreas Rheinhardt wrote:
+/**
+ * Parse the user data registered
On Sun, Mar 12, 2023 at 11:18 AM Andreas Rheinhardt
wrote:
>
> Possible since 8d226fb9786f34760e80e0d6b403bd63e9ac4ddd.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/allcodecs.c | 2 +-
> libavcodec/libvpxdec.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
lgtm.
__
Signed-off-by: Raphaël Zumer
---
libavcodec/Makefile | 2 +-
libavcodec/dynamic_hdr10_plus.c | 198 ---
libavcodec/dynamic_hdr10_plus.h | 35 --
libavcodec/h2645_sei.c | 6 +-
libavutil/hdr_dynamic_metadata.c | 180
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 5 ++
libavutil/hdr_dynamic_metadata.c | 146 +++
libavutil/hdr_dynamic_metadata.h | 12 +++
libavutil/version.h | 2 +-
4 files changed, 164 insertions(+), 1 deletion(-)
diff --git
On 3/13/2023 5:22 PM, Raphaël Zumer wrote:
Signed-off-by: Raphaël Zumer
---
libavcodec/Makefile | 2 +-
libavcodec/dynamic_hdr10_plus.c | 198 ---
libavcodec/dynamic_hdr10_plus.h | 35 --
libavcodec/h2645_sei.c | 6 +-
libavutil
On Fri, 10 Mar 2023, Anton Khirnov wrote:
This field is ad-hoc and will be deprecated. Use the recently-added
AV_CODEC_FLAG_COPY_OPAQUE to pass arbitrary user data from packets to
frames.
---
fftools/ffplay.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff
On 3/13/2023 5:23 PM, Raphaël Zumer wrote:
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 5 ++
libavutil/hdr_dynamic_metadata.c | 146 +++
libavutil/hdr_dynamic_metadata.h | 12 +++
libavutil/version.h | 2 +-
4 files chan
On 3/13/23 16:47, James Almer wrote:
> On 3/13/2023 5:23 PM, Raphaël Zumer wrote:
>> Signed-off-by: Raphaël Zumer
>> ---
>> doc/APIchanges | 5 ++
>> libavutil/hdr_dynamic_metadata.c | 146 +++
>> libavutil/hdr_dynamic_metadata.h | 12 +++
>> l
On Sun, 12 Mar 2023, Andreas Rheinhardt wrote:
Forgotten in 6b6f7db81932f94876ff4bcfd2da0582b8ab897e.
This and the next similar patch in the series LGTM.
Thanks,
Marton
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libxavs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Signed-off-by: Raphaël Zumer
---
libavcodec/Makefile | 6 +-
libavcodec/av1dec.c | 6 +-
libavcodec/dynamic_hdr10_plus.c | 198 ---
libavcodec/dynamic_hdr10_plus.h | 35 --
libavcodec/h2645_sei.c | 6 +-
libavcodec/libda
Co-authored-by: Mohammad Izadi
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 5 ++
libavutil/hdr_dynamic_metadata.c | 145 +++
libavutil/hdr_dynamic_metadata.h | 13 +++
libavutil/version.h | 2 +-
4 files changed, 164 insertion
On Mon, Mar 13, 2023 at 11:57 AM Jan Ekström wrote:
>
> On Thu, Mar 9, 2023 at 8:57 PM Jan Ekström wrote:
> >
> > Generally if maxrate is set, the calculation should be maxrate over
> > bufsize. This additionally enables CRF + maxrate & bufsize usage.
> >
> > In order to keep negative values from
On 3/13/2023 6:38 PM, Raphaël Zumer wrote:
diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic_metadata.c
index 0fa1ee82de..98f399b032 100644
--- a/libavutil/hdr_dynamic_metadata.c
+++ b/libavutil/hdr_dynamic_metadata.c
@@ -20,6 +20,16 @@
#include "hdr_dynamic_metadata.h"
On 3/13/2023 6:39 PM, Raphaël Zumer wrote:
Co-authored-by: Mohammad Izadi
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 5 ++
libavutil/hdr_dynamic_metadata.c | 145 +++
libavutil/hdr_dynamic_metadata.h | 13 +++
libavutil/version.h
James Almer:
> On 3/9/2023 11:18 AM, Raphaël Zumer wrote:
>> Hi,
>>
>> While I omitted adding v2/v3 here, I believe all comments on this set
>> of patches have been addressed so far, unless anyone strongly
>> disagrees with the rationale for moving dynamic HDR parsing and
>> serialization to libavu
On Fri, 10 Mar 2023, Marton Balint wrote:
On Mon, 6 Mar 2023, Nicolas Gaullier wrote:
The width is one thing; for whatever reason, there is a divergence
between DV100 on one hand and AVCI/XDCAMHD35 on the other. In my
understanding, in current practices, DV obey s337 (stored width
incl
On 3/13/2023 7:25 PM, Andreas Rheinhardt wrote:
James Almer:
On 3/9/2023 11:18 AM, Raphaël Zumer wrote:
Hi,
While I omitted adding v2/v3 here, I believe all comments on this set
of patches have been addressed so far, unless anyone strongly
disagrees with the rationale for moving dynamic HDR pa
Raphaël Zumer:
> Co-authored-by: Mohammad Izadi
> Signed-off-by: Raphaël Zumer
> ---
> doc/APIchanges | 5 ++
> libavutil/hdr_dynamic_metadata.c | 145 +++
> libavutil/hdr_dynamic_metadata.h | 13 +++
> libavutil/version.h | 2 +-
>
On Mon, Mar 13, 2023 at 3:30 PM Marton Balint wrote:
>
>
>
> On Fri, 10 Mar 2023, Marton Balint wrote:
>
> >
> >
> > On Mon, 6 Mar 2023, Nicolas Gaullier wrote:
> >
> > The width is one thing; for whatever reason, there is a divergence
> > between DV100 on one hand and AVCI/XDCAMHD35 on
On Sun, Mar 12, 2023 at 11:52 PM Andreas Rheinhardt
wrote:
>
> SSIM360Context.ssim360_hist is an array of four pointers to double;
> so sizeof(*ssim360_hist[0]) (=sizeof(double)) is the correct size
> to use to calculate the amount of memory to allocate, not
> sizeof(*ssim360_hist) (which is sizeo
On 3/13/23 18:19, James Almer wrote:
> On 3/13/2023 6:38 PM, Raphaël Zumer wrote:
>> diff --git a/libavutil/hdr_dynamic_metadata.c
>> b/libavutil/hdr_dynamic_metadata.c
>> index 0fa1ee82de..98f399b032 100644
>> --- a/libavutil/hdr_dynamic_metadata.c
>> +++ b/libavutil/hdr_dynamic_metadata.c
>> @@
On 3/13/23 18:35, Andreas Rheinhardt wrote:
> size being mandatory is different from similar APIs. There is even a
> usecase without size: If you simply feed this to something that expects
> the data to be serialized and trust the data to be complete, you don't
> need the size.
OK, I'll amend that.
On 3/13/2023 8:19 PM, Raphaël Zumer wrote:
On 3/13/23 18:35, Andreas Rheinhardt wrote:
size being mandatory is different from similar APIs. There is even a
usecase without size: If you simply feed this to something that expects
the data to be serialized and trust the data to be complete, you don
On 3/13/23 19:25, James Almer wrote:
>>> You are allocating without any padding. This implies that one could not
>>> use this buffer with our GetBit-API or in other places where one needed
>>> a padded buffer.
>> Is there any comparable code that does that? I feel like padding a buffer
>> should b
Signed-off-by: Raphaël Zumer
---
libavcodec/Makefile | 6 +-
libavcodec/av1dec.c | 6 +-
libavcodec/dynamic_hdr10_plus.c | 198 ---
libavcodec/dynamic_hdr10_plus.h | 35 --
libavcodec/h2645_sei.c | 6 +-
libavcodec/libda
Co-authored-by: Mohammad Izadi
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 5 ++
libavutil/hdr_dynamic_metadata.c | 148 +++
libavutil/hdr_dynamic_metadata.h | 13 +++
libavutil/version.h | 2 +-
4 files changed, 167 insertion
On Thu, 9 Mar 2023, Devin Heitmueller wrote:
Extend the decklink output to include support for compressed AC-3,
encapsulated using the SMPTE ST 377:2015 standard.
This functionality can be exercised by using the "copy" codec when
the input audio stream is AC-3. For example:
./ffmpeg -i ~/f
Raphaël Zumer:
> Signed-off-by: Raphaël Zumer
> ---
> libavcodec/Makefile | 6 +-
> libavcodec/av1dec.c | 6 +-
> libavcodec/dynamic_hdr10_plus.c | 198 ---
> libavcodec/dynamic_hdr10_plus.h | 35 --
> libavcodec/h2645_sei.c
FFmpeg's assembly code currently does not abide by the
plattform-specific ABIs wrt its handling of the X86 MMX flag:
Resetting the MMX state is deferred to avoid doing it multiple times
instead of ensuring that the CPU is in floating point state
upon return from any function.
Furthermore, resettin
Incrementing a NULL pointer is undefined behaviour,
yet this is what would happen in case trailer were NULL
before the check.
Signed-off-by: Andreas Rheinhardt
---
libavformat/assenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/assenc.c b/libavformat/asse
When writing WebMs, FFmpeg muxes WebVTT subtitles with the D_WEBVTT/*
codec tags from the WebM specs [1]. However, it does the same when
muxing MKV files, and the Matroska specifications instead use
S_TEXT/WEBVTT tags for WebVTT subtitles [2], which FFmpeg currently
doesn't understand. Support read
Gwyneth Morgan:
> When writing WebMs, FFmpeg muxes WebVTT subtitles with the D_WEBVTT/*
> codec tags from the WebM specs [1]. However, it does the same when
> muxing MKV files, and the Matroska specifications instead use
> S_TEXT/WEBVTT tags for WebVTT subtitles [2], which FFmpeg currently
> doesn'
Quoting Andreas Rheinhardt (2023-03-12 22:52:49)
> SSIM360Context.ssim360_hist is an array of four pointers to double;
> so sizeof(*ssim360_hist[0]) (=sizeof(double)) is the correct size
> to use to calculate the amount of memory to allocate, not
> sizeof(*ssim360_hist) (which is sizeof(double*)).
Quoting Andreas Rheinhardt (2023-03-12 22:53:44)
> Fixes Coverity issue #1520669.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/vf_ssim360.c | 4
> 1 file changed, 4 deletions(-)
Looks ok.
--
Anton Khirnov
___
ffmpeg-devel mailing l
Patches 3-6 LGTM
--
Anton Khirnov
___
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 subject "unsubscribe".
The attached patchset is all the common code changes that my Vulkan patchset
needs.
In total lines of code, this part has 425 additions and 131 deletions.
Most of that is additions to HEVC parsing. Excluding them, the patchset is
200 lines of code added, which is manageable.
Apart from the parse
55 matches
Mail list logo
