On Fri, Sep 29, 2023 at 1:38 PM Frank Plowman wrote:
> libavutil/x86/x86inc.asm | 10 ++
> 1 file changed, 10 insertions(+)
LGTM.
As a side note https://code.videolan.org/videolan/x86inc.asm is the
upstream repo for x86inc.asm.
___
ffmpeg-deve
0cd8769207f utilized the rc_algorithm member of the kvz_config struct, which
was introduced in Kvazaar 2.0.0. This patch bumps the minimum version of
Kvazaar to 2.0.0 so that FFmpeg compiles successfully.
Signed-off-by: John Mather
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion
This patch makes the libkvazaar encoder respect color settings that are
present on the codec context, including color range, primaries, transfer
function and colorspace.
---
This addresses the issues raised in v2.
* The unspecified conditions have been removed as they were
unnecessary.
* Added
> Hi,
> please find attached a patch to propagate the SSE for a frame into
> the
> encoder stats.
> Since libx264 already provides PSNR values, this is done by basically
> inverting the formula to recover the SSE values.
>
> Would it be possible to also append other values to the errors
> vector?
On Tue, Oct 3, 2023 at 7:50 PM Nicolas George wrote:
> More precisely, I now strongly believe that democracy is a terrible way
> to run a project like FFmpeg.
Why are you part of a community project if you don't believe the
community is capable of running a project?
Why not start your own project
On Thu, Sep 28, 2023 at 2:05 AM Ronald S. Bultje wrote:
>
> Hi Vignesh,
>
> On Thu, Sep 28, 2023 at 12:14 AM Vignesh Venkatasubramanian via ffmpeg-devel
> wrote:
>>
>> SVT-AV1 does not support requesting keyframes at arbitrary points
>> by setting pic_type
SVT-AV1 does not support requesting keyframes at arbitrary points
by setting pic_type to EB_AV1_KEY_PICTURE. So set force_key_frames
to 1 only when gop_size == 1.
Please see the comments in
https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 for a bit more
details.
Signed-off-by: Vignesh Venkat
On Fri, Sep 29, 2023 at 12:21 PM Michael Niedermayer
wrote:
>
> On Tue, Apr 25, 2023 at 03:22:50PM -0700, Vignesh Venkatasubramanian wrote:
> > On Mon, Apr 17, 2023 at 4:18 PM Michael Niedermayer
> > wrote:
> > >
> > > On Mon, Apr 17, 2023 at 12:36:26PM +0200, Anton Khirnov wrote:
> > > > Quoting
On Tue, Sep 26, 2023 at 10:37 AM Vignesh Venkatasubramanian
wrote:
>
> They are similar to AVIF images (both use the HEIF container).
> The only additional work needed is to parse the hvcC box and put
> it in the extradata.
>
> With this patch applied, ffmpeg (when built with an HEVC decoder)
> is
This is not allowed per the spec.
Signed-off-by: Vignesh Venkatasubramanian
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 294c864fbd..a8f57f9281 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4892,6 +4892,8 @@
On Tue, Oct 3, 2023 at 6:32 PM Vittorio Giovara
wrote:
>
> On Tue, Oct 3, 2023 at 8:30 PM Steven Liu wrote:
>
> > > > 2.42.0.515.g380fc7ccd1-goog
> > > >
> > >
> > > Any comments/objections on merging this?
> >
> >
> > Can this patch support tiled hevc coded or sequence heif？=
> >
>
> I believe t
On Tue, Oct 3, 2023 at 7:35 PM Leo Izen wrote:
>
> On 9/26/23 13:37, Vignesh Venkatasubramanian via ffmpeg-devel wrote:
> > They are similar to AVIF images (both use the HEIF container).
> > The only additional work needed is to parse the hvcC box and put
> > it in the
They are similar to AVIF images (both use the HEIF container).
The only additional work needed is to parse the hvcC box and put
it in the extradata.
With this patch applied, ffmpeg (when built with an HEVC decoder)
is able to decode the files in
https://github.com/nokiatech/heif/tree/gh-pages/cont
On Tue, Oct 3, 2023 at 3:56 PM Vignesh Venkat wrote:
>
> On Fri, Sep 29, 2023 at 12:21 PM Michael Niedermayer
> wrote:
> >
> > On Tue, Apr 25, 2023 at 03:22:50PM -0700, Vignesh Venkatasubramanian wrote:
> > > On Mon, Apr 17, 2023 at 4:18 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > On Mon
On Tue, Oct 3, 2023 at 5:30 PM Steven Liu wrote:
>
> Vignesh Venkat via ffmpeg-devel 于2023年10月4日
> 周三06:57写道：
>
> > On Tue, Sep 26, 2023 at 10:37 AM Vignesh Venkatasubramanian
> > wrote:
> > >
> > > They are similar to AVIF images (both use the HEIF
They are similar to AVIF images (both use the HEIF container).
The only additional work needed is to parse the hvcC box and put
it in the extradata.
With this patch applied, ffmpeg (when built with an HEVC decoder)
is able to decode the files in
https://github.com/nokiatech/heif/tree/gh-pages/cont
On Wed, Oct 4, 2023 at 10:23 AM Ronald S. Bultje wrote:
>
> Hi,
>
> On Tue, Oct 3, 2023 at 6:53 PM Vignesh Venkatasubramanian via ffmpeg-devel
> wrote:
>>
>> SVT-AV1 does not support requesting keyframes at arbitrary points
>> by setting pic_type to EB_AV1_KEY
> On Oct 4, 2023, at 7:37 PM, Lynne wrote:
>
> 2048 is just more widely encountered. I'm posting these patches
> to get an opinion:
> - do we cut nothing at all (currently)
> - do we cut 1024 (required by the standard/algorithm, and currently what our
> AAC ENcoder outputs)
> - do we cut 2
On Thu, 5 Oct 2023 23:26:38 +0200 (CEST)
Lynne wrote:
> This fixes filtering on Nvidia.
>
> Patch attached.
>
Tested locally. Filtering works and vulkan validation passes.
Ship it!
--phil
___
ffmpeg-devel mailing list
[email protected]
https:
On Thu, Oct 5, 2023 at 10:58 AM Andreas Rheinhardt
wrote:
>
> Vignesh Venkat via ffmpeg-devel:
> > On Tue, Oct 3, 2023 at 9:40 PM Vittorio Giovara
> > wrote:
> >>
> >>
> >>
> >> On Wed, Oct 4, 2023 at 12:02 AM Vignesh Venkat via ffmpeg-de
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:
>
>> They are similar to AVIF images (both use the HEIF container).
>> The only additional work needed is to parse the hv
Added the codec_name field, in which the unprocessed, not-interpreted codec
name is stored.
This is useful when codecs that are not handled by the libav
(i.e. AV_CODEC_ID_NONE) are encountered, since the application might still
want to handle them.
Having this field allows the application to deter
Added the codec_name field, in which the unprocessed, not-interpreted codec
name is stored.
This is useful when codecs that are not handled by the libav
(i.e. AV_CODEC_ID_NONE) are encountered, since the application might still
want to handle them.
Having this field allows the application to deter
On 03/07/2024 10:02, Hendrik Leppkes wrote:
On Wed, Jul 3, 2024 at 9:48 AM Bernardo Pilarz via ffmpeg-devel
wrote:
Added the codec_name field, in which the unprocessed, not-interpreted codec
name is stored.
This is useful when codecs that are not handled by the libav
(i.e. AV_CODEC_ID_NONE
On 03/07/2024 11:10, Anton Khirnov wrote:
Quoting Bernardo Pilarz via ffmpeg-devel (2024-07-03 10:10:15)
+char *codec_name;
const struct AVCodec *codec;
enum AVCodecID codec_id; /* see AV_CODEC_ID_xxx */
Adding a new field here is an ABI break, it would need to go at
On 03/07/2024 11:56, Bernardo Pilarz via ffmpeg-devel wrote:
On 03/07/2024 11:10, Anton Khirnov wrote:
Quoting Bernardo Pilarz via ffmpeg-devel (2024-07-03 10:10:15)
+ char *codec_name;
const struct AVCodec *codec;
enum AVCodecID codec_id; /* see AV_CODEC_ID_xxx
Hello,
this is revised patch, to sum up the changes:
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 VapourSynth activated.
Connecting to an RTSP stream will now cause the SDP attributes of each media
stream to be stored in the codecpar of the relative AVStream.
The SDP attributes are stored in the coded_side_data using the (new) type
AV_PKT_DATA_SDP_ATTRIBUTES (AVPacketSideDataType enum).
Signed-off-by: Bernardo Pila
> On Jul 9, 2024, at 13:47, Helmut K. C. Tessarek wrote:
>
> I'm very sorry to bother the dev list with this, but this is the 2nd time in
> less than a year that the min version of macOS was changed in videotoolbox.
>
> 2023-09-22: macOS 10.13
> now: macOS 12
>
> Will ffmpeg soon only compil
Connecting to an RTSP stream will now cause the SDP attributes of each media
stream to be stored in the codecpar of the relative AVStream.
The SDP attributes are stored in the coded_side_data using the (new) type
AV_PKT_DATA_SDP_ATTRIBUTES (AVPacketSideDataType enum).
Signed-off-by: bpilarz
---
Connecting to an RTSP stream will now cause the SDP attributes of each media
stream to be stored in the codecpar of the relative AVStream.
The SDP attributes are stored in the coded_side_data using the (new) type
AV_PKT_DATA_SDP_ATTRIBUTES (AVPacketSideDataType enum).
Signed-off-by: Bernardo Pila
Connecting to an RTSP stream will now cause the SDP attributes of each media
stream to be stored in the codecpar of the relative AVStream.
The SDP attributes are stored in the coded_side_data using the (new) type
AV_PKT_DATA_SDP_ATTRIBUTES (AVPacketSideDataType enum).
Signed-off-by: bpilarz
---
Hi,
I've tried to push this patch several times, but it looks like my email client
is messing up the diff, and patchwork isn't able to apply it.
On 09/07/2024 12:02, Bernardo Pilarz via ffmpeg-devel wrote:
Connecting to an RTSP stream will now cause the SDP attributes of each media
Hi,
FFmpeg will have a booth at the next IBC from September 13th to 16th
2024 in Amsterdam [1]!
We received a corporate sponsorship for the booth, so there are no costs
for the FFmpeg project to it (and no obligations, of course).
FFmpeg developers are welcome to join in and help man the bo
On 2024-06-02 11:27 +0200, Alexander Strasser via ffmpeg-devel wrote:
> 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 o
On 2024-07-10 15:51 +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-10 15:44:47)
> > Do you still object to a 32bit check on width and height ?
> > If not i intend to apply a patch adding such limits
> > If you object i will take this to the TC
>
> In my first reply in this threa
> 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 deletion(-)
> 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
> @@ -26
> 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
>
> ---
> 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
> --- a/libavformat/mpegts.
> 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
> +++ b/
> 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 Bour
> 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 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 bel
> 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 <
> [email protected]> wrote:
>
>>
>>
>>> On Jul 16, 2024, at 4:58 PM, Zhao Zhili wrote:
>>>
>>>
&g
Hello,
I adressed the issues/concerns that were raised with the first revision
of the patch.
Any feedback? Did I do something wrong?
Best regards
Stefan
Am 06.07.24 um 23:08 schrieb Stefan Oltmanns via ffmpeg-devel:
Hello,
this is revised patch, to sum up the changes:
The current
AviSynth (or better VapourSynth) as filter sounds great, but is it possible?
The reason why input plugins (like FFmpegSource2) in
AviSynth/VapourSynth create an index file in a first pass is to allow
frame-accurate random access to the video. Also the exact number of
frames of a clip has to be kno
Hi Ramiro,
Am 18.07.24 um 13:08 schrieb Ramiro Polla:
Hi Stefan,
[...]
+
+#include
+
struct VSState {
VSScript *vss;
};
+typedef const VSSCRIPTAPI *(*VSScriptGetAPIFunc)(int version);
+
+typedef struct VSScriptLibrary {
+ void *library;
+ const VSSCRIPTAPI *vssapi;
+} VSScriptL
Hi Ramiro,
Am 18.07.24 um 15:04 schrieb Ramiro Polla:
[...]
+static VSScriptLibrary vs_script_library;
Does vs_script_library have to be a global?
I think it has to: ffmpeg allows multiple input files, in case you open
two VapourSynth files you want to load the Library only once.
It sho
Am 18.07.24 um 16:21 schrieb Ramiro Polla:
On Thu, Jul 18, 2024 at 3:41 PM Stefan Oltmanns via ffmpeg-devel
wrote:
Am 18.07.24 um 15:04 schrieb Ramiro Polla:
[...]
+static VSScriptLibrary vs_script_library;
Does vs_script_library have to be a global?
I think it has to: ffmpeg allows
at
runtime: VapourSynth is based on plugins that are loaded on runtime, so
it won't work on those platforms anyway.
Best regards
Stefan
Am 18.07.24 um 13:25 schrieb Anton Khirnov:
Quoting Stefan Oltmanns via ffmpeg-devel (2024-07-18 11:37:56)
Hello,
I adressed the issues/concerns that w
hi,
a fellow named DANIEL KAISER (EMPH I DID NOT CONTRIBUTE ANYTHING HERE) took
some time to contribute an 'movflags' option for people STUPID enough to buy
APPUL products that, of course, have an equally stupid and BUZZY name like
RETINA.
since it works and it would be convenient to mainline,
that file has nothing to do with the patch.
but i think you may have been outed as an APPUL user.
PREPARE THE SOCKS AND SOAP BARS, LADS
Thanks,
Gagan
> On Jul 20, 2024, at 5:38 PM, Michael Niedermayer
> wrote:
>
> On Sat, Jul 20, 2024 at 09:45:08AM -0300, James Almer wrote:
>> Signed-off-by:
oh ADHD fail my bad.
i'll unsub now haha. but please do add the "RETINA" functionality to ffmpeg.
thanks and bye
Thanks,
Gagan
> On Jul 20, 2024, at 6:17 PM, James Almer wrote:
>
> On 7/20/2024 8:38 PM, Michael Niedermayer wrote:
>> On Sat, Jul 20, 2024 at 09:45:08AM -0300, James Almer wrote
Am 18.07.24 um 17:23 schrieb [email protected]:
Well, the DLL directory is added to PATH by the VapourSynth installer,
but for safety reasons ffmpeg explictly tells the LoadLibrary function
to only search the application directory and system32, quote from
w32dlfcn.h:
/**
* Safe function u
> On Jul 22, 2024, at 06:04, Sean McGovern wrote:
>
> Hi Marvin,
>
>
> On Tue, Jul 9, 2024, 10:47 Marvin Scholz wrote:
>
>> I've accidentally used API not available on the checked version.
>> Additionally check for the SDK to be new enough to even have the
>> CVImageBufferCreateColorSpaceF
> On Jul 22, 2024, at 06:45, Gnattu OC via ffmpeg-devel
> wrote:
>
>
>
>> On Jul 22, 2024, at 06:04, Sean McGovern wrote:
>>
>> Hi Marvin,
>>
>>
>> On Tue, Jul 9, 2024, 10:47 Marvin Scholz wrote:
>>
>>> I've accid
Am 22.07.24 um 00:15 schrieb Hendrik Leppkes:
On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
wrote:
Am 18.07.24 um 17:23 schrieb [email protected]:
Well, the DLL directory is added to PATH by the VapourSynth installer,
but for safety reasons ffmpeg explictly tells the
Am 22.07.24 um 14:13 schrieb Ramiro Polla:
On Mon, Jul 22, 2024 at 12:15 AM Hendrik Leppkes wrote:
On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
wrote:
Am 18.07.24 um 17:23 schrieb [email protected]:
Well, the DLL directory is added to PATH by the VapourSynth
Am 22.07.24 um 08:57 schrieb Anton Khirnov:
Quoting Stefan Oltmanns (2024-07-18 14:12:42)
Hello Anton,
can you eloborate on that? What is unacceptable with my patch that is
perfectly fine in the AviSynth input module? It's the very same concept.
It's not perfectly fine in avisynth, I dislike
Hello,
this is revised patch, this is the first part that just updates to the
API v4 of VapourSynth.
Changes in API v4:
-All functions previously in header are now part of the "vssapi" object
-Renames of different types and functions
-YCoCg is not treated as different format to YUV anymore
-Some
amount windows-specific code.
Tested with 2 VapourSynth inputs on these platforms, no problems and
clean exit:
-Linux x86_64 (Ubuntu 22.04)
-Windows 10 x86_64
-macOS 14 aarch64
Best regards
Stefan
Am 23.07.24 um 16:51 schrieb Stefan Oltmanns via ffmpeg-devel:
Hello,
this is revised patch, this
Increase the tolerance from 10 ulp to 11 ulp. This fixes occasional
errors for some inputs; the errors could be reproduced on
aarch64/neon builds, with "checkasm --test=ac3dsp 3446175925".
---
tests/checkasm/ac3dsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/checkas
Am 28.07.24 um 15:09 schrieb Ramiro Polla:
if (st->codecpar->format == AV_PIX_FMT_NONE) {
- av_log(s, AV_LOG_ERROR, "Unsupported VS pixel format %s\n",
info->format->name);
+ if(vs->vsapi->getVideoFormatName(&info->format, vsfmt))
+ av_log(s, AV_LOG_ERROR, "Unsupport
Am 28.07.24 um 15:15 schrieb Ramiro Polla:
+ void *vslibrary = NULL;
+#ifdef _WIN32
+ const HKEY hkeys[] = {HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE};
+ LONG r;
+ WCHAR vss_path[512];
+ DWORD buf_size = sizeof(vss_path) - 2;
+ char *vss_path_utf8;
+ int i;
+
+ for (i = 0; i <
Since ffmpeg 6.1 video stats are accidentally hidden from progress output
if no filters are used.
This patch re-enables video stats (like frames=) in the progress output.
---
Changelog| 1 +
fftools/ffmpeg.c | 8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Chang
Replaced by: https://ffmpeg.org//pipermail/ffmpeg-devel/2024-August/331962.html
> On Aug 2, 2024, at 06:47, [email protected] wrote:
>
>
>
> On 2 Aug 2024, at 0:25, gnattu via ffmpeg-devel wrote:
>
>> From: Gnattu OC
>>
>> Allocate a dedicated attachm
Since ffmpeg 6.1 video stats are accidentally hidden from streamcopy progress
output.
This patch re-enables video stats (like frames=) in the progress output.
---
fftools/ffmpeg.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index
> On Jul 31, 2024, at 5:14 AM, Niklas Haas wrote:
>
> On Sun, 28 Jul 2024 12:25:06 +0200 Niklas Haas wrote:
>> From: Niklas Haas
>>
>> ---
>> libavutil/dovi_meta.h | 28 +++-
>> 1 file changed, 15 insertions(+), 13 deletions(-)
>>
>> diff --git a/libavutil/dovi_meta.h
Am 30.07.24 um 16:12 schrieb Ramiro Polla:
On Mon, Jul 29, 2024 at 5:56 AM Stefan Oltmanns via ffmpeg-devel
wrote:
Am 28.07.24 um 15:15 schrieb Ramiro Polla:
I think calling win32_dlopen() with a full path will be problematic for
systems without KB2533623. win32_dlopen() might need to be
thanks you Mark! will follow up on libva changes first.
David
On 2024-08-11 14:42, Mark Thompson wrote:
On 11/08/2024 19:27, Mark Thompson wrote:
On 30/07/2024 21:02, David (Ming Qiang) Wu via ffmpeg-devel wrote:
AV1Profile2 VAAPI is supported and tested on AMD VCN5.
Signed-off-by: David
> On Aug 15, 2024, at 19:59, Zhao Zhili wrote:
>
>
>
>> On Aug 10, 2024, at 14:06, gnattu via ffmpeg-devel
>> wrote:
>>
>> In vtenc_populate_extradata, supported_props should always be released
>> to avoid memory leak.
>>
>> Re
The need for this patch arose while attempting to live stream a DASH
feed with low latency. Since I did not use a timeline, having an
accurate start time became crucial. Without it, the player might
download segments at incorrect times. Currently, the start time is set
to the system time, which mig
---
libavformat/dashenc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index d4a6fe0304..e586e934cb 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -204,6 +204,7 @@ typedef struct DASHContext {
AVRa
When encoding a DASH stream in live ("dynamic") mode without timeline,
the field "availabilityStartTime" is set to the system time. The new
options allows the libavformat user to pass a specific time to be used
instead of the system time.
---
libavformat/dashenc.c | 9 -
1 file changed, 8
> On Aug 21, 2024, at 07:17, [email protected] wrote:
>
>
>
> On 21 Aug 2024, at 0:43, Erik Bråthen Solem wrote:
>
>> avfoundation.m uses constants prefixed with AVMediaType on Mac OS X > 10.6.
>> In 10.7 through 10.12 their type was NSString*, but starting with 10.13 a
>> new AVMediaType st
On Mon, Aug 19, 2024 at 7:31 PM Timo Rothenpieler wrote:
>
> On 19.08.2024 16:23, Araz Iusubov wrote:
> > From: Evgeny Pavlov
> >
> > This commit increase precision of Sleep() function on Windows.
> > This fix reduces the sleep time on Windows to improve AMF encoding
> > performance on low resolu
Am 23.08.24 um 14:25 schrieb Ramiro Polla:
I finally managed to test the patches on a real Windows system.
They both look good to me, I'll apply them in a couple of days if
there are no other comments.
It would be helpful to write a page in the trac wiki with a basic
howto and common pitfalls.
On Wed, Aug 28, 2024 at 10:13 AM Michael Niedermayer
wrote:
>
> Text was stolen from the linux kernel
> This is thus identical to the kernel just a different more compact format.
> I am very happy also to switch the file entirely to the format of the linux
> kernel maintainer list
> if people pre
> On Aug 30, 2024, at 3:15 AM, Niklas Haas wrote:
>
> N/A:
> - ayuv, yuv4, y41p, v308, v210, v410, v408 (headerless)
> - pgmyuv (headerless)
> - prores, prores_aw, prores_ks (?)
> - rawvideo, bitpacked (headerless)
> - vnull, wrapped_avframe (pseudocodecs)
AFAIK while ProRes doesn't have taggi
Hi,
Indeed, I have not followed the ML nor looked at the ffmpeg sources
since many years, so yes, you should remove me from MAINTAINERS.
Thanks.
On dim., sept. 1 2024 at 16:27:22 +02:00:00, Michael Niedermayer
wrote:
Aurelien last activity in git is from 2017, last activity on the ML
is fr
On Wed, Sep 4, 2024 at 4:10 AM Niklas Haas wrote:
>
> From: Niklas Haas
>
> ---
> libavcodec/libvpxenc.c | 26 +++---
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
lgtm
___
ffmpeg-devel mailing list
[email protected]
h
On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
> This commit adds the common Vulkan video encoding framework.
> It makes full use of the asynchronous features of our new common
> hardware encoding code, and of Vulkan.
> The code is able to handle anything from H26
On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
> This commit adds the first Vulkan hardware encoder.
>
> Currently, P, and **B**-frames are supported. This marks the
> first implementation to support both.
>
> The encoder has feature-parity with VAAPI.
On Wed Sep 11, 2024 at 12:03 AM EDT, Lynne wrote:
> On 10/09/2024 15:29, Benjamin Cheng wrote:
> > On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
> >> This commit adds the common Vulkan video encoding framework.
> >> It makes full use of the async
On Tue, Jul 09, 2024 at 09:19:54AM +, Anton Khirnov wrote:
> ffmpeg | branch: master | Anton Khirnov | Fri Jul 5
> 12:30:04 2024 +0200| [10185e2d4c1e9839bc58a1d6a63c861677b13fd0] | committer:
> Anton Khirnov
>
> fftools/ffmpeg_mux_init: default to input timebase for streamcopy
>
> Stop tr
Am 17.12.23 um 23:51 schrieb Michael Niedermayer:
On Sat, Dec 16, 2023 at 09:13:21AM +0100, Thilo Borgmann via ffmpeg-devel wrote:
[...]
+// get number of bytes from cur to '\0'
+static int buf_get_zero(FsyncContext *ctx)
maybe doxygen syntax would make sense for comments
Am 18.12.23 um 02:04 schrieb Stefano Sabatini:
On date Saturday 2023-12-16 09:13:21 +0100, ffmpeg-devel Mailing List wrote:
---
Changelog| 1 +
MAINTAINERS | 1 +
configure| 2 +
doc/filters.texi | 33 +
libavfilter/Makefile
On Friday, December 15th, 2023 at 11:18 PM, Leo Izen wrote:
> On 12/15/23 16:31, Zsolt Vadász via ffmpeg-devel wrote:
>
> > On Friday, December 15th, 2023 at 10:12 PM, Leo Izen [email protected]
> > wrote:
> >
> > > On 12/15/23 11:40, Zsolt Vadász via ffmp
Am 15.12.23 um 20:59 schrieb Thilo Borgmann via ffmpeg-devel:
Still images fixed, includes FATE tests, VP8 decoder decoupled so there are no
more data races, fixed more asserts, fixed ffprobe regression, removed
unnecessary parser changes, put the whole animated sequence into one packet
On Tue, Dec 19, 2023 at 1:02 PM Martin Storsjö wrote:
> This replaces the riscv specific handling from
> 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is
> reverted, together with 286d6742218ba0235c32876b50bf593cb1986353)
> with a different implementation of the same (plus a bit more
---
configure | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libjxlenc.c | 226 ++---
3 files changed, 189 insertions(+), 39 deletions(-)
diff --git a/configure b/configure
index 7d2ee66000..2d27d8015a 100755
--- a/configure
+++ b/configure
@@
This patchset adds support for encoding animated JPEG XL images via a
new encoder (libjxl_anim). When using the encoder, the output format
needs to be set to raw video, as shown below:
`ffmpeg -i sample.gif -c:v libjxl_anim -f rawvideo out.jxl`
V3 changes:
- Renamed encoder to libjxl_anim for cons
On Thu, Dec 21, 2023 at 9:16 PM Rémi Denis-Courmont wrote:
> > +checkasm_fail_func("%s",
> > + s == SIGFPE ? "fatal arithmetic error" :
> > + s == SIGILL ? "illegal instruction" :
> > + s == SIGBUS ? "bus error"
On Fri, Dec 22, 2023 at 7:20 AM Rémi Denis-Courmont wrote:
> >> > +checkasm_fail_func("%s",
> >> > + s == SIGFPE ? "fatal arithmetic error" :
> >> > + s == SIGILL ? "illegal instruction" :
> >> > + s == SIGBUS ?
Am 21.12.23 um 23:18 schrieb Andreas Rheinhardt:
Thilo Borgmann via ffmpeg-devel:
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
Still images fixed, includes FATE tests, VP8 decoder decoupled so there are no
more data races, fixed more asserts, fixed ffprobe regression, removed
unnecessary parser changes, put the whole animated sequence into one packet.
Patch 4/6 is still there for making changes in lavc/webp reviewable b
---
libavcodec/webp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 54b3fde6dc..4fd107aa0c 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -59,8 +59,6 @@
#define VP8X_FLAG_ALPHA 0x10
#define VP8X_FLAG_ICC
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
---
libavcodec/webp.c | 142 +++---
1 file changed, 70 insertions(+), 72 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 4f989b8f0a..a2e6e199a7 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1378,7 +1378,76 @@ static int vp
1601 - 1700 of 3424 matches
Mail list logo
