Hi,
The linked version is an old version of the example. Latest version is
in git doc/encode_video.c.
It runs ok on Mac.
Can you try again with the newest version?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/
This patch series introduces the new API that was discussed in my previous
series, and starts working towards a new, graph-based scaler dispatch
mechanism. This currently piggybacks off of existing swscale logic, but I
plan on incrementally rewriting the high-level innards going forwards.
In order
From: Niklas Haas
Slightly more convenient, especially for the upcoming refactor which will
turn SwsContext into a public struct.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale.h | 36 ++--
1 file changed, 18 insertions(+), 1
From: Niklas Haas
Group them into an enum rather than random #defines, and document their
behavior a bit more obviously.
Of particular note, I discovered that SWS_DIRECT_BGR is not referenced
anywhere else in the code base. As such, I have moved it to the deprecated
section, alongside SWS_ERROR_
From: Niklas Haas
Merely a convenience wrapper around sws_freeContext(). The name change is for
parity with the other sws_* functions.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale.h | 7 +++
libswscale/utils.c | 10 ++
2 files changed, 17 i
From: Niklas Haas
I want to start grouping "legacy" functions which I tend to deprecate
together, away from the new ones.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale.h | 34 +-
1 file changed, 17 insertions(+), 17 deletion
From: Niklas Haas
This interface has been designed from the ground up to serve as a new
framework for dispatching various scaling operations at a high level. This
will eventually replace the old ad-hoc system of using cascaded contexts,
as well as allowing us to plug in more dynamic scaling passe
From: Niklas Haas
This rewrite cleans up the code to use AVFrames and the new swscale API. The
log format has also been simplified and expanded to account for the new
options. (Not yet implemented)
The self testing code path has also been expanded to test the new swscale
implementation against t
From: Niklas Haas
As part of a larger, ongoing effort to modernize and partially rewrite
libswscale, it was decided and generally agreed upon to introduce a new
public API for libswscale. This API is designed to be less stateful, more
explicitly defined, and considerably easier to use than the ex
From: Niklas Haas
Most logic from this filter has been co-opted into swscale itself,
allowing the resulting filter to be substantially simpler as it no
longer has to worry about context initialization, interlacing, etc.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libavfilt
From: Niklas Haas
With the ability to set the thread count as well. This benchmark includes
the constant overhead of context initialization.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/tests/swscale.c | 93 --
1 file changed,
From: Niklas Haas
Exactly what it says on the tin.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale.h | 6 ++
libswscale/utils.c | 7 +++
2 files changed, 13 insertions(+)
diff --git a/libswscale/swscale.h b/libswscale/swscale.h
index f36efa4183..d
From: Niklas Haas
Used by the graph API swscale wrapper, for now.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale_internal.h | 4
libswscale/utils.c| 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale_i
On 10.10.24 12:35, Anton Khirnov wrote:
I have to wonder if it would actually help, given the overhead of
copying the data to the GPU and back. Wouldn't it be more useful to
write normal SIMD?
Yes -- that's indeed very good question!
I'm also not convinced that it will always show positive
Quoting Martin Schitter (2024-10-10 04:58:40)
> +static int pass_though(AVCodecContext *avctx, AVFrame *frame, const AVPacket
> *avpkt)
> +{
> +/* there is no need to copy as the data already match
> + * a known pixel format */
> +
> +frame->buf[0] = av_buffer_ref(avpkt->buf);
> +
> +
Quoting Peter Ross (2024-10-09 07:35:08)
> Modification of patch submitted by Aurelien Jacobs (November 2007).
>
> Fixes ticket #5581.
> ---
> libavcodec/vp5.c | 5 +
> libavcodec/vp56.c| 32 +++-
> libavcodec/vp56.h| 6 ++
> libavcodec/vp6.c
>>-FATE_SAMPLES_DEMUX-$(call ALLYES, S337M_DEMUXER DOLBY_E_PARSER
>>FRAMECRC_MUXER) += fate-s337m-demux
>>+FATE_SAMPLES_DEMUX-$(call FRAMECRC, S337M,, DOLBY_E_PARSER
>>+FRAMECRC_MUXER) += fate-s337m-demux
>> fate-s337m-demux: CMD = framecrc -i $(TARGET_SAMPLES)/dolby_e/16-11 -c
>> copy -ss 2 -t
On 10.10.24 11:27, Lynne via ffmpeg-devel wrote:
Petro Mozil wrote a Vulkan VC-2 decoder that'll soon get merged:
https://github.com/pmozil/FFmpeg
Thanks for this very useful link!
I'll definitely have to study this uncommon vulkan dirac implementation
and learn from it.
Its an example o
From: Niklas Haas
Following in the footsteps of the work in the previous commit, it's now
relatively straightforward to expose the options struct publicly as
SwsContext. This is a step towards making this more user friendly, as
well as following API conventions established elsewhere.
Sponsored-b
From: Niklas Haas
Reorganize the list, fix whitespace, make indentation consistent, and
rename some descriptions for clarity, consistency or informativeness.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/options.c | 86 ++--
From: Niklas Haas
I want to pull options out of SwsInternal, so we need to make this field
a dedicated int that gets updated as appropriate in ff_swscale().
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale.c | 1 +
libswscale/swscale_internal.h | 3 +
From: Niklas Haas
Groups together all relevant color metadata from an AVFrame. While we could
use AVFrame directly, keeping it a separate struct has three advantages:
1. Functions accepting an SwsFormat will definitely not care about the
data pointers.
2. It clearly separates sanitized and ra
From: Niklas Haas
Instead of sprinkling av_assert0 into random init functions.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale_internal.h | 9 +
libswscale/utils.c| 3 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/lib
From: Niklas Haas
Replacing the old sws_isSupported* API with a more consistent family
of functions that follows the same signature and naming convention,
including a placeholder for testing the color space parameters that
we don't currently implement conversions for.
Sponsored-by: Sovereign Tec
Hi
On Fri, Oct 11, 2024 at 12:19:08AM +0300, Dennis Mungai wrote:
> Hello there,
>
> Several domains are down/offline, including:
We today rebooted the host on which the VMs are running due to
updates.
> 2. FFmpeg trac https://trac.ffmpeg.org/
trac seems working as far as i can tell
thx
[..
On 10.10.24 14:13, Anton Khirnov wrote:
Quoting Martin Schitter (2024-10-10 04:58:40)
+static int pass_though(AVCodecContext *avctx, AVFrame *frame, const AVPacket
*avpkt)
+{
+/* there is no need to copy as the data already match
+ * a known pixel format */
+
+frame->buf[0] = av_
Quoting martin schitter (2024-10-10 10:50:45)
>
>
> On 10.10.24 08:06, Lynne via ffmpeg-devel wrote:
> > You can copy libavutil/vulkan* into whatever project you want, and
> > change 4 #include lines to make it compile.
> > This lets you use the same API to construct and execute shaders as you
On 10/10/2024 10:50, martin schitter wrote:
On 10.10.24 08:06, Lynne via ffmpeg-devel wrote:
You can copy libavutil/vulkan* into whatever project you want, and
change 4 #include lines to make it compile.
This lets you use the same API to construct and execute shaders as you
would within lavc/
>De : Nicolas Gaullier
>Envoyé : mercredi 9 octobre 2024 22:30
>
>diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak
>index c16b540d2f..fe5073397e 100644
>--- a/tests/fate/demux.mak
>+++ b/tests/fate/demux.mak
>@@ -1,82 +1,82 @@
>(..)
>-FATE_SAMPLES_DEMUX-$(call ALLYES, S337M_DEMUXER DOLBY_
Thanks Cameron, your patch timeout mechanism has been tested and improves
performance.
But still works with some issues when B-frames are presented.
This issue was resolved in the attached data, please update your patch
with information
below:
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
On 10 Oct 2024, at 17:14, Steven Liu wrote:
> Because there have global varible in libxml2, it cleans up memory allocated by
> the library itself. It is a cleanup function for the XML library.
> It tries to reclaim all related global memory allocated for the library
> processing.
> It doesn't d
On 10/9/2024 11:05 PM, James Almer wrote:
Fixes fate-imgutils and fate-pixelutils under gcc-usan after
29ea34728f1064877a0ab9b8dee0f3de69a2d750.
Signed-off-by: James Almer
---
libavutil/pixdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/pixdesc.c b/libavu
On 10/8/2024 7:50 PM, James Almer wrote:
Signed-off-by: James Almer
---
libswscale/input.c | 35 +++
libswscale/utils.c | 1 +
2 files changed, 36 insertions(+)
Will apply patches 5 to 21 soon.
OpenPGP_signature.asc
Description: OpenPGP digital signature
On Tue, Oct 01, 2024 at 10:31:25PM +0200, Michael Niedermayer wrote:
> Fixes: Ticket5548
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ffv1.c| 7 +++
> libavcodec/ffv1.h| 1 +
> libavcodec/ffv1enc.c | 4
> 3 files changed, 12 inser
On Thu, Sep 26, 2024 at 10:01:15PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ffv1.h| 1 +
> libavcodec/ffv1dec.c | 10 ++
> libavcodec/ffv1enc.c | 12 +---
> 3 files changed, 16 insertions(+), 7 deletions(-)
will apply
[...]
-
Hello,
I would like to request reimbursement for the following expenses
incurred attending the Google Summer of Code mentor summit.
Description | Amount
--+
Train home to London
On 10.10.24 08:06, Lynne via ffmpeg-devel wrote:
You can copy libavutil/vulkan* into whatever project you want, and
change 4 #include lines to make it compile.
This lets you use the same API to construct and execute shaders as you
would within lavc/lavfi/lavu into your own project. You will n
To ff_slice_thread_await/report_progress().
---
libavcodec/hevc/hevcdec.c | 16
libavcodec/pthread_slice.c | 4 ++--
libavcodec/thread.h| 4 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index
It currently associates a progress value with a thread rather than a
job, relying on the broken assumption that a job's thread number is
equal to its job number modulo thread count.
This changes the API to associate a mutex/cond/progress value with every
job. Since job count may change dynamically
Because there have global varible in libxml2, it cleans up memory allocated by
the library itself. It is a cleanup function for the XML library.
It tries to reclaim all related global memory allocated for the library
processing.
It doesn't deallocate any document related memory.
One should call xm
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index b4d719a7eec..6aa36716cb3 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression with
rawlsb=4
Please test and comment, especially if you are an archivist caring about
compression and speed
Id like to know if this is a direction (that is trading compression against
speed) that
is wanted
Note, this onl
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1enc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 430e2161a3b..3a431f41365 100644
--- a/libavcodec/ffv1enc.c
+++ b/lib
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1enc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index b9ee5b629a2..430e2161a3b 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1enc.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 3a431f41365..30d8073c8d4 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -988
On Thu, Oct 10, 2024 at 01:45:58PM -0300, James Almer wrote:
> On 10/8/2024 7:50 PM, James Almer wrote:
> > Signed-off-by: James Almer
> > ---
> > libswscale/input.c | 35 +++
> > libswscale/utils.c | 1 +
> > 2 files changed, 36 insertions(+)
>
> Will apply p
Hello there,
Several domains are down/offline, including:
1. https://patchwork.ffmpeg.org/
2. FFmpeg trac https://trac.ffmpeg.org/
It seems to be very intermittent at the moment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/
47 matches
Mail list logo
