On 21.05.24 21:42, Rémi Denis-Courmont wrote:
Le tiistaina 21. toukokuuta 2024, 21.43.44 EEST Thilo Borgmann via ffmpeg-devel
a écrit :
Same as above about that we should and STF would.
Especially since no corporate interest usually pays anyone for these
tasks
Sadly true, but...
(in case
On 21.05.24 21:43, Rémi Denis-Courmont wrote:
Le tiistaina 21. toukokuuta 2024, 22.42.00 EEST Rémi Denis-Courmont a écrit :
And "I hope you realise that you are arguing for" Intel, Loongson, etc.
employees to stop reviewing patches.
P.S.: And FFlabs too, since it is a for-profit company.
S
On Tue, 14 May 2024 19:07:59 -0700
Philip Langdale via ffmpeg-devel wrote:
> On Wed, 15 May 2024 01:36:43 +0530
> [email protected] wrote:
>
> > From: llyyr
> >
> > ab77b878f1 attempted to fix the issue of broken packets being sent
> > to the decode
> 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
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
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 ++-
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 to
On Wed, 22 May 2024 11:10:31 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Wed, May 22, 2024 at 10:36 AM Hendrik Leppkes
> wrote:
>
> > On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
> > >
> > > segmentation.update_map is never reset to 0 on a new frame, and
> > > retains the value from the pr
On Tue, May 21, 2024 at 9:50 AM Thilo Borgmann via ffmpeg-devel
wrote:
>
> Hi,
>
> [...]
> >>> Tests mostly work for me. There are a few images (that I reported
> >>> earlier) that give:
> >>
> >> thanks for testing!
> >>
> &g
> On May 21, 2024, at 3:19 AM, Niklas Haas wrote:
>
> On Tue, 21 May 2024 04:03:43 + 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
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 +--
libavcodec/
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, guar
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 a/
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
---
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 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 op
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 A
> On May 23, 2024, at 4:03 AM, Niklas Haas wrote:
>
> On Wed, 22 May 2024 15:50:43 + Cosmin Stejerean via ffmpeg-devel
> wrote:
>> From: Cosmin Stejerean
>>
>> ---
>> libavutil/dovi_meta.h | 2 ++
>> libavutil/version.h | 2 +-
>&
Am 22.05.24 um 14:27 schrieb Rémi Denis-Courmont:
Le 22 mai 2024 00:34:03 GMT+03:00, Thilo Borgmann via ffmpeg-devel
a écrit :
I hope you realize what you argue in favor of.
Yes. It's quoted above.
Are you claiming that *no* review is better than *some* review done in
*public* for a
On 24.05.24 11:56, Andrew Sayers wrote:
On Fri, May 17, 2024 at 03:49:58PM +0200, Michael Niedermayer wrote:
Hi all
Before this is forgotten again, better start some dicsussion too early than too
late
This comment is inspired by the other subthread, but not directly in reply to
it.
I'm r
It is possible that the actual audio data only occupy part of the last audio
frame. This can be signaled by duration in the "trun" atom. We should respect
the metadata of file and set the duration correctly.
---
libavformat/mov.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-
On 2024-05-31 10:53, Martin Storsjö wrote:
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is
On 2024-04-29 23:53 +0200, Alexander Strasser via ffmpeg-devel wrote:
> When piping ffmpeg into ffplay both programs write a status line in
> the terminal. That causes flickering and invisibility of one or the
> other status line.
>
> As compromise set ffplay log level to warning
On 2024-05-29 18:51 +0300, Rémi Denis-Courmont wrote:
> Le keskiviikkona 29. toukokuuta 2024, 18.44.13 EEST Andreas Rheinhardt a écrit
> :
> > > +static double ff_scalarproduct_double_c(const double *v1,
>
> > Don't use an ff_ prefix for a static function.
>
> I can see over 300 such identifiers in
On 2024-06-02 13:30 +0300, Rémi Denis-Courmont wrote:
> Le sunnuntaina 2. kesäkuuta 2024, 13.04.05 EEST Alexander Strasser via ffmpeg-
> devel a écrit :
> > On 2024-05-29 18:51 +0300, Rémi Denis-Courmont wrote:
> > > Le keskiviikkona 29. toukokuuta 2024, 18.44.13 EEST
On 2024-06-02 21:36, Martin Storsjö wrote:
On Sat, 1 Jun 2024, Dennis Sädtler via ffmpeg-devel wrote:
Should the ftyp atom also be updated to remove brands no longer
required for non-fragmented files?
I'm not sure how important that is in real-world scenarios, so it
might not be worth
Am 02.06.24 um 22:14 schrieb Tomas Härdin:
sön 2024-06-02 klockan 20:01 +0200 skrev Michael Niedermayer:
Hi
On Sat, Jun 01, 2024 at 05:19:26PM +0200, Tomas Härdin wrote:
[...]
* Fund professional real live presence on multimedia / FOSS /
buisness related
events.
Also reasonable. I coul
On 2024-06-03 09:51, Martin Storsjö wrote:
Finally, I've also had a somewhat cursed thought about having a
second always-hidden ftyp before the initial moov, which would then
allow you to use the same file for progressive download and DASH/HLS
streaming by using range-requests (e.g. via BYTERAN
> 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 t
> 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 not
> 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 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 3:58 PM, Vittorio Giovara
> wrote:
>
> On Mon, Jun 3, 2024 at 10:57 PM Cosmin Stejerean via ffmpeg-devel <
> [email protected]> wrote:
>
>>
>>
>>> On Jun 3, 2024, at 12:26 PM, Rémi Denis-Courmont
>> wrote:
>&
> 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 <
> [email protected]> wrote:
>
>>> Reposting my question/comment here since Thilo hasn't had a chance to
>>> re
Hi,
On 05.06.24 09:34, Marton Balint wrote:
On Tue, 4 Jun 2024, Ronald S. Bultje wrote:
Hi all,
Anton resigned from the CC [1], leaving an empty spot. The remaining
members of the CC agreed it would be best to fill the spot with the next
runner-up from the last CC Elections.
The last CC ele
> 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 compil
On 2024-06-13 14:50, Martin Storsjö wrote:
On Wed, 5 Jun 2024, Martin Storsjö wrote:
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfini
On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
wrote:
>
> 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()
> legally dead. The function here always calls draw_horiz_band
> in coded order, although the defa
On Fri, Jun 14, 2024 at 1:53 PM Paul B Mahol wrote:
>
>
>
> On Fri, Jun 14, 2024 at 2:41 PM Kieran Kunhya via ffmpeg-devel
> wrote:
>>
>> On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
>> wrote:
>> >
>> > The H.264 decoder does not
On 2024-06-14 13:23, Gyan Doshi wrote:
On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:
On 14/06/2024 12:44, Martin Storsjö wrote:
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02:18 am, Martin Storsjö wrote:
On Thu, 13 Jun 2024, Gyan Doshi wrote:
On 2024-06-13 06:20 pm, Martin St
Hello,
I updated the VapourSynth input module from the old API to the "new" API
(the "new" API was introduced 4 years ago).
The greatest advantage of the new API is, that it requires only a single
import from the VapourSynth library, optimizing it for runtime loading
instead of linking to the li
On 2024-06-17 04:08 pm, Martin Storsjö wrote:
On Sat, 15 Jun 2024, Gyan Doshi wrote:
On 2024-06-15 03:54 am, Dennis Sädtler via ffmpeg-devel wrote:
On 2024-06-14 13:23, Gyan Doshi wrote:
On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:
On 14/06/2024 12:44, Martin Storsjö wrote:
On Fri
On Sun, Jun 16, 2024 at 4:09 PM Michael Niedermayer
wrote:
>
> This or fifo needs to be freed on errors explicitly
> I have not verified that its always safe to call vpx_free() this needs to be
> checked before applying this
>
It should be safe to call into libvpx whether the encoder init
succee
Am 09.06.24 um 21:51 schrieb Theo Fabi:
Video devices categorized by AVFoundation as
'AVCaptureDeviceTypeExternal(Unknown)' (like USB video streams) were not
recognized by libavdevice.
Signed-off-by: Theo Fabi
---
libavdevice/avfoundation.m | 3 +++
1 file changed, 3 insertions(+)
Ok. Will
On 2024-06-20 15:47, Timo Rothenpieler wrote:
On 20/06/2024 15:46, Martin Storsjö wrote:
On Wed, 19 Jun 2024, Martin Storsjö wrote:
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (
> On Jun 19, 2024, at 3:21 AM, Niklas Haas wrote:
>
> On Thu, 23 May 2024 19:50:23 + Cosmin Stejerean via ffmpeg-devel
> wrote:
>> From: Cosmin Stejerean
>>
>> not all clients support metadata compression, output when
>> vdr_dm_metadata_changed fa
ewable but shall
be stashed when pushing.
-Thilo
Josef Zlomek (2):
libavcodec/webp: add support for animated WebP
libavformat/webp: add WebP demuxer
Thilo Borgmann via ffmpeg-devel (6):
avcodec/webp: remove unused definitions
avcodec/webp: separate VP8 decoding
avcodec/bsf: Add
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 50 +--
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index af4ebcec27..c52b9732b4 100644
--- a/libavcodec/webp.c
+++ b/libavcodec
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 7c2a5f0111..af4ebcec27 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -60,8 +60,6 @@
#define VP8X_FLAG_ALPHA
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
Theref
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 146 +++---
1 file changed, 72 insertions(+), 74 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 146d5cb393..bacf605ff2 100644
--- a/libavcodec/webp.c
+++ b/libavcodec
From: Thilo Borgmann via ffmpeg-devel
Splits a packet containing a webp animations into
one non-compliant packet per frame of the animation.
Skips RIFF and WEBP chunks for those packets except
for the first. Copyies ICC, EXIF and XMP chunks first
into each of the packets except for the first
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 42 --
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index bacf605ff2..c8be673060 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
From: Thilo Borgmann via ffmpeg-devel
---
tests/fate/image.mak | 9
tests/ref/fate/webp-anim | 22
tests/ref/fate/webp-chfmt1 | 23
tests/ref/fate/webp-chfmt2 | 106 +
4 files changed, 160 insertions(+)
create mode 100644
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the
Hello,
this is my first patch, I hope I got all the formalities correct.
The current VapourSynth implementation is rarely used, as it links the
VapourSynth library at build time, making the resulting build unable to
run when VapourSynth is not installed. Therefore barely anyone compiles
with Vap
Am 22.06.24 um 08:27 schrieb Stephen Hutchinson:
On 6/21/24 9:37 PM, Stefan Oltmanns via ffmpeg-devel wrote:
The current VapourSynth implementation is rarely used, as it links the
VapourSynth library at build time, making the resulting build unable to
run when VapourSynth is not installed
Am 22.06.24 um 20:23 schrieb Stephen Hutchinson:
On 6/22/24 6:02 AM, Stefan Oltmanns via ffmpeg-devel wrote:
I don't know the extact reason, but VapourSynth is not just a library
like avisynth, but an application that uses Python, meaning a lot of
dependencies.
If we want to be tech
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 a/libavcodec/dov
Hello,
Over at ladybird (the browser that forked off of the serenity os project) they
are beginning to implement video playback based on ffmpeg. They are wondering
also about gpu acceleration and wondering wether vulkan decode would be an
option. The one thing missing though would be vp9 suppor
On 29.06.24 21:54, Yigithan Yigit wrote:
On 29 Jun 2024, at 22:22, Rémi Denis-Courmont wrote:
Le perjantaina 28. kesäkuuta 2024, 23.15.20 EEST Yigithan Yigit a écrit :
---
libavfilter/af_volumedetect.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git
On Thu, Oct 5, 2023 at 3:40 PM Vignesh Venkat wrote:
>
>
>
> On Thu, Oct 5, 2023 at 10:36 AM Vittorio Giovara
> wrote:
>>
>>
>>
>> On Wed, Oct 4, 2023 at 12:40 PM Vignesh Venkatasubramanian via ffmpeg-devel
>> wrote:
>>>
>>&g
Hi Anton,
On Tue, 2023-10-10 at 12:54 +0200, Anton Khirnov wrote:
>
> Quoting Carotti, Elias via ffmpeg-devel (2023-10-02 19:35:09)
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > index 77a9f173b4..4c643c9066 100644
> > --- a/libavcodec/libx264.c
> &
Hello,
I guess this is the right mailing list for mentioning that I uploaded a sample
video with the VideoLAN uploader which is meant for my new ticket #10617 on
ffmpeg. The file is called 01cr.smk.
Regards
___
ffmpeg-devel mailing list
ffmpeg-devel@
On Fri, 2023-10-13 at 16:16 +0200, Anton Khirnov wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> Quoting Carotti, Elias via ffmpeg-de
h->long_ref isn't guaranteed to be contiguously filled. Use the approach
from both vaapi_h264 and vdpau_h264 which goes through the 16 frames in
h->long_ref to find the LTR entries.
Fixes MR2_MW_A.264 from JVT-AVC_V1.
---
libavcodec/vulkan_h264.c | 11 ---
1 file changed, 8 insertions(+)
> On Oct 13, 2023, at 4:00 PM, Vittorio Giovara
> wrote:
>
> TBF this is in part why i was suggesting a new library - I feel like sws is
> affected by bad brading because of these caching issues and imprecise
> conversion, and a new clean api in a new library would make a lot of sense
> in my
> On Oct 13, 2023, at 4:00 PM, Niklas Haas wrote:
>
> That said, if the status quo for the past decades is to for vf_scale
> treat unspecified chroma loc as center-aligned, I am no longer sure if
> suddenly changing this behavior is a good idea.
I'd say that the current default (jpeg chroma lo
On Fri Oct 13, 2023 at 11:59 PM EDT, xyz1001 wrote:
> dxva2 fail to init when decode h264 with baseline profile becase
> `prof_h264_high` does not contains `AV_PROFILE_H264_BASELINE` and
> `dxva_check_codec_compatibility` will return error
prof_h264_high uses either DXVA2_ModeH264_E or DXVA2_Mod
Hi,
the break after the pandemic has stopped for the LinuxDays in Prague this year
as well.
Thus, FFmpeg will be at the Linux Days 2023 in Prague, Czech Republic from
October 7th to 8th!
Find more information on their homepage. The 2023 english version linked here is
still outdated but should
> On Oct 17, 2023, at 7:36 AM, Michael Niedermayer
> wrote:
>
> On Sat, Oct 14, 2023 at 07:53:04PM +0200, Stefano Sabatini wrote:
>>
>> It would be useful at this point to define the process to accept the
>> proposal and potential candidates. We have a technical committee which
>> might take
# RFC: A file format to store generic raw image/video files
Context: Developers and researchers often want to use raw image/video
files, as they avoid the effects of encoding. Dealing with raw
image/video files is typically done using raw files. This is an
operational pain point, as the metadata a
Signed-off-by: Will Wolcott
---
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 1 +
libavutil/channel_layout.h| 2 ++
libavutil/version.h | 2 +-
tests/ref/fate/channel_layout | 1 +
5 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/utils.texi
> On Oct 20, 2023, at 10:53 AM, Michael Koch
> wrote:
>
>> should i add /pipermail/ffmpeg-trac to robots.txt ?
> is there anyone who googles in these ffmpeg trac archives ?
>
> I don't.
I'd imagine anyone wanting to search would search trac itself rather than the
mailing list archive. If i
Hi,
I went to Prag for the LinuxDays Prague 23 [1] by Bus and stayed at the
university Dorm/Hotel.
Bus:54,98 EUR
Hotel: 154,08 EUR (converted from CZK by VISA)
=
Total: 209,06 EUR
Thanks,
Thilo
[1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-October/315777.html
_
Revealed by the patch to support animated webp, the current
frame threading implementation contains a data race.
vp8_lossy_decode_frame() calls ff_vp8_decode_frame() wich
calls ff_thread_finish_setup() to sync its internal slice threading.
The race is happens because vp8_lossy_decode_frame() has to
Am 22.10.23 um 16:30 schrieb Andreas Rheinhardt:
Thilo Borgmann via ffmpeg-devel:
Revealed by the patch to support animated webp, the current
frame threading implementation contains a data race.
No, it doesn't: The current implementation does not call
ff_thread_finish_setup() in vp8.
Hi,
Am 24.10.23 um 23:15 schrieb Anton Khirnov:
Hi all,
as discussed at the dev meeting at VDD, we need to have a series of
votes, the first of which concerns defining when is the GA voter list to
be updated.
As the previous attempt to vote on this was hampered by email delivery
issues, and als
Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont:
Hi,
I am not on the GA, but there are probably people with my locale on the GA. And
it seems that the voting system hits a Perl syntax error if your browser locale
is set to French.
Can you send me a screenshot?
-Thilo
__
Am 25.10.23 um 16:23 schrieb Thilo Borgmann via ffmpeg-devel:
Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont:
Hi,
I am not on the GA, but there are probably people with my locale on the GA.
And it seems that the voting system hits a Perl syntax error if your browser
locale is set to French
Received.
> On Oct 25, 2023, at 07:22, Rémi Denis-Courmont wrote:
>
> Hi,
>
> I am not on the GA, but there are probably people with my locale on the GA.
> And it seems that the voting system hits a Perl syntax error if your browser
> locale is set to French.
> __
> On Oct 25, 2023, at 10:39 AM, Rémi Denis-Courmont wrote:
>
> Objectively, it really does not matter insofar as we are dealing solely with
> non-GA members such as I. But if I were to play devil's advocate, you may be
> serving on a plate a pretext for some future dissatisfied voters to call
Am 25.10.23 um 19:39 schrieb Rémi Denis-Courmont:
Hi,
Le 25 octobre 2023 18:52:31 GMT+03:00, Thilo Borgmann via ffmpeg-devel
a écrit :
Am 25.10.23 um 16:23 schrieb Thilo Borgmann via ffmpeg-devel:
Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont:
Hi,
I am not on the GA, but there are
Am 25.10.23 um 21:31 schrieb Thilo Borgmann via ffmpeg-devel:
Am 25.10.23 um 19:39 schrieb Rémi Denis-Courmont:
Hi,
Le 25 octobre 2023 18:52:31 GMT+03:00, Thilo Borgmann via ffmpeg-devel
a écrit :
Am 25.10.23 um 16:23 schrieb Thilo Borgmann via ffmpeg-devel:
Am 25.10.23 um 16:22 schrieb
Am 26.10.23 um 12:57 schrieb Andreas Rheinhardt:
Thilo Borgmann via ffmpeg-devel:
Hi,
Am 24.10.23 um 23:15 schrieb Anton Khirnov:
Hi all,
as discussed at the dev meeting at VDD, we need to have a series of
votes, the first of which concerns defining when is the GA voter list to
be updated
Am 26.10.23 um 21:02 schrieb Kieran Kunhya:
* If you have some flashy FFmpeg project you want to work on with a cost of
between 5-15k $ then propose it on the mailing list, make yourself ready
for
some paperwork complexities and some public debate as thats the first
time we
try this, th
Am 27.10.23 um 03:28 schrieb Kieran Kunhya:
Hi,
On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel <
[email protected]> wrote:
Of course. FFmpeg has a donations account. So the money is already there
and
already used for the reimbursement requests. Whatever we spent
Hi,
Am 27.10.23 um 12:43 schrieb Rémi Denis-Courmont:
Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer
a écrit :
This is financial sustainability Plan A (SPI)
ATM SPI has like 150k $, we do not activly seek donations, we do not currently
use SPI money to fund any development. SPI
Am 27.10.23 um 13:30 schrieb Rémi Denis-Courmont:
Hi,
Le 27 octobre 2023 14:10:15 GMT+03:00, Thilo Borgmann via ffmpeg-devel
a écrit :
Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer
a écrit :
This is financial sustainability Plan A (SPI)
ATM SPI has like 150k $, we do not
Am 27.10.23 um 13:24 schrieb Jan Ekström:
On Wed, Oct 25, 2023 at 4:14 PM Thilo Borgmann via ffmpeg-devel
wrote:
Hi,
Am 24.10.23 um 23:15 schrieb Anton Khirnov:
Hi all,
as discussed at the dev meeting at VDD, we need to have a series of
votes, the first of which concerns defining when is
Am 27.10.23 um 15:38 schrieb Kieran Kunhya:
On Fri, 27 Oct 2023 at 03:23, Thilo Borgmann via ffmpeg-devel <
[email protected]> wrote:
Am 27.10.23 um 03:28 schrieb Kieran Kunhya:
Hi,
On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel <
[email protected]>
Hi,
FFmpeg is the winner of the 2nd ZEISS FOSS Funding Award [1]!
We have received $1,001.40 that comes with this award in our SPI account.
-Thilo
[1]
https://blogs.zeiss.com/digital-innovation/en/zeiss-strengthens-engagement-in-foss-community/
___
On Fri, 27 Oct 2023 23:37:00 +0800
Zhao Zhili wrote:
> From: Zhao Zhili
>
> Move it to transfer_get_formats.
> ---
> libavutil/hwcontext_vulkan.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/libavutil/hwcontext_vulkan.c
> b/libavutil/hwc
On Fri, 27 Oct 2023 23:37:01 +0800
Zhao Zhili wrote:
> From: Zhao Zhili
>
> av_hwframe_transfer_data try with src_ctx first. If the operation
> failed with AVERROR(ENOSYS), it will try again with dst_ctx. Return
> AVERROR(EINVAL) makes the second step being skipped.
> ---
> libavutil/hwcontext
On Fri, 27 Oct 2023 12:00:10 +0200
David Rosca wrote:
> This allows some optimizations in driver, such as not having to read
> back the data if write-only mapping is requested.
> ---
> v3: Fix another warning
>
> libavutil/hwcontext_vaapi.c | 11 +++
> 1 file changed, 11 insertions(+)
>
Thank you. I have emailed the samples to [email protected]. I will
ping this thread once they are uploaded.
Could somebody please help upload the sample files sent to
[email protected] so that this patch can be merged? Thank
you!
Done, sorry for delay.
Same for the avi
> On Oct 27, 2023, at 5:39 AM, Thilo Borgmann via ffmpeg-devel
> wrote:
>
>> I'll try to post a patch today either inverting their order (which
>> hopefully outputs my community member e-mail), or - since this e-mail
>> is never supposed to apply to a
> On Oct 27, 2023, at 5:39 AM, Thilo Borgmann via ffmpeg-devel
> wrote:
>
>> I'll try to post a patch today either inverting their order (which
>> hopefully outputs my community member e-mail), or - since this e-mail
>> is never supposed to apply to a
> On Oct 27, 2023, at 9:14 AM, Rémi Denis-Courmont wrote:
>
>> Consider FFlabs, you can look at who is being paid by FFlabs, its being
>> mentioned in various places.
>> Then look at what these people do, so you know what they are paid for.
>
> I don't know if FFlabs publishes the payments it
> On Oct 27, 2023, at 12:00 PM, Rémi Denis-Courmont wrote:
>
> Le perjantaina 27. lokakuuta 2023, 21.52.51 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>> With a list of FFLabs consultants the "what they work on" can be extracted
>> from the git log o
1001 - 1100 of 3424 matches
Mail list logo
