What about ISOM mappings?
___
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 "unsubscribe".
On Sun, 7 Aug 2022, James Almer wrote:
ffmpeg | branch: master | James Almer | Fri Aug 5 13:44:16
2022 -0300| [19748132613d1d13f5b6786051910e7375bb3df6] | committer: James Almer
swscale/output: add VUYA output support
Signed-off-by: James Almer
http://git.videolan.org/gitweb.cgi/ffmpeg.g
From: Anton Khirnov
Bump the version requirement to 122, which introduced b_full_recon.
---
configure| 2 +-
libavcodec/libx264.c | 55 +++-
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index eb413a6716
On Mon, 8 Aug 2022, Martin Storsjö wrote:
From: Anton Khirnov
Bump the version requirement to 122, which introduced b_full_recon.
---
configure| 2 +-
libavcodec/libx264.c | 55 +++-
2 files changed, 55 insertions(+), 2 deletions(-)
Sorry, d
This directory dependency is normally added implicitly by rules
in ffbuild/common.mak; for tools it's created by a rule for TOOLOBJS.
TOOLOBJS is populated implicitly from TOOLS, and decode_simple.o
doesn't end up there because it's an odd occurrance of a lone
object file in the tools subdirectory,
Signed-off-by: James Almer
---
libswscale/output.c | 4 ++--
tests/ref/fate/filter-pixdesc-vuya | 2 +-
tests/ref/fate/filter-pixfmts-copy | 2 +-
tests/ref/fate/filter-pixfmts-crop | 2 +-
tests/ref/fate/filter-pixfmts-field | 2 +-
tests/ref/fate/filt
On 8/8/2022 5:56 AM, Martin Storsjö wrote:
On Sun, 7 Aug 2022, James Almer wrote:
ffmpeg | branch: master | James Almer | Fri Aug 5
13:44:16 2022 -0300| [19748132613d1d13f5b6786051910e7375bb3df6] |
committer: James Almer
swscale/output: add VUYA output support
Signed-off-by: James Almer
- Added new entry to codec IDs list
- Added new entry to the codec descriptor list
- Bumped libavcodec minor version
- Changes in Changelog and MAINTAINERS files
- Added xeve encoder wrapper
- Added xevd dencoder wrapper
- Added documentation for xeve and xevd wrappers
- Added parser for EVC format
- Added muxer for EVC format (MP4, raw)
- Added demuxer for EVC format (MP4)
- Added evc extension to the list of extensions for ff_mov_demuxer
- Added information to moov atom
Signed-off-by: Dawid Kozinski
---
doc/muxers.texi | 6 +
libavformat/Makefile | 4 +-
libavformat/allf
On 8/8/2022 4:48 AM, Paul B Mahol wrote:
What about ISOM mappings?
I don't see any for AYUV tag or this decoder. I saw and changed the riff
one already in f8c62e32b2618d76f26b7536f9a177db2bda7e35.
What mov/qt uses is v408 (ordered UYVA in memory), which is also a pixel
format we could add a
On Mon, 8 Aug 2022, James Almer wrote:
Signed-off-by: James Almer
---
libswscale/output.c | 4 ++--
tests/ref/fate/filter-pixdesc-vuya | 2 +-
tests/ref/fate/filter-pixfmts-copy | 2 +-
tests/ref/fate/filter-pixfmts-crop | 2 +-
tests/ref/fate/filter-pixfmts-f
I've just submitted new patches that were made based on your requests and
suggestions.
Please find below my comments.
-Original Message-
From: ffmpeg-devel On Behalf Of James Almer
Sent: Monday, August 1, 2022 2:29 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/2] P
I just uploaded new patches that were made based on your requests and
suggestions.
Please find below my comments.
-Original Message-
From: ffmpeg-devel On Behalf Of James Almer
Sent: Monday, August 1, 2022 5:09 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/2] Provid
I just uploaded new patches that were made based on your requests and
suggestions.
-Original Message-
From: ffmpeg-devel On Behalf Of Michael
Niedermayer
Sent: Monday, August 1, 2022 9:31 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 2/2] Provided
I just uploaded new patches that were made based on your requests and
suggestions.
Please find below my comments.
-Original Message-
From: ffmpeg-devel On Behalf Of James Almer
Sent: Monday, August 1, 2022 4:05 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 2/2] Provid
On 8/3/2022 2:18 PM, Derek Buitenhuis wrote:
> Some muxers, such as GPAC, create files with only one sidx, but two streams
> muxed into the same fragments pointed to by this sidx.
>
> Prevously, in such a case, when we seeked in such files, we fell back
> to, for example, using the sidx associated
p...@sandflow.com:
> From: Pierre-Anthony Lemieux
>
> Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299726.html
>
> ---
> libavformat/avformat.c | 66
> libavformat/fifo.c | 8 ++---
> libavformat/internal.h | 11 +++
> li
From: Michael Niedermayer
---
doc/git-howto.texi | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/doc/git-howto.texi b/doc/git-howto.texi
index 874afabbbc..9c74199495 100644
--- a/doc/git-howto.texi
+++ b/doc/git-howto.texi
@@ -187,11 +187,18 @@ to make s
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ed15f96f6..ed2ec0b90c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -626,6 +626,7 @@ Leo Izen (thebombzen) B6FD 3CFC 7ACF 83F
Given the recent server issues, i wonder if we should suggest/recommand
and document signing commits and tags
i tried to push such commit to github and it nicely says "verified"
https://github.com/michaelni/FFmpeg/commit/75f196acd16fb0c0ca7a94f0c66072e7c6f736bf
Ive generated a new gpg key for thi
On Mon, Aug 8, 2022 at 7:48 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299726.html
> >
> > ---
> > libavformat/avformat.c | 66
> > libavfor
On 8/8/2022 11:50 AM, Michael Niedermayer wrote:
Given the recent server issues, i wonder if we should suggest/recommand
and document signing commits and tags
fwiw, the git repo isn't hosted in the server that had issues.
i tried to push such commit to github and it nicely says "verified"
ht
James Almer (12022-08-07):
> Include two values for it, a default one that sets/keeps the current behavior,
> where the frame event generated by the primary input will have a timestamp
> equal or higher than frames in secondary input, plus a new one where the
> secondary input frame will be that wi
On 8/8/2022 11:50 AM, Michael Niedermayer wrote:
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ed15f96f6..ed2ec0b90c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -626,6 +626,
On Mon, Aug 08, 2022 at 12:16:36PM -0300, James Almer wrote:
> On 8/8/2022 11:50 AM, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > MAINTAINERS | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/MAINTAINERS b/MAINTA
On Mon, Aug 08, 2022 at 12:02:39PM -0300, James Almer wrote:
> On 8/8/2022 11:50 AM, Michael Niedermayer wrote:
> > Given the recent server issues, i wonder if we should suggest/recommand
> > and document signing commits and tags
>
> fwiw, the git repo isn't hosted in the server that had issues.
---
Depends on the patch adding that pixel format to ffmpeg, sent earlier
this week.
libavutil/hwcontext_d3d11va.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 27c0c80413..363ec6a47d 100644
--- a/libavutil/hwcontext_d3d11v
This is by no means perfect, since at least ddagrab will return scRGB
data with values outside of 0.0f to 1.0f for HDR values.
Its primary purpose is to be able to work with the format at all.
_Float16 support was available on arm/aarch64 for a while, and with gcc
12 was enabled on x86 as long as
Aug 8, 2022, 16:50 by mich...@niedermayer.cc:
> Given the recent server issues, i wonder if we should suggest/recommand
> and document signing commits and tags
>
> i tried to push such commit to github and it nicely says "verified"
> https://github.com/michaelni/FFmpeg/commit/75f196acd16fb0c0ca7a9
Aug 8, 2022, 17:25 by jswin...@amazon.com:
> Recent version of gcc improve the automatic vectorization. This flag
> allows adventurous users to enable vectorization. Known problems with
> this are primarily related to inline assembly for x86 and so to address
> those, add a pragma to explicitly di
On Mon, Aug 8, 2022 at 11:24 AM Timo Rothenpieler
wrote:
> This is by no means perfect, since at least ddagrab will return scRGB
> data with values outside of 0.0f to 1.0f for HDR values.
> Its primary purpose is to be able to work with the format at all.
>
> _Float16 support was available on arm
On Fri, 5 Aug 2022, Martin Storsjö wrote:
On Wed, 27 Jul 2022, Andreas Rheinhardt wrote:
Swinney, Jonathan:
This patch looks good to me. I would appreciate its merging.
} while (0)
#define PERF_STOP(t) do { \
+int ret;
On 08.08.2022 21:39, Mark Reid wrote:
On Mon, Aug 8, 2022 at 11:24 AM Timo Rothenpieler
wrote:
This is by no means perfect, since at least ddagrab will return scRGB
data with values outside of 0.0f to 1.0f for HDR values.
Its primary purpose is to be able to work with the format at all.
_Floa
On Mon, Aug 8, 2022 at 1:59 PM Timo Rothenpieler
wrote:
> On 08.08.2022 21:39, Mark Reid wrote:
> > On Mon, Aug 8, 2022 at 11:24 AM Timo Rothenpieler >
> > wrote:
> >
> >> This is by no means perfect, since at least ddagrab will return scRGB
> >> data with values outside of 0.0f to 1.0f for HDR
On Mon, Aug 08, 2022 at 09:26:52PM +0200, Lynne wrote:
> Aug 8, 2022, 16:50 by mich...@niedermayer.cc:
>
> > Given the recent server issues, i wonder if we should suggest/recommand
> > and document signing commits and tags
> >
> > i tried to push such commit to github and it nicely says "verified"
On 09.08.2022 00:07, Mark Reid wrote:
On Mon, Aug 8, 2022 at 1:59 PM Timo Rothenpieler
wrote:
On 08.08.2022 21:39, Mark Reid wrote:
On Mon, Aug 8, 2022 at 11:24 AM Timo Rothenpieler
This is by no means perfect, since at least ddagrab will return scRGB
data with values outside of 0.0f to 1.0f
On 09.08.2022 00:37, Timo Rothenpieler wrote:
The entire support for the format is removed from swscale in this case,
so the function ending up empty doesn't matter.
I'll see if it can be added to half2float, but I can't even tell if it
implements ieee floats, or something else.
Did a very s
On Wed, 2022-08-03 at 04:55 +, Xiang, Haihao wrote:
> On Mon, 2022-07-25 at 12:11 +0800, Xiang, Haihao wrote:
> > From: Haihao Xiang
> >
> > The oneAPI Video Processing Library (oneVPL) is a single interface for
> > encode, decode and video processing[1][2]. oneVPL is a successor to Intel(R)
On Fri, 2022-08-05 at 20:27 -0700, Philip Langdale wrote:
> vaapi_decode_find_best_format currently does not set the
> VA_SURFACE_ATTRIB_SETTABLE flag on the pixel format attribute that it
> returns.
>
> Without this flag, the attribute will be ignored by vaCreateSurfaces,
> meaning that the drive
On Fri, 2022-08-05 at 20:27 -0700, Philip Langdale wrote:
> Sufficiently recent Intel hardware is able to do encoding of 8bit 4:4:4
> content in HEVC and VP9. The main requirement here is that the frames
> must be provided in the AYUV format.
>
> Enabling support is done by adding the appropriate
40 matches
Mail list logo
