Hi Martin,
Thanks for writing in!
On Tue, Oct 22, 2024 at 11:41 AM martin schitter wrote:
>
>
>
> On 22.10.24 08:50, Diederick C. Niehorster wrote:
> >> I want to pick up a discussion i started last week
> >> (https://ffmpeg.org/pipermail/ffmpeg-devel/2024-October/334585.html)
> >> in a new thre
Quoting Marton Balint (2024-10-22 20:35:52)
>
>
> On Tue, 22 Oct 2024, Anton Khirnov wrote:
>
> > Quoting Martin Schitter (2024-10-21 21:57:18)
> >> +static int pass_through(AVCodecContext *avctx, AVFrame *frame, const
> >> AVPacket *avpkt)
> >> +{
> >> +/* there is no need to copy as the d
On 22.10.24 20:35, Marton Balint wrote:
On Tue, 22 Oct 2024, Anton Khirnov wrote:
I said this twice before already - every single format that uses
pass_through() should instead be exported by the demuxer as
AV_CODEC_ID_RAWVIDEO, because that's what it is.
I don't really want the MXF demuxer/
On 22.10.24 22:33, Diederick C. Niehorster wrote:
I am writing about machine vision, not machine learning or computer
vision. So there are no uncommon small bit sizes, we're dealing with
8bit, 10bit, 12bit components here.
Sorry -- I'm such a sloppy reader/writer -- especially, when I'm hurr
This is needed to correctly set conformance window crop with Mesa AMD.
---
libavcodec/vaapi_encode_h265.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 2283bcc0b4..0f97c9188b 100644
--- a/liba
It needs to create temporary config to query surface attribute.
---
libavcodec/vaapi_encode.c | 66 +++
libavcodec/vaapi_encode.h | 4 +++
2 files changed, 70 insertions(+)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 16a9a364f0..c8
Hi,
On Sun, Oct 6, 2024, 15:48 Martin Storsjö wrote:
> On Sat, 5 Oct 2024, Sean McGovern wrote:
>
> > Hi
> >
> > On Sat, Oct 5, 2024, 19:15 Lynne via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org>
> > wrote:
> >
> >> On 05/10/2024 20:58, Sean McGovern wrote:
> >>> ---
> >>> libavcodec/aacenc_pred.c
On Tue, 22 Oct 2024, Anton Khirnov wrote:
Quoting Martin Schitter (2024-10-21 21:57:18)
+static int pass_through(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] =
Fixes compile error on windows with decklink:
In file included from ./libavformat/os_support.h:175,
from ./libavformat/internal.h:30,
from libavdevice/decklink_common.cpp:25:
./libavutil/wchar_filename.h: In function 'int wchartocp(unsigned int, const
wchar_t*, c
On 10/21/2024 10:22 AM, Zhao Zhili wrote:
On Sep 18, 2024, at 14:56, Zhao Zhili wrote:
From: Zhao Zhili
---
sample:
8054b4b8e62c0171476b40206d044590 Hierarchical.bit
https://drive.google.com/file/d/1U5WGWeSsMFiEkhsl_vL4NiMma-LLh02t/view?usp=sharing
Put Hierarchical.bit under $(TARGET_SAM
On 22.10.24 04:37, James Almer wrote:
On 10/21/2024 8:51 PM, James Almer wrote:
On 10/21/2024 10:02 PM, martin schitter wrote:
I didn't participate in earlier rounds, but at least my opinion is
that we shouldn't add new pixel formats if they are only used for a
single codec and have no RIFF
Quoting Martin Schitter (2024-10-21 21:57:18)
> +static int pass_through(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);
I said
On 22.10.24 15:10, James Almer wrote:
On 10/22/2024 11:26 AM, martin schitter wrote:
On 22.10.24 14:48, James Almer wrote:
+ AV_PIX_FMT_Y216BE, ///< packed YUV 4:2:2 like YUYV422,
32bpp, big-endian
+ AV_PIX_FMT_Y216LE, ///< packed YUV 4:2:2 like YUYV422,
32bpp, little-endia
We tried to update cinelerra-gg to ffmpeg 7.1 and ran into two problems:
First, vf_scale now declares dynamic input and was filtered out by code
in cinelerra/pluginfclient.C
int flag_mask = AVFILTER_FLAG_DYNAMIC_INPUTS |
AVFILTER_FLAG_DYNAMIC_OUTPUTS;
if( filter->flags & flag_mask ) return AV
Why yet another crappy hardware API? There is a million of those.
Why yet another crappy special snowflake hardware decoder? We have more
of those than we want (which is 0).
As Mark has also previously commented, the hwcontext implementation
seems to be to a large extent a cargo cult.
--
Anton K
Quoting martin schitter (2024-10-22 01:40:07)
>
>
> On 21.10.24 22:44, James Almer wrote:
> >
> > That's not good...
> >
> > [...]
>
> Whenever and however I change it, there will allways be somebody who
> doesn't like it. !:(
>
> This time I spend a lot of time to modify the code as close a
On 22.10.24 14:48, James Almer wrote:
+AV_PIX_FMT_Y216BE, ///< packed YUV 4:2:2 like YUYV422, 32bpp,
big-endian
+AV_PIX_FMT_Y216LE, ///< packed YUV 4:2:2 like YUYV422, 32bpp,
little-endian
Why to you avoid any more verbose naming, where any developer would see
the actual
On 10/22/2024 11:26 AM, martin schitter wrote:
On 22.10.24 14:48, James Almer wrote:
+ AV_PIX_FMT_Y216BE, ///< packed YUV 4:2:2 like YUYV422,
32bpp, big-endian
+ AV_PIX_FMT_Y216LE, ///< packed YUV 4:2:2 like YUYV422,
32bpp, little-endian
Why to you avoid any more verbose nam
As defined in
https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#422-formats
Signed-off-by: James Almer
---
libavcodec/raw.c | 2 ++
libavformat/riff.c | 2 ++
tests/ref/fate/filter-pixdesc-y210le | 2 +-
Signed-off-by: James Almer
---
libavutil/pixdesc.c | 23 +++
libavutil/pixfmt.h | 4
libavutil/tests/pixfmt_best.c| 2 ++
tests/ref/fate/imgutils | 4
tests/ref/fate/pixfmt_best | 2 +-
tests/ref/fate/sws-pixdesc-quer
Signed-off-by: James Almer
---
libswscale/output.c | 44
libswscale/utils.c | 2 +-
tests/ref/fate/filter-pixdesc-y216le | 1 +
tests/ref/fate/filter-pixfmts-copy | 1 +
tests/ref/fate/filter-pixfmts-field | 1
Signed-off-by: James Almer
---
libavcodec/qsv.c | 8
libavutil/hwcontext_qsv.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 8a3dc95706..d9eb212b1c 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -218,7
Signed-off-by: James Almer
---
libavutil/hwcontext_d3d11va.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 9b3c5f389f..ecf4207b3c 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.
Signed-off-by: James Almer
---
libswscale/input.c | 7 +++
libswscale/utils.c | 1 +
2 files changed, 8 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index bb5e31a428..40629831db 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -601,6 +601,7 @@ static void yvy
On Mon, Oct 21, 2024 at 1:41 AM Michael Niedermayer
wrote:
> On Thu, Oct 17, 2024 at 01:00:12PM +0200, Ramiro Polla wrote:
> > Consider APPx fields that are too short to contain an id field (32-bit)
> > as stubs, and silently ignore them.
> >
> > This has been seen in the MJPEG output from some we
On 22.10.24 08:50, Diederick C. Niehorster wrote:
I want to pick up a discussion i started last week
(https://ffmpeg.org/pipermail/ffmpeg-devel/2024-October/334585.html)
in a new thread, with the relevant information nicely organized. This
is about adding pixel formats common in machine vision
On Mon, Oct 21, 2024 at 04:40:41PM +0200, Jerome Martinez wrote:
> Le 16/10/2024 à 22:53, Michael Niedermayer a écrit :
> > what are you testing?
> > the new code is faster than the old code.
> > There is something not right here, the range coder based implementation
> > i posted now is 5% faster t
On 16/10/2024 15:26, Michael Niedermayer wrote:
This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression with
rawlsb=4
Please test and comment
This stores the LSB through non binary range coding, this is simpler than using
a
separate coder
For cases where range coding is not w
On 10/22/2024 11:45 AM, martin schitter wrote:
On 22.10.24 15:10, James Almer wrote:
On 10/22/2024 11:26 AM, martin schitter wrote:
On 22.10.24 14:48, James Almer wrote:
+ AV_PIX_FMT_Y216BE, ///< packed YUV 4:2:2 like YUYV422,
32bpp, big-endian
+ AV_PIX_FMT_Y216LE, ///< pac
29 matches
Mail list logo
