On 2/28/25 15:07, Devin Heitmueller wrote:
I've been working on the codebase for more than eight years, and
didn't know it existed. I would suggest that people reviewing patches
and rejecting them due to style issues that they recommend to
submitters to run the tool. In my experience, develo
On 2/26/25 17:03, Zhao Zhili wrote:
Plugin interface can be abused, but at the same time, they can fulfill many
legitimate
user needs. Not everyone can write a program based on
libavcodec/libavformat/libavfilter,
and get the same function as fftools. They can write a filter plugin, and let
On 2/13/25 13:10, Tomas Härdin wrote:
More stuff should be done with git alone. This is
one case where fossil shines, because it combines code, tickets and
wiki into one single CLI tool.
'radicle' does the same with git! :)
But it's still much to immature to use it as real alternative to the
On 2/13/25 07:14, Lynne wrote:
Finally, with federation, there's are no restriction. If users have an
account on another Forgejo instance, such as codeberg, they can clone
and submit PRs to FFmpeg without having to register, and without needing
to use agit.
This will not work very well tog
On 2/12/25 23:05, Timo Rothenpieler wrote:
PRs are not restricted. Creating repos is.
And there is no way to NOT restrict it, unless you want to pay several
hundred Euros a month in hosting fees extra, and constantly be on the
lookout for hosting illegal/harmful things.
Hosting tons of for
On 25.01.25 08:54, Soft Works wrote:
Gitea
https://gitea.com/ffstaging/FFmpeg
forgejo
https://v10.next.forgejo.org/ffstaging/FFmpeg
GitLab
https://gitlab.com/ffstaging/FFmpeg
Perhaps you should also add a `radicle` (https://radicle.xyz/) test
repo
This was nothing official nor plann
On 22.01.25 03:00, Soft Works wrote:
It's a bit difficult to judge those repo providers without appropriate data, so
I made copies of the ffstaging GitHub site (for creating PRs being sent to the
ML), so the all have current ffmpeg data:
Gitea
https://gitea.com/ffstaging/FFmpeg
forgejo
On 27.12.24 16:26, James Almer wrote:
Everyone wants to move to gitlab/forejo already. The entry bar for new
blood is too high with the current ML + git send-email/format-patch style.
An optimization of the contribution mechanisms, issue and documention
handling and CI/CD would be indeed ve
On 30.11.24 21:41, Michael Niedermayer wrote:
What name should the repository have ?
ffmpeg-infra
ffmpeg-private
(i dont like the sound of "private" for a open source project)
ffmpeg-internals may sound nicer
___
ffmpeg-devel mailing list
ffmpeg-d
On 20.11.24 22:03, Marton Balint wrote:
The layering issue is for the decoder to take care of, not the parser.
Yes, we could handle it in the decoder just like in case of OpenEXR,
where we use a special `-layer` option to specify the component/layer
to pick out of the input stream.
But
On 19.11.24 22:47, Marton Balint wrote:
The current parser does things which a parser should not, like skipping parts
of the packet header, but it does not actually able to packetize a raw DNXUC
bitstream.
You're right! I simply can't reject this judgment about the obvious
flaws of the curr
On 12.11.24 08:51, Martin Storsjö wrote:
On Tue, 12 Nov 2024, martin schitter wrote:
The git history of Patches here on this mailinglist are usually
rewritten whenever one of the reviewers requests some change, but the
typical workflow in github/gitlab doesn't use or even forbids this
On 11.11.24 08:11, Diederick C. Niehorster wrote:
I have no personal experience with gitlab, but it:
I'm a long term GitLab user. I use it for most of my work on self-hosted
instances but also on gitlab.com.
In the past it was a really impressive alternative to github, which
provided use
On 23.10.24 15:19, Marton Balint wrote:
On Tue, 22 Oct 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-10-22 20:35:52)
I don't really want the MXF demuxer/muxer to do DNXUC parsing
What parsing is there to do? You just compare against the codec tag.
As far as I know, the codec tag
On 23.10.24 09:12, Diederick C. Niehorster wrote:
+ This decoder for DNxUncompressed video data is mostly based on
+ reverse engineering of output generated by DaVinci Resolve 19
+ but was later also checked against the SMPTE RDD 50 specification.
+
+ Not all DNxUncompressed pixel format varia
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
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 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,
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 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 a
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 22.10.24 00:31, James Almer wrote:
On 10/21/2024 8:40 PM, martin schitter wrote:
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. !:(
My point is, it's not a good idea
On 22.10.24 00:32, Michael Niedermayer wrote:
I see you added these in the previous patch of the series, i guess its ok then
exactly! :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsu
On 22.10.24 00:30, Michael Niedermayer wrote:
adding them in the middle will change the numbers of the following and break ABI
sadly
you have to add them at the end
If you apply the whole patch set, they are all as one group at the end!
I just did my best to not increase the utterly chaot
On 21.10.24 23:50, James Almer wrote:
On 10/21/2024 5:44 PM, James Almer wrote:
On 10/21/2024 4:57 PM, Martin Schitter wrote:
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV4
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 as possible
to requests asked by one previous reviewer, who insisted, that
---
tests/Makefile | 1 +
tests/fate/dnxuc.mak| 40 +
tests/ref/fate/dnxuc-cb-rgb-10 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-12 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-8 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-flo
In case of RGB content wrapped in MXF containers we can not use
CDCIDescriptor fields for the video level detection.
The corresponding information in RGBA Descriptors uses a significant
differnt structure. As a workaround we pick the first found channel
depth info value of the RGBALayout array and
---
Changelog | 2 ++
doc/general_contents.texi | 1 +
2 files changed, 3 insertions(+)
diff --git a/Changelog b/Changelog
index 7963e09..75b8e15 100644
--- a/Changelog
+++ b/Changelog
@@ -3,6 +3,8 @@ releases are sorted from youngest to oldest.
version :
- yasm support droppe
@@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 decoder
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software
---
libswscale/input.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index f9d7c39..ba7e3c4 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1447,6 +1447,30 @@ static av_always_inline void planar_rgbf3
---
libavutil/pixdesc.c | 48 +++
libavutil/pixfmt.h | 6 ++
libswscale/input.c | 100 +++
libswscale/utils.c | 6 +-
tests/ref/fate/imgutils | 8 +++
tests/ref/fate/sws-pixdesc-query |
---
libavutil/pixdesc.c | 48
libavutil/pixfmt.h | 6 ++
libswscale/input.c | 99
libswscale/utils.c | 4 ++
tests/ref/fate/imgutils | 8 +++
tests/ref/fate/sws-pixdesc-query | 14 +
---
libavutil/pixdesc.c | 46
libavutil/pixfmt.h | 8 +++
libswscale/input.c | 90
libswscale/utils.c | 4 ++
tests/ref/fate/imgutils | 8 +++
tests/ref/fate/sws-pixdesc-query | 14
.
Unfortunately I don't have samples to test all of them.
At least all export options supported by DaVinci Resolve should work.
Combined Components and mixed RGB + Alpha content is still not supported.
Please check the code and merge it.
Martin
Martin Schitter (9):
avutil/swscale:
---
libavutil/pixdesc.c | 11 +++
libavutil/pixfmt.h | 2 ++
libswscale/input.c | 22 ++
libswscale/utils.c | 1 +
tests/ref/fate/imgutils | 2 ++
tests/ref/fate/sws-pixdesc-query | 2 ++
6 files change
The missing APIchanges entry requested by A.Khirnov.
Martin
---
doc/APIchanges | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index 5bfb52c..9ee898b 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all librarie
---
libswscale/input.c | 101 ++-
libswscale/utils.c | 2 +
libswscale/version.h | 2 +-
3 files changed, 103 insertions(+), 2 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index e2af1d5..9beb72b 100644
--- a/libswscale/input.c
+
---
libavutil/pixdesc.c | 25 +
libavutil/pixfmt.h | 4
libavutil/version.h | 2 +-
tests/ref/fate/imgutils | 4
tests/ref/fate/sws-pixdesc-query | 11 +++
5 files changed, 45 insertions(+), 1 deletion(-)
---
libswscale/input.c | 72 --
libswscale/utils.c | 2 ++
2 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 35c1fb7..e2af1d5 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1170,6
Changes v4: Fix fate test error caused by changes pix_fmt order.
Martin
Martin Schitter (3):
swscale/input: add input support for RGBF32
avutil: add RGBF16 pix_fmt
swscale/input: add input support for RGBF16
libavutil/pixdesc.c | 25 +
libavutil/pixfmt.h
v3 changes: The new RGBF16 pix format enum entry is moved to end of list.
Martin
Martin Schitter (3):
swscale/input: add input support for RGBF32
avutil: add RGBF16 pix_fmt
swscale/input: add input support for RGBF16
libavutil/pixdesc.c | 25 +
libavutil/pixfmt.h
---
libswscale/input.c | 101 ++-
libswscale/utils.c | 2 +
libswscale/version.h | 2 +-
3 files changed, 103 insertions(+), 2 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index e2af1d5..9beb72b 100644
--- a/libswscale/input.c
+
---
libavutil/pixdesc.c | 25 +
libavutil/pixfmt.h | 4
libavutil/version.h | 2 +-
tests/ref/fate/imgutils | 4
tests/ref/fate/sws-pixdesc-query | 11 +++
5 files changed, 45 insertions(+), 1 deletion(-)
---
libswscale/input.c | 72 --
libswscale/utils.c | 2 ++
2 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 35c1fb7..e2af1d5 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1170,6
On 14.10.24 00:45, Michael Niedermayer wrote:
On Sun, Oct 13, 2024 at 08:03:56PM +0200, Martin Schitter wrote:
---
libavutil/pixdesc.c | 25 +
libavutil/pixfmt.h | 4
libavutil/version.h | 2 +-
tests/ref/fate
---
libswscale/input.c | 101 ++-
libswscale/utils.c | 2 +
libswscale/version.h | 2 +-
3 files changed, 103 insertions(+), 2 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index e2af1d5..9beb72b 100644
--- a/libswscale/input.c
+
---
libavutil/pixdesc.c | 25 +
libavutil/pixfmt.h | 4
libavutil/version.h | 2 +-
tests/ref/fate/imgutils | 4
tests/ref/fate/sws-pixdesc-query | 11 +++
5 files changed, 45 insertions(+), 1 deletion(-)
---
libswscale/input.c | 72 --
libswscale/utils.c | 2 ++
2 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 35c1fb7..e2af1d5 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1170,6
Additonal pix_fmts and swscale import support for RGB Float data.
v2 fixes changed fate results.
martin
Martin Schitter (3):
swscale/input: add input support for RGBF32
avutil: add RGBF16 pix_fmt
swscale/input: add input support for RGBF16
libavutil/pixdesc.c | 25
---
libavutil/pixdesc.c | 25 +++
libavutil/pixfmt.h | 4 ++
libavutil/version.h | 2 +-
libswscale/input.c | 101 ++-
libswscale/utils.c | 2 +
libswscale/version.h | 2 +-
6 files changed, 133 insertions(+), 3 deletions(-)
diff --
Additonal pix_fmts and swscale import support for RGB Float data.
Please review and merge these changes.
thanks
martin
Martin Schitter (2):
swscale/input: add input support for RGBF32
avutil/swscale: add RGBF16 pix_fmt and input support
libavutil/pixdesc.c | 25 +++
libavutil
---
libswscale/input.c | 72 --
libswscale/utils.c | 2 ++
2 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 35c1fb7..e2af1d5 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1170,6
On 12.10.24 23:18, epira...@gmail.com wrote:
Maybe just squash them into one commit.
Yes -- this looks like the most desirable solution.
And thanks to Alex for the suggested improvement!
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
On 11.10.24 10:57, Anton Khirnov wrote:
It seems rather obvious to me - you're making a demuxer export something
that IS raw video, yet you're tagging it as a new codec ID with a new
decoder that (for these specific pixel format) duplicates what the
rawvideo decoder does.
Just to be clear, I
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->bu
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
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
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
Can someone here point me to an example, how to use GPU acceleration
outside of external hw_decode/encode facilities or vulkan_filters, just
as more suitable compute mechanism and for better float image data
support in ordinary ffmpeg code modules?
Most examples and documentation are only f
@@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 decoder
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software
---
tests/Makefile | 1 +
tests/fate/dnxuc.mak| 40 +
tests/ref/fate/dnxuc-cb-rgb-10 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-12 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-8 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-flo
---
Changelog | 2 ++
doc/general_contents.texi | 1 +
2 files changed, 3 insertions(+)
diff --git a/Changelog b/Changelog
index 7963e09..75b8e15 100644
--- a/Changelog
+++ b/Changelog
@@ -3,6 +3,8 @@ releases are sorted from youngest to oldest.
version :
- yasm support droppe
A slightly improved version of the DNxUncompressed decoder
to fix flaws pointed out in Michael Niedermayers last review.
* utilize byte swapping in float16 alpha workaround.
* use bitwise AND instead of reminder for performance reasons.
Martin
Martin Schitter (3):
libavcodec/dnxucdec
Thanks for looking again in such an accurate manner over this code!
On 09.10.24 18:13, Michael Niedermayer wrote:
On Fri, Oct 04, 2024 at 11:07:33PM +0200, Martin Schitter wrote:
[...]
+static int half_add_alpha(AVCodecContext *avctx, AVFrame *frame, const
AVPacket *pkt)
+{
+/* ffmpeg
Shouldn't the number in RELEASE reflect the present release version?
Martin
---
RELEASE | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/RELEASE b/RELEASE
index 72ec89d..9fa1d2c 100644
--- a/RELEASE
+++ b/RELEASE
@@ -1 +1 @@
-7.0.git
+7.1.git
--
2.45.2
__
On 04.10.24 18:10, Devon Sookhoo wrote:
I thought the option "-c:v rawvideo" was the way to go because it's used
to generate an uncompressed avi file:
$ ffmpeg -i input.mp4 -c:v rawvideo out.avi
For the older simpler file formats, where only a rather small set of
supported image format
On 03.10.24 20:44, Michael Niedermayer wrote:
On Mon, Sep 23, 2024 at 11:16:45AM +0200, Martin Schitter wrote:
[...]
+static av_cold int dnxuc_decode_init(AVCodecContext *avctx)
+{
+return 0;
+}
unneeded
done in v10.
+memcpy(&frame->data[2][2*(y*lw + x)]
---
tests/Makefile | 1 +
tests/fate/dnxuc.mak| 40 +
tests/ref/fate/dnxuc-cb-rgb-10 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-12 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-8 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-flo
---
Changelog | 2 ++
doc/general_contents.texi | 1 +
2 files changed, 3 insertions(+)
diff --git a/Changelog b/Changelog
index b82b948..41632ba 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,8 @@ Entries are sorted chronologically from oldest to youngest
within each release,
@@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 decoder
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software
---
libavformat/mxf.c| 1 +
libavformat/mxfdec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index a73e40e..b6c1f17 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -61,6 +61,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x
) += dvaudio_parser.o
diff --git a/libavcodec/dnxuc_parser.c b/libavcodec/dnxuc_parser.c
new file mode 100644
index 000..55d5763
--- /dev/null
+++ b/libavcodec/dnxuc_parser.c
@@ -0,0 +1,124 @@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 parser
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of
---
libavcodec/codec_desc.c | 7 +++
libavcodec/codec_id.h | 1 +
libavcodec/version.c| 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 03dea57..2452a7b 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec
v10 of this patch set utilizes AV_WL16 macros instead of memcpy to get
byte swapping support as pointed out by michael niedermayers review.
Martin
Martin Schitter (6):
libavcodec/: Add ID and desc for DNxUncompressed
libavformat/mxf: Add ULs for DNxUncompressed
libavcodec/dnxuc_parser
On 04.10.24 15:11, Devon Sookhoo wrote:
You're correct that I'm primarily interested in uncompressed data and not
raw bayer sensor data.
Yes -- it was more a rather extreme example to remind, that this file
format isn't as simple and limited as many old and simple AV packaging
solutions f
On 04.10.24 01:33, Devon Sookhoo wrote:
Once completed, I envision the following command to work:
$ ffmpeg -i input.mp4 -c:v rawvideo output.mp4
Why do you choose the term "raw" instead of uncompressed?
Using this format for "raw" bayer CFA data is just one possible
application of ISO/
I know, you are all busy with 7.1 release cleanup, but could you please
take another look at my DNxUncompressed patches and merge them.
I always fixed the change requests reported by reviewers within 24
hours, and most of them were in fact really trivial and of cosmetic
nature anyway, but in t
On 25.09.24 21:30, Thilo Borgmann via ffmpeg-devel wrote:
Am 20.09.24 um 02:50 schrieb Martin Schitter:
Because I'm now waiting for one week that someone finally puts my
contributed DNxUncompressed sample files to the Fate sample repo
(see: https://lists.ffmpeg.org/pipermail/ffmpeg-
On 25.09.24 01:34, Devon Sookhoo wrote:
Historically,
whenever an application required the use of uncompressed data, it was a
"wild west" of file formats, with no shortage of proprietary options which
has lead to interoperability issues across communities.
Sure, a few simple old fashioned s
On 23.09.24 16:36, Devon Sookhoo wrote:
I'm interested in implementing uncompressed MP4 parsing according to the
newly released ISO/IEC 23001-17:2024. Would anyone be interested in further
discussing this with me?
As you have most likely already seen I've worked on a rather similar
project
On 24.09.24 20:45, martin schitter wrote:
"Meitner" (https://en.wikipedia.org/wiki/Lise_Meitner)
because of:
https://en.wikipedia.org/wiki/Lise_Meitner#/media/
File:Bohr_Heisenberg_Pauli_Meitner_u.a._1937_(cropped).jpg
sorry -- I had the impression, that physics count, but in th
On 24.09.24 18:08, Marcus B Spencer wrote:
anyone has a suggestion/preferrance for a name ?
I have a preference for the name "Huffman".
"Meitner" (https://en.wikipedia.org/wiki/Lise_Meitner)
because of:
https://en.wikipedia.org/wiki/Lise_Meitner#/media/File:Bohr_Heisenberg_Pauli_Meitner_u.
On 24.09.24 01:48, martin schitter wrote:
they should be T:
feel free to send a patch fixing that, or ill fix it later
Although you fixed one occurrence of this issue by f2aba7 it's still
present on the next line.
My patch would have fixed both of them. ;)
M
On 24.09.24 00:31, Michael Niedermayer wrote:
Btw.: the fate info and the "webserver"-entry one line above use
(S:...)-entries, which aren't mentioned as a possible variant in the
descriptive top section of MAINTAINERS. Shouldn't these be (T:...)-
or (W: ...)-entries or the (S: ...) kind be
---
MAINTAINERS| 7 +--
doc/developer.texi | 2 +-
doc/fate.texi | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 036066d..04a4a05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -61,8 +61,11 @@ API tests
---
tests/Makefile | 1 +
tests/fate/dnxuc.mak| 40 +
tests/ref/fate/dnxuc-cb-rgb-10 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-12 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-8 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-flo
---
Changelog | 1 +
doc/general_contents.texi | 1 +
2 files changed, 2 insertions(+)
diff --git a/Changelog b/Changelog
index 49a16da..13e2ac0 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
- Cropping metadata parsing and writing in Matroska and MP4/MOV de/m
) += dvaudio_parser.o
diff --git a/libavcodec/dnxuc_parser.c b/libavcodec/dnxuc_parser.c
new file mode 100644
index 000..55d5763
--- /dev/null
+++ b/libavcodec/dnxuc_parser.c
@@ -0,0 +1,124 @@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 parser
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of
@@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 decoder
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software
Patchset for DNxUncomprressed decoder.
v9 includes changes to fix issues mentioned in Marton Balints review.
---
libavcodec/codec_desc.c | 7 +++
libavcodec/codec_id.h | 1 +
libavcodec/version.c| 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/codec_desc
---
libavformat/mxf.c| 1 +
libavformat/mxfdec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index a73e40e..b6c1f17 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -61,6 +61,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x
All the mentioned issues are fixed in v9.
Thanks for your accurate review!
martin
On 23.09.24 00:24, Marton Balint wrote:
+ for(y = 0; y < frame->height; y++){
+ for(x = 0; x < frame->width; x++){
You might want to push variable declarations to the loop initializer
expression, li
v2 adds the address as a second (L: ...)-entry
to the Fate info in MAINTAINERS.
I'm not sure if this is correct because I couldn't find other lines,
where the same kind of entry gets used twice.
Btw.: the fate info and the "webserver"-entry one line above use
(S:...)-entries, which aren't menti
---
tests/Makefile | 1 +
tests/fate/dnxuc.mak| 40 +
tests/ref/fate/dnxuc-cb-rgb-10 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-12 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-8 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-flo
---
Changelog | 1 +
doc/general_contents.texi | 1 +
2 files changed, 2 insertions(+)
diff --git a/Changelog b/Changelog
index 49a16da..13e2ac0 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
- Cropping metadata parsing and writing in Matroska and MP4/MOV de/m
@@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 decoder
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software
---
libavformat/mxf.c| 1 +
libavformat/mxfdec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index a73e40e..b6c1f17 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -61,6 +61,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x
) += dvaudio_parser.o
diff --git a/libavcodec/dnxuc_parser.c b/libavcodec/dnxuc_parser.c
new file mode 100644
index 000..55d5763
--- /dev/null
+++ b/libavcodec/dnxuc_parser.c
@@ -0,0 +1,124 @@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 parser
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of
This is just a rebased version of the DNxUncompressed patch set
without any additional changes to make merging easier.
Please contact me if you still see necessary improvements.
thanks
martin
[PATCH v8 1/6] libavcodec/: Add ID and desc for DNxUncompressed
[PATCH v8 2/6] libavformat/mxf: Add UL
1 - 100 of 152 matches
Mail list logo
