On Tue, Apr 26, 2022 at 2:44 AM James Almer wrote:
>
> On 4/25/2022 6:59 PM, Jan Ekström wrote:
> > Support for configuring this was added with version 1.0.0.
> > ---
> > libavcodec/libsvtav1.c | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/libavcode
On 4/25/2022 6:59 PM, Jan Ekström wrote:
Support for configuring this was added with version 1.0.0.
---
libavcodec/libsvtav1.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..49c396387f 100644
--
On 4/25/2022 7:54 PM, Christopher Degawa wrote:
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Dega
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa
---
libavcodec/libsvtav1.c | 10 ++
1
On 4/25/2022 7:37 PM, Christopher Degawa wrote:
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Dega
Yes, only impact using TCP as the transport.
From: ffmpeg-devel on behalf of Tristan
Matthews
Sent: Tuesday, April 19, 2022 7:03 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] libavformat/rtsp: pkt_size option is not
honor
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa
---
libavcodec/libsvtav1.c | 5 +
1 file
Support for configuring this was added with version 1.0.0.
---
libavcodec/libsvtav1.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..49c396387f 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/l
On Sun, Apr 24, 2022 at 2:33 AM Timo Rothenpieler wrote:
>
> - certs.h is gone. Only contains test data, and was not used at all.
> - config.h is renamed. Was seemingly not used, so can be removed.
> - MBEDTLS_ERR_SSL_NO_USABLE_CIPHERSUITE is gone, instead
> MBEDTLS_ERR_SSL_HANDSHAKE_FAILURE wil
On 4/25/2022 6:02 PM, Jan Ekström wrote:
Support for configuring this was added with version 1.0.0.
---
libavcodec/libsvtav1.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..a670dab822 100644
--- a/l
Support for configuring this was added with version 1.0.0.
---
libavcodec/libsvtav1.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..a670dab822 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvt
Thus far I've avoided jumping into this because I genuinely do not care
about Windows' code page shenanigans or what-all, but because this seems
to be zeroing in on one thing in particular...
On 4/25/22 5:03 AM, nil-admir...@mailo.com wrote:
If you were to look at the code, you would've seen tha
> Am 25.04.2022 um 21:14 schrieb Rick Kern :
>
>>
>>{ "a53cc", "Use A53 Closed Captions (if available)", OFFSET(a53_cc),
>> AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, VE },
>> +{ "prio_speed", "prioritize encoding speed", OFFSET(prio_speed),
>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>>
>
Ping for the series, especially the first commit in the series which
should spark some discussion.
Thanks!
Dee
On Wed, Mar 30, 2022 at 2:18 PM Diederick Niehorster wrote:
>
> This patch series implements a series of features, mostly enhancing the
> dshow avdevice, but also adding new functionali
On Mon, 25 Apr 2022, at 20:40, Michael Niedermayer wrote:
> On Mon, Apr 25, 2022 at 08:04:25PM +0200, Jean-Baptiste Kempf wrote:
>> On Mon, 25 Apr 2022, at 19:19, Michael Niedermayer wrote:
>> > On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote:
>> >> On Sat, 23 Apr 2022, at 18
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Monday, April 25, 2022 8:40 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] FFmpeg 5.0 LTS vs 5.1 LTS
>
> On Mon, Apr 25, 2022 at 08:04:25PM +0200,
On Sat, Apr 23, 2022 at 8:31 AM Simone Karin Lehmann
wrote:
>
>
> > Am 22.04.2022 um 18:52 schrieb Thilo Borgmann :
> >
> >
>
> > For that version I get:
> >
> > libavcodec/videotoolboxenc.c:1153:39: error: use of undeclared
> identifier 'kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuali
Am 25.04.22 um 00:08 schrieb Thilo Borgmann:
Am 25.04.22 um 00:03 schrieb Thilo Borgmann:
Am 24.04.22 um 19:28 schrieb Thilo Borgmann:
Am 23.04.22 um 15:32 schrieb Thilo Borgmann:
Hi,
v3 updated to current HEAD.
Named blurdetect filter now.
Minor fixes on allocation and removed -f option.
On Mon, Apr 25, 2022 at 08:04:25PM +0200, Jean-Baptiste Kempf wrote:
> On Mon, 25 Apr 2022, at 19:19, Michael Niedermayer wrote:
> > On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote:
> >> On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote:
> >> > Do people prefer that 5.0 b
On 4/25/2022 2:19 PM, Michael Niedermayer wrote:
On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote:
On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote:
Do people prefer that 5.0 becomes LTS or the next (5.1) ?
Or something else ?
My understanding of the consensus wa
On Mon, 25 Apr 2022, at 19:19, Michael Niedermayer wrote:
> On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote:
>> On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote:
>> > Do people prefer that 5.0 becomes LTS or the next (5.1) ?
>> > Or something else ?
>>
>> My understandi
On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote:
> On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote:
> > Do people prefer that 5.0 becomes LTS or the next (5.1) ?
> > Or something else ?
>
> My understanding of the consensus was;
> - 5.0 in Dec/Jan
> - 5.1 in Jul with A
On Mon, Apr 25, 2022 at 3:19 PM Jan Ekström wrote:
>
> On Mon, Apr 25, 2022 at 2:33 PM Jan Ekström wrote:
> >
> > On Mon, Apr 25, 2022 at 1:36 PM Jan Ekström wrote:
> > >
> > > On Tue, Apr 19, 2022 at 11:06 PM Marton Balint wrote:
> > > >
> > > >
> > > >
> > > > On Tue, 19 Apr 2022, Jan Ekström
It's missing in the table of contents of the documentation.
___
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
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Monday, April 25, 2022 3:02 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Monday, April 25, 2022 2:52 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi an
On Mon, 25 Apr 2022, Hendrik Leppkes wrote:
On Mon, Apr 25, 2022 at 1:12 PM Soft Works wrote:
From my point of view:
ffmpeg is already working pretty well in handling long file paths (also with
Unicode characters) when pre-fixing paths with \\?\, and this is working
on all Windows versions wi
On Mon, Apr 25, 2022 at 1:12 PM Soft Works wrote:
>
> From my point of view:
> ffmpeg is already working pretty well in handling long file paths (also with
> Unicode characters) when pre-fixing paths with \\?\, and this is working
> on all Windows versions without all the caveats, requirements and
On Mon, Apr 25, 2022 at 2:33 PM Jan Ekström wrote:
>
> On Mon, Apr 25, 2022 at 1:36 PM Jan Ekström wrote:
> >
> > On Tue, Apr 19, 2022 at 11:06 PM Marton Balint wrote:
> > >
> > >
> > >
> > > On Tue, 19 Apr 2022, Jan Ekström wrote:
> > >
> > > > On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström wrote
On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote:
> Do people prefer that 5.0 becomes LTS or the next (5.1) ?
> Or something else ?
My understanding of the consensus was;
- 5.0 in Dec/Jan
- 5.1 in Jul with API additions, but no ABI/behavior breakage
- 6.0 in Dec 22 with ABI/API/behavior br
On Mon, Apr 25, 2022 at 1:36 PM Jan Ekström wrote:
>
> On Tue, Apr 19, 2022 at 11:06 PM Marton Balint wrote:
> >
> >
> >
> > On Tue, 19 Apr 2022, Jan Ekström wrote:
> >
> > > On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström wrote:
> > >>
> > >> On Tue, Apr 19, 2022 at 3:00 AM Marton Balint wrote:
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of nil-
> admir...@mailo.com
> Sent: Monday, April 25, 2022 11:52 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
>
> > Again, y
On Tue, Apr 19, 2022 at 11:06 PM Marton Balint wrote:
>
>
>
> On Tue, 19 Apr 2022, Jan Ekström wrote:
>
> > On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström wrote:
> >>
> >> On Tue, Apr 19, 2022 at 3:00 AM Marton Balint wrote:
> >> >
> >> >
> >> >
> >> > On Thu, 14 Apr 2022, Jan Ekström wrote:
> >> >
> On Mar 31, 2022, at 2:48 PM, zhilizhao(赵志立) wrote:
>
> Ping for patch 1/2. rcombs has reviewed the patch on IRC. I decided to
> drop patch 2/2.
>
>
>> 11:05 rcombs: quink_: seems reasonable to me
>> 11:06 quink_: rcombs: thanks : )
>> 11:06 rcombs: not entirely sure what the deal with the s
Pushed as f2724d2b6958a4e62afa10157f2b19566239e12d
On 2022-04-25 12:09 am, Vignesh Venkatasubramanian wrote:
AVIF still and animations are now supported by the MOV parser.
Add the "avif" extension to the list of supported extensions to
AVInputFormat.
Signed-off-by: Vignesh Venkatasubramanian
-
> On Mar 30, 2022, at 2:04 AM, Zhao Zhili wrote:
>
> The stsc_index is checked and updated for the next sample. If the
> next sample needs to update stsd_index and stsc_index, then only
> stsc_index is updated, which leads to a missing
> AV_PKT_DATA_NEW_EXTRADATA. For example, the sample in th
> Again, you have deleted my asking for an example scenario
> and which library would need to be loaded from a long path.
Because I don't think that an example would be relevant. Generic library
function must be able to load a library, no matter the location.
You're talking as if MAX_PATH limited
On Fri, 2022-04-01 at 17:24 +0800, Tong Wu wrote:
> For hwmap between qsv and d3d11va, The mfxHDLPair information should be
> put into texture_infos when deriving from qsv context. Moreover, when
> uploading from rawvideo, the ways that the textures are created are
> different, bindflag assertions
> -Original Message-
> From: ffmpeg-devel On Behalf Of nil-
> admir...@mailo.com
> Sent: Monday, April 25, 2022 11:04 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
>
> > You normal
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul
> B Mahol
> Sent: Monday, April 25, 2022 10:01 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] FFmpeg 5.0 LTS vs 5.1 LTS
>
> On Mon, Apr 25, 2022 at 12:48 AM Soft Works
> w
> You normally don't load libraries from such longs paths.
And? 80% of FFmpeg functionality is normally not used.
> But file IO is a fundamental feature where a common and predictable
> behavior is crucial.
You're talking as if the manifest change somehow broke or fundamentally altered
file IO,
This patch fixes a wrong type of BTI landing pad when branching to
functions instantiated via the fft*_neon macro.
Although the previously employed paciasp instruction serves as a landing
pad, for the ways that this function is invoked it is the wrong type, resulting
in an unexpected termination o
On Mon, Apr 25, 2022 at 12:48 AM Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Saturday, April 23, 2022 6:36 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: [FFmpeg-devel] FFmpeg
Nicely applied, many thanks!
Sent: Sunday, April 24, 2022 at 11:04 PM
From: "James Almer"
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] avdevice/dshow: reuse unused variables.
On 4/19/2022 5:13 AM, Diederick Niehorster wrote:
> Fix for f125c504d8fece6420bb97767f9e72414c26312a,
44 matches
Mail list logo
