> On Jul 17, 2024, at 5:39 PM, Paul B Mahol wrote:
>
> On Tue, Jul 16, 2024 at 5:56 PM Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
>>
>>
>>> On Jul 16, 2024, at 4:58 PM, Zhao Zhili wrote:
>>>
>>>
&g
> On Jul 16, 2024, at 8:24 PM, Rémi Denis-Courmont wrote:
>
> Le tiistaina 16. heinäkuuta 2024, 18.48.06 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>> To add another data point, the platform decoders might also be more secure
>> due to sandboxing. I
> On Jul 16, 2024, at 6:04 PM, Zhao Zhili wrote:
>
>
>
>> On Jul 16, 2024, at 23:48, Cosmin Stejerean via ffmpeg-devel
>> wrote:
>>
>>
>>
>>> On Jul 16, 2024, at 4:58 PM, Zhao Zhili wrote:
>>>
>>>
>>>
&
> On Jul 16, 2024, at 4:58 PM, Zhao Zhili wrote:
>
>
>
>> On Jul 16, 2024, at 21:20, Matthieu Bouron wrote:
>>
>> On Wed, Jul 10, 2024 at 6:31 PM Matthieu Bouron
>> wrote:
>>>
>>> On Wed, Jul 10, 2024 at 4:04 PM Zhao Zhili wrote:
> On Jun 12, 2024, at 21:42, Matthieu
> On Jul 16, 2024, at 1:23 PM, Niklas Haas wrote:
>
> From: Niklas Haas
>
> ---
> libavformat/dump.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index 78b2481d90..5e1f367742 100644
> --- a/libavformat/dump.c
> +++
> On Jul 16, 2024, at 1:23 PM, Niklas Haas wrote:
>
> From: Niklas Haas
>
> ---
> libavformat/mpegts.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index c66a1ea6ed..6b02187eb1 100644
> ---
> On Jul 16, 2024, at 1:23 PM, Niklas Haas wrote:
>
> From: Niklas Haas
>
> ---
> libavformat/dovi_isom.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/dovi_isom.c b/libavformat/dovi_isom.c
> index d49aa5a75f..269374cff9 100644
>
> On Jul 16, 2024, at 1:23 PM, Niklas Haas wrote:
>
> From: Niklas Haas
>
> ---
> fftools/ffprobe.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 0b7d4ce0d7..265718467f 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@
> On Jul 16, 2024, at 1:23 PM, Niklas Haas wrote:
>
> From: Niklas Haas
>
> This field is used to signal the compression method in use.
> ---
> doc/APIchanges| 3 +++
> libavutil/dovi_meta.h | 9 +
> libavutil/version.h | 2 +-
> 3 files changed, 13 insertions(+), 1
From: Cosmin Stejerean
now that we are reading ext_mapping_idc as the upper 8 bits of
el_bit_depth_minus8 we need to use get_ue_golomb_long rather than
get_ue_golomb_31 for reading it
---
libavcodec/dovi_rpudec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
> On Jun 19, 2024, at 3:21 AM, Niklas Haas wrote:
>
> On Thu, 23 May 2024 19:50:23 +0000 Cosmin Stejerean via ffmpeg-devel
> wrote:
>> From: Cosmin Stejerean
>>
>> not all clients support metadata compression, output when
>> vdr_dm_metadata_changed fa
> On Jun 5, 2024, at 5:23 AM, Niklas Haas wrote:
>
> On Wed, 05 Jun 2024 12:07:08 +0200 Andreas Rheinhardt
> wrote:
>> Niklas Haas:
>>> From: Niklas Haas
>>>
>>> This code was unnecessarily trying to be robust against downgrades of
>>> libavutil (relative to the version libavcodec was
> On Jun 3, 2024, at 11:53 PM, Vittorio Giovara
> wrote:
>
> On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
>>> Reposting my question/comment here since Thilo hasn't had a chance to
>>> respond
> On Jun 3, 2024, at 3:58 PM, Vittorio Giovara
> wrote:
>
> On Mon, Jun 3, 2024 at 10:57 PM Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
>>
>>
>>> On Jun 3, 2024, at 12:26 PM, Rémi Denis-Courmont
>> wrote:
>&
> On Jun 3, 2024, at 12:26 PM, Rémi Denis-Courmont wrote:
>
> Le maanantaina 3. kesäkuuta 2024, 21.58.48 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>> Not sure why you keep beating this dead horse.
>
> Err, I think that it is obvious why:
>
> 1) The qu
> On Jun 3, 2024, at 11:18 AM, Rémi Denis-Courmont wrote:
>
> Le maanantaina 3. kesäkuuta 2024, 20.48.08 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>>>> What was cost-problematic about NAB? As far as I know it cost ffmpeg $0.
>>>> It would be hard
> On Jun 3, 2024, at 10:36 AM, Rémi Denis-Courmont wrote:
>
> Le 3 juin 2024 19:43:52 GMT+03:00, Cosmin Stejerean via ffmpeg-devel
> a écrit :
>>
>>
>>> On Jun 3, 2024, at 12:55 AM, Rémi Denis-Courmont wrote:
>>>
>>> IBC is probably
> On Jun 3, 2024, at 12:55 AM, Rémi Denis-Courmont wrote:
>
> IBC is probably not as (cost-)problematic as NAB, w.r.t. setting up the booth
> or transportation
What was cost-problematic about NAB? As far as I know it cost ffmpeg $0. It
would be hard for IBC to be less cost-problematic than
> On May 23, 2024, at 4:03 AM, Niklas Haas wrote:
>
> On Wed, 22 May 2024 15:50:43 +0000 Cosmin Stejerean via ffmpeg-devel
> wrote:
>> From: Cosmin Stejerean
>>
>> ---
>> libavutil/dovi_meta.h | 2 ++
>> libavutil/version.h | 2 +-
>&
From: Cosmin Stejerean
---
libavcodec/libsvtav1.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2fef8c8971..4a8cab4eb9 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -731,8 +731,7 @@ static const
From: Cosmin Stejerean
---
libavcodec/libx265.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index ac1dbc4f97..70e447fc0e 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -951,8 +951,7 @@ static const AVOption
From: Cosmin Stejerean
---
libavcodec/libaomenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index dec74ebecd..22429717e8 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1487,8 +1487,7 @@ static
From: Cosmin Stejerean
Guard use_prev_vdr_rpu by the new enable_compression field since not all
clients support this.
Separately output when vdr_dm_metadata_changed == 0 fails the DV verifier so
turn that off unconditionally for now.
---
libavcodec/dovi_rpuenc.c | 8 ++--
1 file changed,
From: Cosmin Stejerean
Add a field to enable or disable metadata compression since not all clients
support this.
Introduce DOVI_ENCODING_OPTS macro to faciliate exposing this as an option to
encoders.
---
libavcodec/dovi_rpu.h | 10 ++
1 file changed, 10 insertions(+)
diff --git
From: Cosmin Stejerean
not all clients support metadata compression, output when
vdr_dm_metadata_changed fails the DV verifier.
Compared to v2 this makes the dovi field name a parameter of the
DOVI_ENCODING_OPTS macro as requested. It also splits up the commits into
introducing the macro,
From: Cosmin Stejerean
not all clients support metadata compression, output when
vdr_dm_metadata_changed fails the DV verifier.
---
libavcodec/dovi_rpu.h| 10 ++
libavcodec/dovi_rpuenc.c | 8 ++--
libavcodec/libaomenc.c | 3 +--
libavcodec/libsvtav1.c | 3 +--
> On May 21, 2024, at 3:19 AM, Niklas Haas wrote:
>
> On Tue, 21 May 2024 04:03:43 +0000 Cosmin Stejerean via ffmpeg-devel
> wrote:
>>
>> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
>> index dec74ebecd..c6104f5522 100644
>> --- a/libavc
From: Cosmin Stejerean
Some DolbyVision samples fail to parse currently due to mis-reading the
el_bit_depth_minus8 field. Upon investigation it seems that the RPU syntax has
been extended in an as of yet undocumented way by adding ext_mapping_idc and
coding it together with el_bit_depth_minus8
From: Cosmin Stejerean
These two fields are coded together into a single 16 bit integer with upper 8
bits for ext_mapping_idc and lower 8 bits for el_bit_depth_minus8.
Furthermore ext_mapping_idc has two components, upper 3 bits and lower 5 bits.
---
libavcodec/dovi_rpudec.c | 7 ++-
From: Cosmin Stejerean
---
libavutil/dovi_meta.h | 2 ++
libavutil/version.h | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
index e10332f8d7..e168075a24 100644
--- a/libavutil/dovi_meta.h
+++ b/libavutil/dovi_meta.h
@@ -91,6
> On May 21, 2024, at 9:19 PM, Andreas Rheinhardt
> wrote:
>
> Cosmin Stejerean via ffmpeg-devel:
>> From: Cosmin Stejerean
>>
>> These two fields are coded together into a single 16 bit integer with upper 8
>> bits for ext_mapping_idc and
> On May 21, 2024, at 11:54 AM, Cosmin Stejerean via ffmpeg-devel
> wrote:
>
>
> However I've found a workaround. By setting my git send-email from to just
> "cos...@cosmin.at <mailto:cos...@cosmin.at>" rather than "Cosmin Stejerean
> mailto:cos..
> On May 21, 2024, at 11:54 AM, Cosmin Stejerean via ffmpeg-devel
> wrote:
>
>
> However I've found a workaround. By setting my git send-email from to just
> "cos...@cosmin.at <mailto:cos...@cosmin.at>" rather than "Cosmin Stejerean
> mailto:cos..
> On May 21, 2024, at 11:48 AM, Dennis Sädtler via ffmpeg-devel
> wrote:
>
>> From: Dennis Sädtler via ffmpeg-devel
>
> I wonder what happened here, did I make a mistake when submitting the
> original patch to the ML so the actual commit author name/email got
> lost?
>
> Should be the same
From: Cosmin Stejerean
These two fields are coded together into a single 16 bit integer with upper 8
bits for ext_mapping_idc and lower 8 bits for el_bit_depth_minus8.
Furthermore ext_mapping_idc has two components, upper 3 bits and lower 5 bits.
---
libavcodec/dovi_rpudec.c | 7 ++-
> On May 21, 2024, at 3:21 AM, Niklas Haas wrote:
>
> On Tue, 21 May 2024 01:17:32 +0000 Cosmin Stejerean via ffmpeg-devel
> wrote:
>> From: Cosmin Stejerean
>>
>> It looks like the el_bitdepth_minus8 value in the header can also encode
>>
From: Cosmin Stejerean
not all clients support metadata compression, make this an option and off by
default until we can verify output.
vdr_dm_metadata_changed = 0 case fails the DV verifier so force this to true
for now until we can determine the correct output format for this case.
---
> On May 20, 2024, at 6:17 PM, Cosmin Stejerean via ffmpeg-devel
> wrote:
>
> From: Cosmin Stejerean
>
> Co-authored-by: Amir Naghdinezhad
> Signed-off-by: Cosmin Stejerean
> ---
> libavcodec/libsvtav1.c | 10 ++
> 1 file changed, 10 insert
From: Cosmin Stejerean
Co-authored-by: Amir Naghdinezhad
Signed-off-by: Cosmin Stejerean
---
libavcodec/libsvtav1.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 3b41f5a39e..1eda63200c 100644
--- a/libavcodec/libsvtav1.c
From: Cosmin Stejerean
It looks like the el_bitdepth_minus8 value in the header can also encode
ext_mapping_idc in the upper 8 bits.
Samples having a non-zero ext_mapping_idc fail validation currently because the
value returned is out of range. This bypasses this by currently ignoring the
> On May 20, 2024, at 1:05 PM, Rémi Denis-Courmont wrote:
>
> Le maanantaina 20. toukokuuta 2024, 22.33.45 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>>> And again, you can't expect users to select decoders manually. If vvdec is
>>> the
>>>
> On May 20, 2024, at 12:01 PM, Rémi Denis-Courmont wrote:
>
> Le maanantaina 20. toukokuuta 2024, 21.39.18 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>> The same way using FDK-AAC as a decoder works, if you want to use it as the
>> *AAC decoder you hav
> On May 20, 2024, at 11:03 AM, Rémi Denis-Courmont wrote:
>
> Le maanantaina 20. toukokuuta 2024, 19.33.43 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>
>> hwaccel decoding seems somewhat orthogonal
>
> How exactly will that work then? Either vvdec
Trying again with better formatting, hopefully
> On May 18, 2024, at 10:48 PM, Rémi Denis-Courmont wrote:
>
> Hi,
>
> Le 18 mai 2024 21:55:04 GMT+03:00, Cosmin Stejerean via ffmpeg-devel
> a écrit :
>>
>>
>>> On May 18, 2024, at 7:04 AM, Nuo Mi wrote
On May 18, 2024, at 10:48 PM, Rémi Denis-Courmont wrote:
Le 18 mai 2024 21:55:04 GMT+03:00, Cosmin Stejerean via ffmpeg-devel
mailto:ffmpeg-devel@ffmpeg.org> > a écrit :
On May 18, 2024, at 7:04 AM, Nuo Mi mailto:nuomi2...@gmail.com> > wrote:
This happened many years ago. See th
> On May 18, 2024, at 7:04 AM, Nuo Mi wrote:
>
> This happened many years ago. See the discussion here:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201221060710.12230-6-nuomi2...@gmail.com/#60589
> Now that we have an internal vvc decoder, we can focus on improving it.
> As for the
> On May 14, 2024, at 9:28 AM, Lynne via ffmpeg-devel
> wrote:
>
> On 14/05/2024 17:09, Christian Bartnik wrote:
>> From: Thomas Siedel
>> Add external decoder VVdeC for H266/VVC decoding.
>> Register new decoder libvvdec.
>> Add libvvdec to wrap the vvdec interface.
>> Enable decoder by
> On May 3, 2024, at 6:54 AM, Ronald S. Bultje wrote:
>
> On Fri, May 3, 2024 at 7:33 AM Rémi Denis-Courmont wrote:
>
>>
>> There is no technical plan how that would actually work in practice, and I
>> don't think it is even feasible. Not to speak of a realistic plan who would
>> actually
> On May 2, 2024, at 9:35 AM, Zhao Zhili wrote:
>
> I know a developer which have contributed to FFmpeg and stop doing so after
> losing his git-send-email environment.
I'm not surprised, getting git-send-email to work can be fairly daunting.
First you have to know enough about secure SMTP to
> On Mar 25, 2024, at 1:49 AM, Andrea Mastroberti via ffmpeg-devel
> wrote:
>
> Signed-off-by: Andrea Mastroberti <10736...@polimi.it>
> ---
> doc/filters.texi | 20 -
> libavfilter/version.h | 2 +-
> libavfilter/vf_smartblur.c | 44
> On Mar 19, 2024, at 2:39 PM, Derek Buitenhuis
> wrote:
>
> The reason I never implemented this back when I adde RPU side data is that
> there is a strong chance of generating broken files.
>
> That's because if we do anything to the video with swscale, etc., we're
> now encoding RPUs that
On Mar 19, 2024, at 10:21 AM, Kieran Kunhya wrote:
On Tue, 19 Mar 2024 at 15:27, James Almer mailto:jamr...@gmail.com> > wrote:
On 3/19/2024 12:20 PM, Kieran Kunhya wrote:From
https://github.com/v-novaltd/LCEVCdec
" This software is protected by copyrights and other intellectual
property
> On Mar 2, 2024, at 11:01 AM, Ronald S. Bultje wrote:
>
> This recusal may be effected either directly by
>> the TC member, or by a vote of the Community Committee (CC)
>>
>
> The CC is for enforcement of behavioural guidelines (CoC), not for
> technical matters, so this strikes me as a
> On Feb 20, 2024, at 7:07 PM, wenbin.chen-at-intel@ffmpeg.org wrote:
>
> From: Wenbin Chen
>
> PyTorch is an open source machine learning framework that accelerates
> the path from research prototyping to production deployment. Official
> website: https://pytorch.org/. We call the C++
> On Feb 29, 2024, at 7:27 AM, Zhao Zhili wrote:
>
> Hi, I can't pull from main developer git server. Patchwork is slow to loading.
> I have tried two ISP. Anything happened?
Not sure if it's related but trac has also been very unreliable for me, with
frequent "Service Unavailable" errors
> On Feb 27, 2024, at 1:49 PM, James Almer wrote:
>
>>> SVT-AV1 1.8.0 has this value set to 1.8.0, same as in the current git head
>>> commit. Is this in preparation for an upcoming release?
>> Yes, this is in preparation for release 2.0 which is targeted for next week.
>>
> On Feb 27, 2024, at 1:19 PM, James Almer wrote:
>
> SVT-AV1 1.8.0 has this value set to 1.8.0, same as in the current git head
> commit. Is this in preparation for an upcoming release?
Yes, this is in preparation for release 2.0 which is targeted for next week.
From: Cosmin Stejerean
Co-authored-by: Amir Naghdinezhad
Signed-off-by: Cosmin Stejerean
---
libavcodec/libsvtav1.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 3b41f5a39e..1eda63200c 100644
--- a/libavcodec/libsvtav1.c
> On Feb 20, 2024, at 12:41 PM, Michael Niedermayer
> wrote:
>
> On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2024-02-20 15:01:11)
>>> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
>>> [...]
their preferred wording, and
> On Feb 1, 2024, at 11:26 PM, wenbin.chen-at-intel@ffmpeg.org wrote:
>
> From: Wenbin Chen
>
> PyTorch is an open source machine learning framework that accelerates
> the path from research prototyping to production deployment. Official
> websit: https://pytorch.org/. We call the C++
> On Feb 7, 2024, at 1:48 PM, Lynne wrote:
>
> Feb 7, 2024, 22:11 by ffmpeg-devel@ffmpeg.org:
>
>>
>>
>>> On Feb 7, 2024, at 11:27 AM, Lynne wrote:
>>>
>
> As a compromise, we could start requiring C11 now, and C17 in 7.1.
> Or does anyone still care about compilers without
> On Feb 7, 2024, at 11:27 AM, Lynne wrote:
>
>>>
>>> As a compromise, we could start requiring C11 now, and C17 in 7.1.
>>> Or does anyone still care about compilers without even c11 support?
>>>
>>
>> How about C11 now and C17 in a year with ffmpeg 8?
>>
>
> Do you have setups and
> On Jan 23, 2024, at 11:22 AM, Michael Niedermayer
> wrote:
>
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release
Can we get the
> On Feb 7, 2024, at 1:55 AM, Anton Khirnov wrote:
>
> As a compromise, we could start requiring C11 now, and C17 in 7.1.
> Or does anyone still care about compilers without even c11 support?
How about C11 now and C17 in a year with ffmpeg 8?
- Cosmin
> On Feb 6, 2024, at 10:17 AM, Michael Niedermayer
> wrote:
>
> if "merge to git master" is a requirement then iam not participating
> in this. The risk simply outweights the gain. I wont work for months to
> then be at the mercy of not a single of 2000 subscribers posting some
> "i object"
From: Cosmin Stejerean
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index 7546cf0caf..cbe6b3ff99 100644
--- a/.mailmap
+++ b/.mailmap
@@ -22,3 +22,4 @@ rcombs
+Cosmin Stejerean Cosmin Stejerean via ffmpeg-devel
--
2.42.1
From: Cosmin Stejerean
---
tests/fate/mov.mak| 5 +
tests/ref/fate/mov-read-amve | 8
tests/ref/fate/mov-write-amve | 33 +
3 files changed, 46 insertions(+)
create mode 100644 tests/ref/fate/mov-read-amve
create mode 100644
From: Damiano Galassi
Co-Authored-By: Cosmin Stejerean
---
libavformat/dump.c | 15 +
libavformat/isom.h | 3 +++
libavformat/mov.c| 35 +++
libavformat/movenc.c | 50 ++--
4 files changed, 92
From: Damiano Galassi
---
doc/APIchanges| 3 +++
fftools/ffprobe.c | 3 +++
libavcodec/avpacket.c | 1 +
libavcodec/decode.c | 1 +
libavcodec/packet.h | 9 -
libavcodec/version.h | 2 +-
6 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges
From: Cosmin Stejerean
Version 4 resolves feedback from v3 by moving new side data field in
packet.h to the end for ABI compatibility, bumping the minor API
version for lavc, adding APIChanges entry, using -c:v in the FATE
test, cleaning up formatting in avformat/movenc and renaming
rescale_mdcv
> On Feb 4, 2024, at 13:44, James Almer wrote:
>
> On 2/4/2024 8:16 AM, Cosmin Stejerean via ffmpeg-devel wrote:
>> From: Cosmin Stejerean
>>
>> ---
>> tests/fate/mov.mak| 5 +
>> tests/ref/fate/mov-read-amve | 8
> On Feb 4, 2024, at 12:45, Anton Khirnov wrote:
>
> Quoting Cosmin Stejerean via ffmpeg-devel (2024-02-04 12:16:53)
>> diff --git a/libavcodec/packet.h b/libavcodec/packet.h
>> index 2c57d262c6..215b1c9970 100644
>> --- a/libavcodec/packet.h
>> +++ b/libavco
From: Cosmin Stejerean
---
tests/fate/mov.mak| 5 +
tests/ref/fate/mov-read-amve | 8
tests/ref/fate/mov-write-amve | 33 +
3 files changed, 46 insertions(+)
create mode 100644 tests/ref/fate/mov-read-amve
create mode 100644
From: Damiano Galassi
Co-Authored-By: Cosmin Stejerean
---
libavformat/dump.c | 15 +++
libavformat/isom.h | 3 +++
libavformat/mov.c| 35 +++
libavformat/movenc.c | 30 ++
4 files changed, 83 insertions(+)
diff
From: Damiano Galassi
---
fftools/ffprobe.c | 3 +++
libavcodec/avpacket.c | 1 +
libavcodec/decode.c | 1 +
libavcodec/packet.h | 7 +++
4 files changed, 12 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index f33e2471cb..aa1153e709 100644
--- a/fftools/ffprobe.c
From: Cosmin Stejerean
This rebases the previous patch series from Damiano Galassi after the
packet side data changes and adds FATE tests for both reading and
writing amve
Cosmin Stejerean (1):
tests/fate/mov: add a test for reading and writing amve box
Damiano Galassi (2):
avcodec: add
> On Feb 1, 2024, at 9:45 AM, Vittorio Giovara
> wrote:
>
> Since all objections and requests for more time have been ignored, and this
> is happening anyway, can we add a small amendment for the sake of
> transparency and for avoiding any conflict of interest? Whoever was
> involved with the
> On Jan 31, 2024, at 11:07 AM, Michael Niedermayer
> wrote:
>
> On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote:
>> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer
>> wrote:
>>
>>> Hi Jonatas, Remi
>>>
>>> _THIS_ reply shows why i LOVE SPI
>>>
>>> I mean this is
> On Jan 28, 2024, at 7:54 AM, Kieran Kunhya wrote:
>
> So work like Anton's threading, YUVJ removal etc, that couldn't be funded
> via bounties as they have no direct commercial value but require expertise
> in the codebase.
> Statements of Work and milestones (by definition) are for
> On Dec 8, 2023, at 11:07 AM, Kalev Lember wrote:
>
> On Fri, Dec 8, 2023 at 4:59 PM James Almer wrote:
>
>> Does the configure check ensure a new enough openh264 version is the
>> minimum supported?
>>
>
> Hm, I'd say that configure minimum version check is mostly orthogonal to
> the
> On Dec 7, 2023, at 9:42 AM, Andreas Rheinhardt
> wrote:
>
> According to
> https://developers.google.com/speed/webp/docs/riff_container#extended_file_format
> metadata chunks are stored after the image data; if you split the data
> into packets, then the metadata while only become available
> On Dec 6, 2023, at 11:36 AM, Anton Khirnov wrote:
>
>> In some cases the performance penalty because of threading is quite
>> significant:
>>
>> Example command line:
>>
>> ffmpeg -f lavfi -i sine -af volume=6dB -f null none
>>
>> After latest threading changes: speed=810x
>> Before
> On Dec 6, 2023, at 02:44, Philip Langdale via ffmpeg-devel
> wrote:
>
> On Sat, 2 Dec 2023 23:02:36 +0100
> Thomas Mundt wrote:
>
>>
>> LGTM, thanks.
>>
>
> I am going to squash the three commits and push. There's no real need
> to put each filter in a separate diff when the logical
From: Cosmin Stejerean
---
tests/Makefile | 1 +
tests/fate/qoa.mak | 12
tests/ref/fate/qoa-152 | 13
tests/ref/fate/qoa-278 | 135 +
tests/ref/fate/qoa-303 | 35 +++
5 files changed, 196 insertions(+)
create mode
From: Cosmin Stejerean
Fixes #10688
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 137cd5ef13..353cd0b61a 100644
--- a/libavfilter/vf_bwdif.c
+++
From: Cosmin Stejerean
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif_vulkan.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_bwdif_vulkan.c b/libavfilter/vf_bwdif_vulkan.c
index 690a89c4ba..c51df9aa26 100644
---
From: Cosmin Stejerean
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif_cuda.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
index a5ecfbadb6..418f15f989 100644
--- a/libavfilter/vf_bwdif_cuda.c
From: Cosmin Stejerean
This fixes the issue reported in #10688. In v3 only the chroma planes
are checked based on feedback for v2, since the chroma planes are
going to have the minimum dimension.
Cosmin Stejerean (3):
avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum
> On Dec 2, 2023, at 7:53 AM, Anton Khirnov wrote:
>
> Its author not only failed to add any tests, as is required by the
> development rules, but continues to actively refuse to do so.
>
> Untested decoders are worse than useless, so remove it.
While I agree that decoders (among other
On Nov 30, 2023, at 04:37, Thomas Mundt wrote:
Am Do., 30. Nov. 2023 um 01:23 Uhr schrieb Cosmin Stejerean via ffmpeg-devel
mailto:ffmpeg-devel@ffmpeg.org> >:
From: Cosmin Stejerean mailto:cos...@cosmin.at> >
Fixes #10688
Signed-off-by: Cosmin Stejerean mailto:cos.
> On Nov 30, 2023, at 03:07, Tomas Härdin wrote:
>
> tor 2023-11-30 klockan 01:49 +0100 skrev Stefano Sabatini:
>> This is meant to introduce functionality to handle QR codes.
>
> Why?
>
The why seems to be answered below the section you quoted in the original email
> QR codes are robust
> On Nov 29, 2023, at 5:42 PM, Ronald S. Bultje wrote:
>
> Does ranked voting allow expressing equal weight to multiple candidates?
> For example, I prefer Jerry and Tom equally, but I prefer either one over
> Spike.
In theory that could depend on the implementation of ranked voting, it could
From: Cosmin Stejerean
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif_vulkan.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_bwdif_vulkan.c b/libavfilter/vf_bwdif_vulkan.c
index 690a89c4ba..6a886d11ac 100644
---
From: Cosmin Stejerean
Fixes #10688
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 137cd5ef13..80aa85a48b 100644
--- a/libavfilter/vf_bwdif.c
From: Cosmin Stejerean
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif_cuda.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
index a5ecfbadb6..7d9bf861b7 100644
---
From: Cosmin Stejerean
This fixes the issue reported in #10688. In v2 the checks for chroma
plane are combined together and the fixes are extended to cover the
Vulkan and CUDA implementations of bwdif.
I have not had a chance to replicate the issue on CUDA or Vulkan but
based on the dimension
> On Nov 29, 2023, at 3:14 PM, Michael Niedermayer
> wrote:
>
> If you give Jerry a weight of 10 and give Tom a weight of 9, that means
> you prefer Jerry over Tom because 10 > 9
> If you give Spike a weight of 20 that would mean you not only prefer Spike
> over Tom OR Jerry but also over Tom
> On Nov 29, 2023, at 11:36 AM, Dennis Mungai wrote:
>
> On Wed, 29 Nov 2023 at 22:26, Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
>>
>>
>>> On Nov 28, 2023, at 5:30 AM, Thomas Mundt wrote:
>>>
>>> Hi
> On Nov 28, 2023, at 5:30 AM, Thomas Mundt wrote:
>
> Hi Cosmin,
>
> Cosmin Stejerean via ffmpeg-devel schrieb am Sa.,
> 25. Nov. 2023, 21:39:
>
>> Fixes #10688
>>
>> Signed-off-by: Cosmin Stejerean
>> ---
>> libavfilter/vf_bwdif.c
Fixes #10688
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 137cd5ef13..bce11c39f7 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -197,6
1 - 100 of 123 matches
Mail list logo
